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

evanflow-executing-plans

NPX Install

Tags

SKILL.md Content