Writing Implementation Plans

What it does

Writing-plans records the decisions a competent implementer cannot infer from a specification alone: file ownership, names, signatures, pinned values and checks. It avoids both vague instructions such as “handle errors” and unnecessary full function bodies when signatures and tests already determine the implementation. The reviewed version includes a self-review for requirement coverage, cross-task interface consistency and realistic failure modes. Its execution handoff preserves a method already chosen by the user or asks them to choose one.

When to use it

• Plan a feature spanning a route, a calculation module and a data migration.
• Prepare a handoff for an engineer who has not read the original discussion.
• Break a large requirement into independently verifiable deliverables.

Step-by-step workflow

1. Read the approved specification and existing code conventions; separate independent projects if their scope is unrelated.
2. Map the files and responsibilities, including which tasks consume interfaces produced by earlier tasks.
3. Write tasks in red/green order with exact test assertions, signatures, paths and required values.
4. Add executable verification commands and expected results; check coverage, consistency, proportion and overlooked failure cases.
5. Save the plan with a reference to its specification, obtain review and hand it to the selected execution workflow.

Example request

Use writing-plans for the approved CSV import design at docs/import-design.md. Keep our existing Python standard-library parser. Plan duplicate-row detection, invalid-date reporting and an atomic save. Name exact files, test inputs, expected row counts and public signatures. Include malformed input and interrupted-write cases. Do not implement code yet; preserve our choice of native execution when presenting the completed plan.

Worked example

For an import of three rows containing one duplicate, a task should state whether two records are accepted or the whole file is rejected. “Add deduplication” leaves that decision unresolved. A later persistence task must consume the same result type and error semantics. The review should also ask what happens if writing fails after parsing succeeds. That case belongs in a concrete test task, not a generic reminder at the end of the document.

What you get

A specification-linked implementation plan with file ownership, interfaces, ordered tests, expected results and execution handoff.

How to evaluate the result

• Every requirement maps to a deliverable and behavioral check.
• Interfaces agree across producer and consumer tasks, including failure shapes.
• A new implementer can execute each step and recognize success without guessing.

What you need

An approved design or sufficiently precise requirements, a readable repository and knowledge of its actual test commands. Planning does not require installing a new test framework.

Setup and activation

The publisher documents separate installation routes for Claude Code, Codex App and CLI, Cursor and other harnesses. Use the README for your exact client; installing the whole Superpowers framework can activate additional workflows automatically. Preserve this skill’s companion files and relative references. Review and security-scan the exact selected version before installation. This directory only reviews sources; it has not installed, executed or tested this skill on those clients.

Limits and considerations

The plan cannot repair an unresolved product decision by silently choosing it. The source’s conventional documentation path is overridable by project preference. Its review-focus section must lead to actual checks, not speculative lists. A complete plan remains subject to the real repository and should not copy large implementation bodies merely to appear thorough.

Related workflows

• Use brainstorming when requirements still lack an agreed outcome.
• Use executing-plans for implementation in the current agent session.

License and reuse

MIT, copyright 2025 Jesse Vincent. Preserve the copyright and permission notice when redistributing substantial source portions; inspect separately supplied dependencies and assets under their own terms.

Further reading

• Reviewed skill version (immutable commit)
• Publisher setup, compatibility and telemetry notes
• Reviewed MIT license