EvanFlow: Executing Plans
Vocabulary
See evanflow 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
0. Parallelization Check (offer coder-overseer if applicable)
Before doing anything else, scan the plan: does it have 3+ truly independent units that share a common interface contract?
If YES — offer evanflow-coder-overseer to the user before starting sequential execution:
"This plan has [N] independent units. We can execute sequentially or via evanflow-coder-overseer (parallel coders + per-coder overseers + integration overseer + executable cohesion contract via named integration tests). Parallel is faster and adds independent QA. Which path?"If the user picks coder-overseer, hand off there and stop this skill. If the user picks sequential — or if the plan doesn't qualify (tightly sequential dependencies, fewer than 3 units, no shared contract) — proceed to step 1.
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
evanflow-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 evanflow-writing-plans.
4. Iterate, Then Stop
After all tasks pass quality checks, hand off to evanflow-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. Subagent-driven execution and git-worktree isolation are escape hatches for huge plans, not requirements.
- 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 →
evanflow-iterate(self-review loop) → report and STOP - Plan needs revision → back to
evanflow-writing-plans - Plan has 3+ truly independent parallel tasks with a shared contract → switch to
evanflow-coder-overseer(parallel coders + per-coder overseers + integration overseer) - Working in a shared codebase, want isolation → consider a git-worktrees workflow if your environment provides one