Implementation Plan

Implementation Plan

Design the smallest sequence of independently verifiable vertical slices that satisfies accepted requirements, or challenge an existing plan before it is executed; implementation follows the accepted scope and applicable stack skills.

Workflow

To write a plan, follow the steps below. To challenge an existing plan, read only [plan-review](references/plan-review.md); to settle an unfamiliar API or architecture choice first, read [research-brief](references/research-brief.md).

1. Read the accepted scope: identify the outcome, constraints, authorization, and unresolved decisions; stop planning when material options still need a user decision.
2. Inspect the implementation: verify relevant paths, interfaces, dependencies, tests, and current work; preserve user changes and reuse existing mechanisms.
3. Choose useful slices: order the smallest independently verifiable changes by dependency; identify shared files and real compatibility or migration risks.
4. Specify proof: each slice names its outcome, affected files, dependencies, implementation steps, focused checks with expected results, and objective acceptance criteria.
5. Review the plan: map every requirement to a slice, verify unfamiliar APIs, remove speculative flexibility, and state any decision that truly blocks execution.
6. Deliver at the right scale: use a compact task table for linear work; add interface contracts, concurrency, rollout, or rollback details where needed, retaining every applicable risk and proof boundary.
7. Hand off: identify the first executable slice and the full project gate; carry existing implementation authorization forward without requesting it again.

Gotchas

• Planning is read-only by default: Do not edit source, create issues, install dependencies, or deploy while planning unless the user explicitly asked.
• Deletion test: An abstraction earns its place only when removing it would spread meaningful complexity or violate a real seam; delay a generalized adapter until a second concrete variation exists.
• Deep modules: Prefer modules that hide decisions over pass-through layers, and put tests and callers across the same real seam.

Task guides

• [plan-review](references/plan-review.md): Challenge a product or implementation plan: assumptions, failure modes, trade-offs, and a GO or NO-GO verdict.
• [research-brief](references/research-brief.md): Decision-ready research brief for an unfamiliar API or architecture choice: evidence table, options, and proof boundaries.

Documentation

• Adapted from Superpowers writing-plans, Spec Kit plan template, codebase design, domain modeling.
• Companion skills: [python-testing](../python-testing/SKILL.md) (red-green proof), [threat-model](../threat-model/SKILL.md) (security design risk).

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: fmind
• Source: fmind/dot
• License: MIT
• Homepage: https://fmind.dev

Install and usage instructions live in the source repository linked above.