Skip to content

/spec-refine

Update requirements or architecture design for an existing spec. Use this when requirements change, new edge cases are discovered, or the design needs revision after implementation has started.

Usage

/spec-refine

No arguments — the command detects available specs and prompts you to select one if multiple exist.

Arguments

Argument Required Description
(none) — The command is interactive. Select the spec and describe changes when prompted.

What It Does

  1. Identifies the spec to refine — lists specs in .claude/specs/. If only one exists, it is selected automatically. If multiple exist, you are asked to choose.

  2. Reads the current spec — loads both requirements.md and design.md so Claude has full context before asking what needs to change.

  3. Gathers refinements — asks what needs updating: new requirements to add, existing ones to modify or remove, design changes, new components or APIs.

  4. Updates requirements — adds new user stories with EARS acceptance criteria, modifies existing stories, and marks removed requirements as deprecated rather than deleting them. Change history is preserved.

  5. Updates design — if requirements changed, reviews impacted components, updates architecture descriptions, data models, API specifications, and sequence diagrams.

  6. Flags task impact — after updating the spec, identifies which existing tasks may be affected and suggests running /spec-tasks to regenerate the task list.

Example

/spec-refine

Then follow the prompts: select your spec, describe what changed (e.g., "we need to support OAuth in addition to email/password"), and Claude updates the documents.

Tips

  • Preserve change history — add notes about what changed and why. This context is valuable during implementation and retrospectives.
  • After any significant requirement change, always review the design for consistency.
  • After design changes, always regenerate tasks with /spec-tasks to keep implementation in sync.
  • Deprecated requirements should stay in the document (marked deprecated) rather than be deleted — they explain why certain design decisions were made.

Note

Refinements cascade: requirements changes may require design updates, which in turn require task updates. Work top-down and run /spec-tasks at the end.

See Also

  • /spec-tasks — Regenerate tasks after refining requirements or design
  • /spec-validate — Validate the updated spec before continuing implementation
  • /spec-status — Check which tasks may be affected by the changes