implementation-planning

# Implementation Planning

## Overview

Write comprehensive implementation plans assuming the engineer is skilled but unfamiliar with the codebase and project conventions. Document everything they need: which files to touch for each task, complete code examples, testing commands, documentation to reference, and verification steps. Break work into atomic, committable units following DRY, YAGNI, and TDD principles.

**Announce at start:** "I'm using the implementation-planning skill to create the implementation plan."

**Context:** Plans should be created in a dedicated worktree for isolation.

**Save plans to:** `docs/plans/YYYY-MM-DD-<feature-name>.md`

## When to Use

**Use implementation-planning when:**
- Multi-step implementation (3+ distinct tasks)
- Complex integration requiring file-level navigation guidance
- Handoff to another developer or future execution session
- TDD cycle needs documentation for consistency across tasks
- Clear requirements exist and architecture approach is defined

**Don't use for:**
- Single-file changes (just implement directly)
- Well-established patterns with existing guides (reference those instead)
- Exploratory prototyping (plans constrain necessary experimentation)
- Unclear requirements (use brainstorming first)

## Atomic Task Granularity

**Each step is one atomic action:**
- Focused on single outcome
- Independently testable
- Committable as logical unit
- Has clear Definition of Done

**Examples of atomic steps:**
- "Write the failing test" - one step
- "Run it to verify failure" - one step
- "Implement minimal code to make test pass" - one step
- "Run tests and verify they pass" - one step
- "Commit changes" - one step

**NOT atomic:**
- "Write and run tests" - two steps combined
- "Implement feature with error handling" - multiple concerns
- "Update code and documentation" - separate commits

## Plan Document Header

**Every plan MUST start with this header:**

```markdown
# [Feature Name] Implementation Plan

> **For C