From evanflow
Turns specs or requirements into bite-sized implementation plans: file-structure-first with deep modules, stress-test grill, parallelization options. For multi-file tasks.
npx claudepluginhub evanklem/evanflow --plugin evanflowThis skill uses the workspace's default tool permissions.
See `evanflow` meta-skill. Key terms: **deep modules**, **interface**, **vertical slice**, **deletion test**.
Generates detailed implementation plans from specs for multi-step tasks before coding, with bite-sized TDD steps, file structure maps, architecture overviews, tech stacks, and task dependencies.
Creates detailed implementation plans from specs for multi-step tasks before coding, with file structure mapping, bite-sized TDD steps, architecture overview, and tech stack.
Generates detailed implementation plans from specs for multi-step tasks before coding, with file structure, bite-sized TDD steps, architecture, and tech stack.
Share bugs, ideas, or general feedback.
See evanflow meta-skill. Key terms: deep modules, interface, vertical slice, deletion test.
SKIP when: single-file change, typo fix, one-line config tweak. Just do it.
If the spec covers multiple independent subsystems, suggest splitting into separate plans. Each plan should produce working, testable software on its own.
Before any tasks, name the files that will be created or modified, with a one-line responsibility for each. This locks in decomposition decisions.
Example (adapt the paths to your project's structure):
<backend>/routers/foo.ts — API router; thin, delegates to service
<backend>/services/foo.ts — business logic; pure where possible
<backend>/services/foo.test.ts — vertical-slice tests
<frontend>/pages/foo.tsx — UI; consumes the API
Apply the deletion test: if a file would just shuffle complexity to its callers, fold it into the caller.
After the file structure is sketched, ask: does this plan have 3+ truly independent units that share a common interface contract?
If YES — offer evanflow-coder-overseer to the user as the execution path:
"This plan has [N] independent units sharing [contract]. We could execute it sequentially via
evanflow-executing-plans, or in parallel viaevanflow-coder-overseer(one coder per unit + per-coder overseer + integration overseer + executable contract via integration tests). Parallel is faster for big plans and adds independent QA, but only works if the units are truly independent. Which?"
Signals that favor coder-overseer:
Signals that favor sequential executing-plans:
If the user picks coder-overseer, structure the plan with a per-coder section and the cohesion contract upfront. If sequential, continue to step 3 normally.
Stress-test the structure before writing tasks:
CONTEXT.md first?"Each task is one focused unit (~15-30 min of work). Within each task, list bite-sized steps (~2-5 min each):
### Task 1: [Component Name]
**Files:** Create `path/to/foo.ts`, modify `path/to/bar.ts:123-145`, test `path/to/foo.test.ts`
- [ ] Write the failing test (one behavior — see evanflow-tdd)
- [ ] Run test, confirm it fails for the right reason
- [ ] Write minimal implementation
- [ ] Run test, confirm it passes
- [ ] Run the project's quality checks (typecheck / lint / test) — exact commands are project-specific; see CLAUDE.md or the project's README
After all tasks complete, the executor hands off to evanflow-iterate for self-review, then stops and reports. The plan does NOT include staging or committing — the user controls those.
# [Feature Name] Plan
**Goal:** [one sentence]
**Architecture:** [2-3 sentences]
**Files:** [list from step 2]
---
No "REQUIRED SUB-SKILL" header. Sub-skills are suggestions documented inline at hand-off points, not mandates baked into the plan format.
Default location: docs/plans/YYYY-MM-DD-<topic>.md. If the user has a different preference, honor it. Don't write to any vendor-specific path unless explicitly asked.
docs/plans/ only if no preference stated.evanflow-executing-plansevanflow-design-interfaceevanflow-improve-architecture first, then back here