Plan Step Skill
Plan the implementation of a roadmap step from docs/ROADMAP.md. Reads the GitHub issue, relevant documentation, and enters plan mode for user approval before any code is written.
Context
Current branch: !git branch --show-current
Roadmap steps: !grep -E '^\| [0-9]+ \|' docs/ROADMAP.md | head -40
Instructions
Step 1 — Identify the step and issue
- Parse
$ARGUMENTS for a step number. It may be provided as just a number (e.g., 27), or as Step 27, or with an issue number (e.g., 27 #64).
- If no step number is found in
$ARGUMENTS, ask the user with AskUserQuestion.
- Look up the step in
docs/ROADMAP.md to get its title, description, and dependencies.
- If the step already has
:white_check_mark:, warn the user that this step appears completed.
- Find the corresponding GitHub issue:
- If an issue number was provided in
$ARGUMENTS, use that.
- Otherwise, search:
gh issue list --search "Step {N}" --json number,title,state,labels --limit 10
- Match by step number in the title (e.g., "Step 27:" or "Step 27 —").
- If no issue is found, note that the issue needs to be created — the plan will include creating it as the first step (per CLAUDE.md: "every task starts with a GitHub issue").
- If multiple matches, pick the open one. If ambiguous, ask the user.
- If an existing issue was found, fetch its details:
gh issue view <number> --json title,body,labels,comments
- Use
AskUserQuestion to confirm: "Plan implementation for Step {N}: {title} (Issue #{issue} / issue will be created)?"
Step 2 — Gather context
- Read the relevant documentation listed in the roadmap step's "Key Files" or "Description" column.
- Check
CLAUDE.md Documentation Index — read any docs referenced for the module being implemented.
- Read existing source files that will be modified or extended (from roadmap's Key Files and issue body).
- Check dependency steps — verify they are completed (
:white_check_mark: in roadmap).
- If the step depends on incomplete steps, warn the user.
Step 3 — Enter plan mode
Use EnterPlanMode to enter planning mode. Then build a comprehensive implementation plan:
Plan structure
# Step {N}: {Title}
**Issue**: #{issue_number}
**Branch**: `issue/{issue_number}-{short-kebab-description}`
## Summary
<1-2 sentence overview of what this step accomplishes>
## Dependencies
- Step X: {title} — {status}
- ...
## Performance expectations (if applicable)
<If this step is performance-related, explicitly state:>
- **What** improvement is expected (e.g., "prefill throughput", "decode latency")
- **Where** in the pipeline (e.g., "attention softmax", "FFN projections")
- **How much** (e.g., "~10-35% total inference speedup" from roadmap/paper)
- **How to measure** (e.g., "bench_compare.py before/after on SmolLM-135M and Llama-3.2-1B")
- **Baseline**: run benchmarks BEFORE implementing
## Implementation plan
### 1. Create GitHub issue (if none exists)
Draft the issue title, body (with acceptance criteria derived from the roadmap description and docs), and create it via `gh issue create`. Use the returned issue number for the branch name.
### 2. Create branch
`git checkout -b issue/{issue_number}-{short-kebab-description} main`
### 3. {First logical unit of work}
- Files to create/modify: ...
- What to implement: ...
- Key design decisions: ...
### 4. {Next unit}
...
### N. Tests
- Unit tests: ...
- Integration tests (if applicable): ...
### N+1. Update roadmap & README
- Mark step as `:white_check_mark:` in `docs/ROADMAP.md`
- Update `README.md` roadmap table step count
- Add News entry if significant milestone
## Key design decisions
- Decision 1: {choice} — {rationale}
- ...
## Open questions
- Any uncertainties to resolve during implementation
Plan guidelines
- Follow CLAUDE.md conventions (file-scoped namespaces,
readonly record struct, etc.)
- Reference specific line numbers in existing files when extending them.
- For SIMD work: plan scalar reference first, then SIMD optimization.
- For new kernel work: plan correctness tests against scalar reference.
- Keep the plan concrete — specify method signatures, file paths, data structures.
- If the issue body has acceptance criteria, map each criterion to a plan section.
Step 4 — Present plan
Use ExitPlanMode to present the plan for user approval. The user will review and either approve or request changes.
1---2name: plan-step3description: Plan the implementation of a roadmap step — reads the issue, relevant docs, and enters plan mode4---56# Plan Step Skill78Plan the implementation of a roadmap step from `docs/ROADMAP.md`. Reads the GitHub issue, relevant documentation, and enters plan mode for user approval before any code is written.910## Context1112Current branch: !`git branch --show-current`13Roadmap steps: !`grep -E '^\| [0-9]+ \|' docs/ROADMAP.md | head -40`1415## Instructions1617### Step 1 — Identify the step and issue18191. Parse `$ARGUMENTS` for a step number. It may be provided as just a number (e.g., `27`), or as `Step 27`, or with an issue number (e.g., `27 #64`).202. If no step number is found in `$ARGUMENTS`, ask the user with `AskUserQuestion`.213. Look up the step in `docs/ROADMAP.md` to get its title, description, and dependencies.224. If the step already has `:white_check_mark:`, warn the user that this step appears completed.235. Find the corresponding GitHub issue:24 - If an issue number was provided in `$ARGUMENTS`, use that.25 - Otherwise, search: `gh issue list --search "Step {N}" --json number,title,state,labels --limit 10`26 - Match by step number in the title (e.g., "Step 27:" or "Step 27 —").27 - If no issue is found, note that the issue needs to be created — the plan will include creating it as the first step (per CLAUDE.md: "every task starts with a GitHub issue").28 - If multiple matches, pick the open one. If ambiguous, ask the user.296. If an existing issue was found, fetch its details: `gh issue view <number> --json title,body,labels,comments`307. Use `AskUserQuestion` to confirm: "Plan implementation for Step {N}: {title} (Issue #{issue} / issue will be created)?"3132### Step 2 — Gather context33341. Read the relevant documentation listed in the roadmap step's "Key Files" or "Description" column.352. Check `CLAUDE.md` Documentation Index — read any docs referenced for the module being implemented.363. Read existing source files that will be modified or extended (from roadmap's Key Files and issue body).374. Check dependency steps — verify they are completed (`:white_check_mark:` in roadmap).385. If the step depends on incomplete steps, warn the user.3940### Step 3 — Enter plan mode4142Use `EnterPlanMode` to enter planning mode. Then build a comprehensive implementation plan:4344#### Plan structure4546```markdown47# Step {N}: {Title}4849**Issue**: #{issue_number}50**Branch**: `issue/{issue_number}-{short-kebab-description}`5152## Summary53<1-2 sentence overview of what this step accomplishes>5455## Dependencies56- Step X: {title} — {status}57- ...5859## Performance expectations (if applicable)60<If this step is performance-related, explicitly state:>61- **What** improvement is expected (e.g., "prefill throughput", "decode latency")62- **Where** in the pipeline (e.g., "attention softmax", "FFN projections")63- **How much** (e.g., "~10-35% total inference speedup" from roadmap/paper)64- **How to measure** (e.g., "bench_compare.py before/after on SmolLM-135M and Llama-3.2-1B")65- **Baseline**: run benchmarks BEFORE implementing6667## Implementation plan6869### 1. Create GitHub issue (if none exists)70Draft the issue title, body (with acceptance criteria derived from the roadmap description and docs), and create it via `gh issue create`. Use the returned issue number for the branch name.7172### 2. Create branch73`git checkout -b issue/{issue_number}-{short-kebab-description} main`7475### 3. {First logical unit of work}76- Files to create/modify: ...77- What to implement: ...78- Key design decisions: ...7980### 4. {Next unit}81...8283### N. Tests84- Unit tests: ...85- Integration tests (if applicable): ...8687### N+1. Update roadmap & README88- Mark step as `:white_check_mark:` in `docs/ROADMAP.md`89- Update `README.md` roadmap table step count90- Add News entry if significant milestone9192## Key design decisions93- Decision 1: {choice} — {rationale}94- ...9596## Open questions97- Any uncertainties to resolve during implementation98```99100#### Plan guidelines101102- Follow CLAUDE.md conventions (file-scoped namespaces, `readonly record struct`, etc.)103- Reference specific line numbers in existing files when extending them.104- For SIMD work: plan scalar reference first, then SIMD optimization.105- For new kernel work: plan correctness tests against scalar reference.106- Keep the plan concrete — specify method signatures, file paths, data structures.107- If the issue body has acceptance criteria, map each criterion to a plan section.108109### Step 4 — Present plan110111Use `ExitPlanMode` to present the plan for user approval. The user will review and either approve or request changes.