Specification

Define requirements formally using spec-driven development. This workflow produces a structured specification with acceptance criteria, edge cases, and constraints before any implementation begins.

When to Use This

• You need a formal specification before implementation (common for larger features).
• Multiple team members need to agree on requirements before coding starts.
• You want structured acceptance criteria to validate the implementation against.
• The feature has complex requirements that need to be documented clearly.

What You'll Use

Walkthrough

Scenario: Define requirements for a user notification system.

Step 1: Bootstrap the Workflow

Run /speckit-startup at the beginning of the session. This initializes the spec-driven development context and optionally loads a project constitution (principles and constraints).

Step 2: Write the Specification

Run /speckit-specify and describe the feature:

"We need a notification system that alerts users about important events: new messages, task assignments, and system updates. Users should be able to configure which notifications they receive and how (email, in-app, push)."

Claude produces a structured specification including:

• Overview — What the system does and why
• Requirements — Functional and non-functional requirements
• Acceptance criteria — Testable conditions for each requirement
• Edge cases — What happens with no notifications, bulk events, offline users
• Constraints — Performance targets, notification delivery SLA, storage limits

Step 3: Clarify Ambiguities

Run /speckit-clarify to resolve any gaps:

• Should notifications be real-time or batched?
• What is the retention period for in-app notifications?
• How should notification preferences sync across devices?

Claude updates the spec with each clarification.

Step 4: Generate the Implementation Plan

Once the spec is complete, run /speckit-plan to produce an implementation plan. This includes architecture decisions, file changes, database schema, and API design — all derived from the specification.

Quick Reference

Tips

• Spec-kit's pipeline is sequential: specify, clarify, plan. Follow the order for best results.
• Use /speckit-constitution once per project to define principles that guide all specs (e.g., "all APIs must be versioned").
• /speckit-analyze can audit an existing spec for completeness without rewriting it.
• Spec-kit pairs with superpowers: use spec-kit for specification, then superpowers' /write-plan and /execute-plan for implementation.

See Also

• spec-kit plugin — Full plugin documentation
• Brainstorming workflow — Previous step: explore the idea
• Planning workflow — Next step: break the spec into tasks