Plan Implementation

Methodology for decomposing work into implementation units and planning each one. Use this skill standalone or as a reference from other planning skills.

Decomposition

Sizing

• One unit = one logical unit of work (a feature, a subsystem, a layer)

• Never split tightly-coupled pieces across units (if UI + API + tests are inseparable, keep them together)

• Split independent subsystems into separate units

• If a unit would touch more than ~15-20 files or span 3+ unrelated subsystems, split further

• If the entire scope fits one session, produce a single unit — do not over-decompose

• Each unit must leave the codebase fully integrated — never leave components unreachable from the project's entry points

Ordering

Order by dependency — foundational work before dependent work:

• Setup and scaffolding (project init, config, CI)

• Data and domain layer (models, schemas, types)

• Core business logic

• API and service layer

• UI and frontend

• Integration and end-to-end concerns

• Finalization (QA, commit, PR — always last)

Adaptation

When a plan meets reality, adjust for divergence before executing:

• File paths changed — update references to match actual structure

• Architecture evolved — adjust the plan to work with what was actually built

• Scope shifted — add or remove items based on what prior work produced

• New information — incorporate discoveries from previous sessions

Keep adaptations minimal — adjust only what diverged, do not rewrite plans unnecessarily.

Planning Each Unit

For each unit of work, plan the implementation thoroughly:

• Explore the codebase — read files relevant to the unit's scope, understand existing patterns, find code to build on

• Design the implementation — determine what files to create or modify, what approach to take, what tests to write

• Write a detailed plan — specific enough to execute: exact file paths, function signatures, data flow, test cases

• Include a task list — one task per step in the plan

• Include relevant skills — identify which skills apply and instruct: "After plan approval and before making edits, run /skill-a , /skill-b ."

Rules

• Split conservatively when scope is ambiguous (smaller units are safer than oversized ones)

• Each unit must be self-contained with enough context to understand the work without reading the full plan

• Never merge setup and finalization into the same unit