Create Implementation Plan

Read the requirements at $ARGUMENTS and create a lean implementation plan.

Plan Document Header

Every plan MUST start with:

# [Feature Name] Implementation Plan

**Goal:** [One sentence]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies]

## Lanes
| Lane | Owns files | Tasks | After | Executor | Effort |
|------|-----------|-------|-------|----------|--------|
| [name] | `src/full/path.py`, `tests/full/test_path.py` | 1–3 | — | inline | — |
| [name] | `src/other/module.py`, `tests/other/test_module.py` | 4–6 | [lane] | builder | medium |

## Review Focus
- [input or condition the spec implies but never names] → [what a reasonable user expects] (pinned: Task N)

Lanes let /turbocharge:build run independent work side by side and skip a builder spawn for mechanical work:

• A lane owns a set of files, listed as full repo-relative paths — build diffs and reviews each lane by them. No file belongs to two lanes — test files included.
• Tasks inside a lane run in order. After names lanes that must finish first; lanes with no After path between them may overlap.
• Executor is a hint: inline for mechanical lanes (content edits, exact text given, ≤3 tasks) that the main session applies directly; builder for real logic or lanes with judgment calls, run by one builder for the whole lane.
• Effort (low/medium/high) applies to builder lanes; use — for inline.
• A small plan can be a single lane.

Review Focus names up to 5 input classes or failure modes the spec implies but never names, and that no task's test would otherwise exercise: the empty list, the duplicate, the field with a comma, the rerun. One line each, most likely first: the input, then what a reasonable user expects. The spec says what the software must do, not everything it will meet; its silence on an input is not permission for that input to break the program. The task that owns the code gets a test assertion that pins each line, and the line names that task. If nothing is implied, write None found — <why>.

Context Gathering

Before planning, preload domain context. When dispatching the planner agent, prefix its prompt with:

@ATLAS.md (navigation index — use its Where to Look and Module Map tables before any codebase search)
@CLAUDE.md (conventions, rules, domain vocabulary)

If either file does not exist, omit the corresponding @ reference. Exception: if CLAUDE.md is missing but AGENTS.md exists, use @AGENTS.md in its place. .claude/CLAUDE.md counts as a CLAUDE.md: if the project keeps it there, use @.claude/CLAUDE.md. @ references auto-read on dispatch so the subagent receives them in context; subagents do NOT inherit parent conversation history.

Token discipline: Do NOT paste file contents or summaries into the dispatch prompt — send task description, file paths, and line ranges only. The planner reads actual files in its own context. Duplicating content in the dispatch wastes tokens (same pattern as build skill).

Task Structure

Each task MUST follow this format:

### Task N: [Component Name]
**Lane:** [lane] · **Files:** `exact/path.py:40-62` (modify), `exact/new_file.py` (create)
**Decision:** [1–4 lines: what changes and why — names, signatures, behavior, edge cases]
**Test:** `tests/exact/test_file.py`
- [assertion: input/state → expected result]
- [assertion: the edge case that must fail today]
**Verify:** `[exact command]` → [expected result]
**Commit:** `feat: [description]`

Rules

• Decisions, not code. Record what to build and why; the builder or the main session writes the code. Include code only where the exact text is the decision — a regex, a signature, a JSON key, an error string — inline or in a fence of ≤10 lines. Target ≈1.5 KB per task.
• Each task: 2-5 minutes of work. If longer, split it.
• Exact file paths, with line ranges for modifications — not "somewhere in src/". Line ranges are plan-time hints; build re-locates code by content when an earlier task in the lane shifts it
• Verify runs the task's own tests — never the full suite while another lane can still be running: it would see that lane's half-written files. Build runs the full suite once, at the join; only a final lane that comes After every other lane may verify with it
• Test assertions, not test code — each one names the input and the expected result, specific enough to write the test from
• Exact commands with expected output
• TDD always — every task names the test that fails before the change
• Review Focus pinned — every Review Focus line has its assertion in the task that owns the code
• DRY, YAGNI — don't plan features that aren't needed

Save

Write plan to: docs/plans/YYYY-MM-DD-<feature-name>.md. When the request names a path for the plan, write it there instead.

The planner writes the file early, with line 1 <!-- plan: in progress -->, appends tasks as it goes, and removes the marker once its self-review passes. A rerun on a path whose line 1 is that marker resumes it: it keeps the header and every task with its **Commit:** line, and continues from the next task. A finished plan at the path is never overwritten; the new one goes to <name>-2.md.

Report: plan location, number of tasks, any assumptions made. End with exactly:

Next: review `<path>`, then `/turbocharge:build <path>`.

If the planner stopped on a question that would change the design, there is no plan: report the question and end with it instead.

This skill runs forked and cannot ask for approval; the user reviews the saved plan, and running build is the approval.