PolyFlow: Executing Plans
Vocabulary
See polyflow meta-skill. Key terms: vertical slice, behavior through public interface.
When to Use
- A plan file exists (
docs/plans/... or wherever the user put it)
- Ready to start implementation
The Flow
1. Load and Critically Review
- Read the plan in full
- Identify ambiguities, gaps, or assumptions you'd make differently
- If anything is unclear or wrong, raise it with the user before starting
- Set up TaskCreate items mirroring the plan's tasks
2. Execute Task-by-Task
For each task:
- Mark the task
in_progress
- Follow the plan's bite-sized steps exactly
- For code steps, default to TDD via
polyflow-tdd (skip only when plan flags an exception)
- Run the inline verifications the plan specifies
- Run the project-wide quality checks before claiming done. The exact commands are project-specific — find them in CLAUDE.md or the project's README. Typically:
- typecheck (e.g.,
tsc --noEmit, pnpm typecheck, cargo check, go vet ./...)
- lint (e.g.,
eslint ., pnpm lint, cargo clippy, ruff check .)
- test for affected workspaces (e.g.,
pnpm test, pytest, cargo test, go test ./...)
- Mark the task
completed
3. Handle Blockers
Stop immediately when:
- Missing dependency or environment problem
- Plan instruction is ambiguous or contradicts the code
- Verification fails repeatedly
- Discover the plan's assumption was wrong
Don't force through. Surface the blocker and ask. If the plan needs revision, return to polyflow-writing-plans.
4. Iterate, Then Stop
After all tasks pass quality checks, hand off to polyflow-iterate for the self-review loop. Iterate finds issues a single pass missed (dead code, naming, scope creep, missing tests). For UI changes, iterate also views the rendered page.
When iterate converges: report what was done and STOP. Do NOT stage files (git add), do NOT commit, do NOT push, do NOT propose integration. The user decides every step from here.
A good "done" report includes: what files changed (one line each), what behaviors were added/changed, what verifications passed. Then await user direction.
Hard Rules
- Never auto-commit, never auto-stage, never auto-finish. Period. After all tasks pass and iterate converges, report and stop. The user decides what comes next.
- No forced sub-skill chain. Extra execution tooling is an explicit user choice, not a requirement.
- Verify before claiming done. Run the project's quality checks and confirm output before marking a task complete or reporting success.
- Match scope. Don't add features or refactor beyond what the plan calls for.
Hand-offs
- All tasks complete →
polyflow-iterate (self-review loop) → report and STOP
- Plan needs revision → back to
polyflow-writing-plans
1---2name: polyflow-executing-plans3description: Execute a written implementation plan task-by-task with inline verification. Stop and ask on blockers. No forced sub-skill chains. Use when a plan exists and you're ready to implement.4---56# PolyFlow: Executing Plans78910## Vocabulary1112See `polyflow` meta-skill. Key terms: **vertical slice**, **behavior through public interface**.1314## When to Use1516- A plan file exists (`docs/plans/...` or wherever the user put it)17- Ready to start implementation1819## The Flow2021### 1. Load and Critically Review2223- Read the plan in full24- Identify ambiguities, gaps, or assumptions you'd make differently25- If anything is unclear or wrong, raise it with the user **before** starting26- Set up TaskCreate items mirroring the plan's tasks2728### 2. Execute Task-by-Task2930For each task:31321. Mark the task `in_progress`332. Follow the plan's bite-sized steps exactly343. For code steps, default to TDD via `polyflow-tdd` (skip only when plan flags an exception)354. Run the inline verifications the plan specifies365. Run the project-wide quality checks before claiming done. The exact commands are project-specific — find them in CLAUDE.md or the project's README. Typically:37 - typecheck (e.g., `tsc --noEmit`, `pnpm typecheck`, `cargo check`, `go vet ./...`)38 - lint (e.g., `eslint .`, `pnpm lint`, `cargo clippy`, `ruff check .`)39 - test for affected workspaces (e.g., `pnpm test`, `pytest`, `cargo test`, `go test ./...`)406. Mark the task `completed`4142### 3. Handle Blockers4344**Stop immediately when:**4546- Missing dependency or environment problem47- Plan instruction is ambiguous or contradicts the code48- Verification fails repeatedly49- Discover the plan's assumption was wrong5051**Don't force through.** Surface the blocker and ask. If the plan needs revision, return to `polyflow-writing-plans`.5253### 4. Iterate, Then Stop5455After all tasks pass quality checks, hand off to `polyflow-iterate` for the self-review loop. Iterate finds issues a single pass missed (dead code, naming, scope creep, missing tests). For UI changes, iterate also views the rendered page.5657When iterate converges: **report what was done and STOP**. Do NOT stage files (`git add`), do NOT commit, do NOT push, do NOT propose integration. The user decides every step from here.5859A good "done" report includes: what files changed (one line each), what behaviors were added/changed, what verifications passed. Then await user direction.6061## Hard Rules6263- **Never auto-commit, never auto-stage, never auto-finish.** Period. After all tasks pass and iterate converges, **report and stop**. The user decides what comes next.64- **No forced sub-skill chain.** Extra execution tooling is an explicit user choice, not a requirement.65- **Verify before claiming done.** Run the project's quality checks and confirm output before marking a task complete or reporting success.66- **Match scope.** Don't add features or refactor beyond what the plan calls for.6768## Hand-offs6970- All tasks complete → `polyflow-iterate` (self-review loop) → **report and STOP**71- Plan needs revision → back to `polyflow-writing-plans`
evanklem