speci5.plan

Plan

Read a story spec and create a concrete implementation plan.

Start by understanding the story and the codebase, then produce specific, actionable tasks. Only ask questions if the spec has genuine ambiguities that would lead to a wrong plan.

<HARD-GATE> Do NOT implement code, modify specs, create features, or brainstorm ideas. This skill ONLY produces plan files in .spec/features/<feature>/<story>/plan.md. </HARD-GATE>

Triggers

Activate this skill when the user wants to:

• Create an implementation plan for a story
• Break a story into concrete development tasks
• Understand what needs to be built for a story
• Update an existing plan with revised tasks

Rules

1. Tasks must be specific and actionable — not vague ("implement feature") but concrete ("Create POST /api/auth/login route in src/routes/auth.ts").
2. Include unit test tasks as a first-class part of every plan (not optional). Tie each test task to acceptance criteria and existing test conventions.
3. If a plan.md already exists, update it — preserve any checked-off tasks and add/revise remaining ones.
4. Do NOT modify story.md or feature.md — those are the specify skill's domain.
5. Do NOT implement the code — only produce the plan.
6. YAGNI ruthlessly — Every task must tie back to an acceptance criterion. If it doesn't serve the story, leave it out.
7. Be tech-stack-specific: reference the actual frameworks, libraries, runtime, test runner, and folder conventions found in the target codebase. Avoid generic wording.

Conversation Style

• Bias toward action. If the story and codebase give enough information, produce the plan directly.
• Only ask when genuinely blocked — ambiguous acceptance criteria, multiple conflicting interpretations, or a technical decision with no clear answer.
• One question at a time if you do need to ask.
• Prefer multiple choice when possible.

Steps

1. Read the story — Load .spec/features/<feature>/<story>/story.md.
2. Read the feature — Load the parent feature.md for broader context.
3. Analyze the codebase — Go beyond the story. Understand:
4. Project structure, tech stack, and conventions.
5. Unit testing setup (test framework, mocking tools, naming/file patterns, test commands, coverage expectations).
6. What related code already exists.
7. Where new code should be placed.
8. Existing patterns to follow (routing conventions, test structure, naming, etc.).
9. Check scope — If the story is too large or covers multiple independent concerns, flag it. Help decompose into smaller stories before planning. Each plan should be completable in a focused session.
10. Ask clarifying questions (only if needed) — If acceptance criteria are genuinely ambiguous or a technical decision has no clear answer from the codebase, ask. Otherwise, proceed.
11. Propose 2-3 implementation approaches — Present different strategies with trade-offs (e.g., new module vs. extending existing, library vs. hand-rolled). Lead with your recommendation and explain why. Include testing implications for each approach.
12. Write the plan — Once aligned with the user, write ordered, actionable tasks to .spec/features/<feature>/<story>/plan.md.
13. Include explicit unit test tasks with concrete test file paths, test case intent, and the project's actual test tooling.
14. Include validation task(s) that run the relevant project test command(s) (for example, targeted test file command and/or package script used in this repo).
15. Present for review — Show the plan and confirm it looks right before considering the job done.

Output Format

See [output template](./assets/output.md).