Back to skills
SkillHub ClubShip Full StackFull StackTesting

workflow-execute-plans

Execute written implementation plans: first read and critically review the plan, then implement in small batches (default 3 tasks), produce verification evidence per batch and pause for feedback; must stop immediately and ask for help when blocked/tests fail/plan unclear. Trigger words: execute plan, implement plan, batch execution, follow the plan.

Packaged view

This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.

Stars
322
Hot score
99
Updated
March 20, 2026
Overall rating
C5.9
Composite score
5.9
Best-practice grade
A88.4

Install command

npx @skill-hub/cli install heyvhuang-ship-faster-workflow-execute-plans

Repository

Heyvhuang/ship-faster

Skill path: skills/workflow-execute-plans

Execute written implementation plans: first read and critically review the plan, then implement in small batches (default 3 tasks), produce verification evidence per batch and pause for feedback; must stop immediately and ask for help when blocked/tests fail/plan unclear. Trigger words: execute plan, implement plan, batch execution, follow the plan.

Open repository

Best for

Primary workflow: Ship Full Stack.

Technical facets: Full Stack, Testing.

Target audience: everyone.

License: Unknown.

Original source

Catalog source: SkillHub Club.

Repository owner: Heyvhuang.

This is still a mirrored public skill entry. Review the repository before installing into production workflows.

What it helps with

  • Install workflow-execute-plans into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
  • Review https://github.com/Heyvhuang/ship-faster before adding workflow-execute-plans to shared team environments
  • Use workflow-execute-plans for development workflows

Works across

Claude CodeCodex CLIGemini CLIOpenCode

Favorites: 0.

Sub-skills: 0.

Aggregator: No.

Original source / Raw SKILL.md

---
name: workflow-execute-plans
description: "Execute written implementation plans: first read and critically review the plan, then implement in small batches (default 3 tasks), produce verification evidence per batch and pause for feedback; must stop immediately and ask for help when blocked/tests fail/plan unclear. Trigger words: execute plan, implement plan, batch execution, follow the plan."
---

# Executing Plans (Batch Execution + Checkpoints)

## Goal

Reliably turn a "written plan file" into implementation results, avoiding drift or accumulated risk from doing everything at once.

**Core strategy: Batch execution + pause for feedback after each batch.**

## Input/Output (Recommended for Chaining)

Input (pass paths only):
- `plan_path`: Plan file (usually in `run_dir/03-plans/`)
- `repo_root`
- `run_dir`

Output (persisted):
- Plan execution status: `logs/state.json` (or `03-plans/<plan>-status.md`)
- Per-batch verification evidence: append to the corresponding plan file or `05-final/` summary

## Execution Flow

### Step 1) Read and Review Plan (Critical Review First)

1. Read `plan_path`
2. Review if the plan has these issues:
   - Missing dependencies (packages to install/env vars/external services)
   - Task granularity too large (can't verify, hard to rollback)
   - Missing acceptance criteria or verification commands
   - Obviously wrong task ordering
3. If critical issues found: **Stop first**, present concerns as 1-3 bullet points, let human confirm before starting execution.

> Rule: Don't "guess while doing". Clarify when plan is unclear.

### Step 2) Batch Execution (Default 3 Tasks per Batch)

Execute the first 3 tasks from the plan, then stop and report.

For each task:
1. Mark as `in_progress`
2. Execute strictly per plan (don't expand scope)
3. Run verification per plan (tests / build / typecheck / lint / manual verification steps)
4. Mark as `completed`

**Status recording (choose one, prefer structured):**
- Update task status in `logs/state.json`
- Or maintain checklist in `plan_path` (`[ ]`→`[x]`), recording verification results alongside

### Step 3) Batch Report (Must Pause for Feedback)

After each batch, report three things:
- **What changed**: Which files changed/what was implemented (brief)
- **Verification**: What verification was run, what were the results (key info only, no long logs)
- **Next batch**: Which 3 tasks are next

Optional but recommended:
- Use `review-merge-readiness` for a conclusive review on this batch (especially for cross-module changes, risky changes, or approaching merge)

Last line must be:
> Ready for feedback.

Then wait for human feedback—don't automatically continue to next batch.

### Step 4) Continue Based on Feedback

- If feedback requests changes: fix first, re-verify, then continue next batch
- If feedback is OK: continue to next batch (still default 3 tasks)

### Step 5) Wrap Up (After All Complete)

When all tasks are complete and verified:
- Run full tests/build (per project conventions)
- Write `05-final/summary.md` (what was done/how verified/risks & rollback/next steps)
- Do a `skill-evolution` **Evolution checkpoint** (3 questions); if user chooses "want to optimize", run `skill-improver` based on this `run_dir` to produce minimal patch suggestions
- If `finishing-a-development-branch` skill exists: follow that skill to complete merge/PR/cleanup options

## When to Stop and Ask for Help (Hard Rules)

Encounter any of these, **stop execution immediately** and report the issue:
- Blocked mid-way (missing dependency, wrong environment, permission issues)
- Tests/verification failed and can't quickly identify the cause
- Plan step unclear (can't determine correct implementation approach)
- Action that could cause data loss or wide-ranging side effects appears but plan doesn't include confirmation point

## Remember

- Review plan critically before starting
- Small batch execution (default 3 tasks)
- Every batch requires verification and reporting, then wait for feedback
- When blocked, stop—don't guess