Implement Feature

OpenUsage Feature Implementer

Invocation: When a user wants to implement a feature that has a design doc in docs/*_DESIGN.md. Always requires a design doc — if none exists, tell the user to run /design-feature first.

Input: Design doc path or feature name (resolved to docs/<NAME>_DESIGN.md).

Phase 0 — Load Design

1. Read the design doc. If the path wasn't given, search docs/*_DESIGN.md for a match.
2. Extract and confirm with the user:
   • Problem statement
   • Affected subsystems (from Impact Analysis table)
   • Implementation tasks (Section 7)
   • Total task count
3. Ask: "Implement all tasks, or a subset?" Proceed only after confirmation.

Phase 1 — Codebase Analysis

For each affected subsystem, read the primary files from docs/skills/design-feature/references/subsystem-map.md.

For each implementation task, read every file listed under Files:. Note:

• Current state of types, functions, and interfaces the task will modify.
• Existing test patterns in each package (use the same style).
• Import conventions (stdlib / third-party / internal groups).

Summarize blockers or conflicts found (e.g., a type was renamed since the design was written). If any exist, flag them before proceeding.

Phase 1.5 — Pre-Implementation Quiz (MANDATORY)

After reading the codebase but before presenting the execution plan, surface ambiguities. Design docs cannot anticipate every integration detail. Present an interactive quiz covering:

1. Ambiguous design choices: Where the design says "add X" but there are multiple valid locations or approaches in the code.
2. Missing details: Decisions the design doc defers or doesn't address (e.g., UI placement, key bindings, exact data flow).
3. Conflicting patterns: Where the codebase has evolved since the design was written and there's more than one way to reconcile.
4. Scope boundaries: Confirm what's in vs. out — e.g., "Should this apply to both screens or just one?"

Format: Present numbered questions with options (A/B/C) where possible. For open-ended questions, propose a default and ask for confirmation.

After the quiz:

• Update the design doc with the resolved answers (add notes inline or update the relevant sections). The design doc is living documentation — keep it accurate.
• Proceed to Phase 2 only after all ambiguities are resolved.

Phase 2 — Execution Plan

Present a numbered execution plan derived from the design doc's tasks. For each task state:

Task N: <title>
  Depends on: <task numbers or "none">
  Files: <from design doc>
  Approach: <1-2 sentences: what you'll do, in order>
  Risk: <low/medium — flag anything non-trivial>

Parallelization analysis

After listing all tasks, identify parallel groups — sets of tasks with no mutual dependencies that can execute concurrently using agents:

Parallel group 1: Tasks 3, 4, 5 (all depend on Tasks 1-2 but not each other)
Sequential: Task 6 (depends on Tasks 3, 4) → Task 7 (depends on all)

Note: Parallel execution uses separate agents that cannot see each other's changes. Each agent must be given complete context for its task. Integration verification (Phase 3d) is mandatory after every parallel group.

Ask: "Proceed with this plan?" Adjust if the user requests changes.

Phase 3 — Implement

Execute tasks in dependency order. Tasks within the same parallel group MAY be executed concurrently using agents when the user requests it or when there are 3+ independent tasks.

3a. Code

• Follow existing patterns exactly. Match naming, error wrapping, comment style.
• Respect the project's code style rules from CLAUDE.md (gofmt, import groups, error prefix, JSON tags).
• Add only what the design specifies. No extras, no refactors, no bonus features.
• If the design doc shows type definitions, use them verbatim unless they conflict with current code.

3b. Test

• Write tests for every task that specifies them.
• Match the package's existing test patterns (table-driven, httptest servers, t.TempDir, etc.).
• Run the tests for the changed packages: go test ./<package>/... -count=1
• Do NOT run go test ./... unless explicitly asked.

3c. Validate (per-task)

After each task:

1. Run go_diagnostics on all modified files.
2. Fix any errors before moving to the next task.
3. Run the package tests.
4. Briefly report: task title, files changed, tests passing.

If a test fails, fix it before moving on. If a fix requires changing the design, flag it and ask the user.