stdd-planninglisted

Turn an agreed behavior contract into an executable, verifiable sequence of work. Use when: The behavior contract is agreed (docs edit drafted or committed) and the change is large enough to need ordered steps — before the first implementation edit, to fix the execution mode and the closing review.
vsem-azamat/stdd · ★ 0 · Testing & QA · score 72

Install: claude install-skill vsem-azamat/stdd

# Planning A plan is a disposable working artifact: it guides one execution and is thrown away. It is never committed as a file — its home is the PR description (for the durable summary) and `.stdd/plan.md` (for the working copy: per checkout, gitignored, read by `stdd status`, survives compaction). Write the plan for an executor with zero context and questionable taste: exact file paths, exact names, exact commands. The planning session's memory does not survive delegation or compaction — whatever the plan does not say, the executor does not know. ## Structure A good plan has, in order: 1. **Intent** — one paragraph: the problem and the agreed direction. 2. **Docs delta** — which permanent docs change and how (added / modified / removed rules, named per target file). This is the spec surface of the plan; keep it exact so the docs edit is mechanical. 3. **Global constraints** — the agreement's project-wide requirements (version floors, naming and copy rules, platform limits), one line each, exact values verbatim. Every step implicitly includes this section; a delegated worker gets it copied into the brief. 4. **Steps** — each step small enough to verify independently, written as checkboxes (`- [ ]`) so `stdd status` can report progress and the next open item. Per step: - what changes (files, functions); - the failing test that gates it (or the visual check, for frontend