| name | sdlc-specify |
| description | Phase 1 of the SDLC. Use this to capture WHAT a feature does and WHY it exists, before any technical design. Triggers when the user describes a new feature, requirement, user story, or problem to solve. Produces specs/<feature>/spec.md focused on user value and acceptance criteria, deliberately avoiding implementation details. Reads memory/constitution.md first. |
Phase 1 — Specify (WHAT & WHY)
Capture intent, not implementation. This artifact is read by every later phase.
Preconditions
memory/constitution.md must exist. If not, route to /constitution.
Process
- Recall related prior specs via
memory-manager (avoid duplicating existing features).
- Interview the user one question at a time. Resolve every
[NEEDS CLARIFICATION] — do
not guess on ambiguous requirements; ask.
- Write
specs/<feature-slug>/spec.md from templates/spec.template.md.
What goes in spec.md
- User story / problem — who, what pain, what outcome.
- Functional requirements — numbered, each testable.
- Acceptance criteria — Given/When/Then; these become the review checklist later.
- Out of scope — explicit non-goals.
- UI surface? — yes/no flag that tells the orchestrator whether
/design runs.
What must NOT go in spec.md
- No tech stack, frameworks, schemas, or API shapes. Those belong in
/plan.
Exit
Write .sdlc/state.json (phase=specify, artifact=spec path). Persist memory checkpoint.
Tell the user: "Spec ready. Next: /plan."
Примітка (UK)
Специфікація описує цінність для користувача та критерії приймання — без жодних
технічних рішень. Якщо вимога неоднозначна — постав питання, не вгадуй.
