ss-plan

Build Execution Plan

Decompose a requirement or technical proposal into an executable, task-level implementation plan. Each task must be small enough for a single agent to complete independently, with explicit dependencies, exact file paths, and verification criteria.

Language of the plan: write the plan's prose in the same language as the input document (or the project's existing docs, if that's a clearer signal); default to English when neither gives a signal. Code, commands, and file paths always stay in their original form regardless of prose language.

Zero-context assumption: write the plan as if the executor has zero knowledge of the codebase and limited design taste. Every task must be fully self-contained — the executor should never need to "figure out" what to do. If a step changes code, show the code. If a step runs a command, show the command and its expected output.

Inputs

One of:

• A link to a requirement or proposal document that your document-reading tool can fetch.
• A local Markdown file path.
• Plain text describing the requirement directly.

If the input is missing or too thin to extract a goal, scope, and acceptance criteria, ask the user rather than guessing.

Iron Rules

Violating any of these means stop and start over:

1. Comprehend before planning — do not start decomposing until the entire input is read and understood. Skipping this voids the plan.
2. Never guess — if the input is ambiguous or missing information, ask the user. Do not assume and continue.
3. No placeholders — see "No Placeholders" below for the full list of forbidden patterns.
4. Every task must be independently verifiable, and acceptance traces to the spec — each task ends with a concrete acceptance command and expected output. When Phase 0 produced delta specs, the acceptance MUST cover a named Scenario from that delta (the Scenario is the single source of truth for expected behavior) — do not author parallel, independent acceptance prose that restates the Scenario.
5. Exact file paths — every referenced file is a real path from the project root. No vague descriptions.
6. TDD-driven — code tasks have test steps before implementation steps.
7. DRY / YAGNI — do not plan features that weren't requested; do not add abstraction layers for hypothetical future needs.
8. Self-contained tasks — each task produces a change that makes sense on its own, and the project still compiles/runs after it. Never write "similar to Task N" — repeat the code, since executors may work tasks out of order.
9. Plan the full scope, no unauthorized reduction — the plan must cover every requirement point in the input. Never defer work to "phase 2 / a later iteration / future enhancement," plan only an "MVP / P0 / core" subset, or quietly downgrade a requirement. Splitting the plan (see Scope Check) changes delivery packaging, not scope — every sub-plan still gets written. If the full scope can't be planned, stop and ask the user. The only valid reduction is one the user explicitly requested — record it in the plan header's "User-Confirmed Scope Adjustments" section, which downstream review also reads.