evanflow-executing-plans

Name: evanflow-executing-plans
Author: evanklem

419stars18forks

How to install evanflow-executing-plans?

evanklem/evanflow/evanflow-executing-plans

$npx -y skills add evanklem/evanflow --skill evanflow-executing-plans

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Executing Plans
2
3
4
5	## Vocabulary
6
7	See `evanflow` meta-skill. Key terms: vertical slice, behavior through public interface.
8
9	## When to Use
10
11	- A plan file exists (`docs/plans/...` or wherever the user put it)
12	- Ready to start implementation
13
14	## The Flow
15
16	### 0. Parallelization Check (offer coder-overseer if applicable)
17
18	Before doing anything else, scan the plan: does it have 3+ truly independent units that share a common interface contract?
19
20	If YES — offer `evanflow-coder-overseer` to the user before starting sequential execution:
21
22	> "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?"
23
24	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.
25
26	### 1. Load and Critically Review
27
28	- Read the plan in full
29	- Identify ambiguities, gaps, or assumptions you'd make differently
30	- If anything is unclear or wrong, raise it with the user before starting
31	- Set up TaskCreate items mirroring the plan's tasks
32
33	### 2. Execute Task-by-Task
34
35	For each task:
36
37	1. Mark the task `in_progress`
38	2. Follow the plan's bite-sized steps exactly
39	3. For code steps, default to TDD via `evanflow-tdd` (skip only when plan flags an exception)
40	4. Run the inline verifications the plan specifies
41	5. 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:
42	- typecheck (e.g., `tsc --noEmit`, `pnpm typecheck`, `cargo check`, `go vet ./...`)
43	- lint (e.g., `eslint .`, `pnpm lint`, `cargo clippy`, `ruff check .`)
44	- test for affected workspaces (e.g., `pnpm test`, `pytest`, `cargo test`, `go test ./...`)
45	6. Mark the task `completed`
46
47	### 3. Handle Blockers
48
49	Stop immediately when:
50
51	- Missing dependency or environment problem
52	- Plan instruction is ambiguous or contradicts the code
53	- Verification fails repeatedly
54	- Discover the plan's assumption was wrong
55
56	Don't force through. Surface the blocker and ask. If the plan needs revision, return to `evanflow-writing-plans`.
57
58	### 4. Iterate, Then Stop
59
60	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.
61
62	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.
63
64	A good "done" report includes: what files changed (one line each), what behaviors were added/changed, what verifications passed. Then await user direction.
65
66	## Hard Rules
67
68	- 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.
69	- No forced sub-skill chain. Subagent-driven execution and git-worktree isolation are escape hatches for huge plans, not requirements.
70	- Verify before claiming done. Run the project's quality checks and confirm output before marking a task complete or reporting success.
71	- Match scope. Don't add features or refactor beyond what the plan calls for.
72
73	## Hand-offs
74
75	- All tasks complete → `evanflow-iterate` (self-review loop) → report and STOP
76	- Plan needs revision → back to `evanflow-writing-plans`
77	- Plan has 3+ truly independent parallel tasks with a shared contract → switch to `evanflow-coder-overseer` (parallel coders + per-coder overseers + integration overseer)
78	- Working in a shared codebase, want isolation → consider a git-worktrees workflow if your environment provides one

People who liked this also viewed

6 picks

Type

evanflow-executing-plans

419stars18forks

View on GitHub

How to install evanflow-executing-plans?

evanklem/evanflow/evanflow-executing-plans

$npx -y skills add evanklem/evanflow --skill evanflow-executing-plans

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# EvanFlow: Executing Plans
2
3
4
5	## Vocabulary
6
7	See `evanflow` meta-skill. Key terms: vertical slice, behavior through public interface.
8
9	## When to Use
10
11	- A plan file exists (`docs/plans/...` or wherever the user put it)
12	- Ready to start implementation
13
14	## The Flow
15
16	### 0. Parallelization Check (offer coder-overseer if applicable)
17
18	Before doing anything else, scan the plan: does it have 3+ truly independent units that share a common interface contract?
19
20	If YES — offer `evanflow-coder-overseer` to the user before starting sequential execution:
21
22	> "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?"
23
24	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.
25
26	### 1. Load and Critically Review
27
28	- Read the plan in full
29	- Identify ambiguities, gaps, or assumptions you'd make differently
30	- If anything is unclear or wrong, raise it with the user before starting
31	- Set up TaskCreate items mirroring the plan's tasks
32
33	### 2. Execute Task-by-Task
34
35	For each task:
36
37	1. Mark the task `in_progress`
38	2. Follow the plan's bite-sized steps exactly
39	3. For code steps, default to TDD via `evanflow-tdd` (skip only when plan flags an exception)
40	4. Run the inline verifications the plan specifies
41	5. 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:
42	- typecheck (e.g., `tsc --noEmit`, `pnpm typecheck`, `cargo check`, `go vet ./...`)
43	- lint (e.g., `eslint .`, `pnpm lint`, `cargo clippy`, `ruff check .`)
44	- test for affected workspaces (e.g., `pnpm test`, `pytest`, `cargo test`, `go test ./...`)
45	6. Mark the task `completed`
46
47	### 3. Handle Blockers
48
49	Stop immediately when:
50
51	- Missing dependency or environment problem
52	- Plan instruction is ambiguous or contradicts the code
53	- Verification fails repeatedly
54	- Discover the plan's assumption was wrong
55
56	Don't force through. Surface the blocker and ask. If the plan needs revision, return to `evanflow-writing-plans`.
57
58	### 4. Iterate, Then Stop
59
60	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.
61
62	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.
63
64	A good "done" report includes: what files changed (one line each), what behaviors were added/changed, what verifications passed. Then await user direction.
65
66	## Hard Rules
67
68	- 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.
69	- No forced sub-skill chain. Subagent-driven execution and git-worktree isolation are escape hatches for huge plans, not requirements.
70	- Verify before claiming done. Run the project's quality checks and confirm output before marking a task complete or reporting success.
71	- Match scope. Don't add features or refactor beyond what the plan calls for.
72
73	## Hand-offs
74
75	- All tasks complete → `evanflow-iterate` (self-review loop) → report and STOP
76	- Plan needs revision → back to `evanflow-writing-plans`
77	- Plan has 3+ truly independent parallel tasks with a shared contract → switch to `evanflow-coder-overseer` (parallel coders + per-coder overseers + integration overseer)
78	- Working in a shared codebase, want isolation → consider a git-worktrees workflow if your environment provides one

People who liked this also viewed

6 picks

Type