Generate TDD implementation plans for zero-context engineers

Writing Plans turns an existing specification or set of requirements into a detailed implementation plan before code changes begin. It assumes the implementing engineer understands development but lacks context about the repository, tools, and problem domain. The plan therefore records exact files, code, tests, relevant documentation, commands, and expected results rather than leaving broad instructions for someone else to interpret.

The workflow favors small tasks, minimal implementation, reduced duplication, and frequent commits. Its prescribed rhythm separates writing a failing test, confirming the failure, implementing the smallest change, rerunning the test, and committing the result. Those are planning instructions, not evidence that implementation or tests have already occurred.

Use it when requirements are sufficiently defined and a multi-step change needs an actionable handoff. It is helpful when the next engineer cannot rely on conversation history to understand what to edit or how to validate the result. Prepare a dedicated worktree through the preceding brainstorming workflow.

Do not treat a saved plan as a completed feature or use generic placeholders as a substitute for repository-specific investigation. Include complete code and exact commands in the finished plan. Its example paths, functions, and expected failures illustrate structure and must be replaced with facts from the actual project.

Inputs are the specification, requirements, repository context, relevant architecture, technology stack, and validation expectations. The output is a Markdown document under docs/plans using a date and feature name. Its header states the goal, architecture, and technology stack, and identifies the execution workflow expected to implement the plan.

Each task lists files to create, modify, and test. Each step is one concrete action, with code where needed and the command and expected result for verification. An illustrative test step is:

Run: `pytest tests/path/test.py::test_name -v`

The finished plan should explain what the test proves and distinguish the expected initial failure from the later passing result. Documentation and relevant skill references belong in the task where they will be needed. The stated two-to-five-minute granularity is a planning target, not a delivery estimate for an unknown feature.

Choose between two execution handoffs: task-by-task work in the current session with fresh subagents and review, or a separate execution session with checkpoints. These rely on named superpowers workflows and a worktree context; their mention does not establish that those helpers are installed in every environment.

This skill supports engineers preparing implementation instructions for another developer or a later execution session. Its value is the reviewable specificity of the plan and validation steps before changes begin.