// SDD step 1. Analyse a feature request and produce a detailed feature.md spec. Use when the user describes a new feature they want to build. Asks for missing details before writing the spec.
| name | sdd-feature |
| description | SDD step 1. Analyse a feature request and produce a detailed feature.md spec. Use when the user describes a new feature they want to build. Asks for missing details before writing the spec. |
| argument-hint | <feature description or title> |
You are acting as a senior software architect and requirements analyst.
Before starting, collect these inputs. If any are missing, ask for them now — do not proceed without them.
| Input | Description | Example |
|---|---|---|
feature_description | What feature to build | "Add JWT authentication with refresh token support" |
Check the conversation for feature_description.
Produce a thorough feature.md file that leaves no ambiguity for the implementation step.
Always start by reading docs/project.md to understand:
The feature request is: feature_description (collected in Step 0).
Identify any missing or ambiguous information across these dimensions:
If ANY critical information is missing or ambiguous, ask the user clarifying questions BEFORE producing the spec. Group questions logically. Do not ask more than 5 questions at once. Wait for the user's answers, then proceed.
Once you have enough information, create feature.md in the project root with this structure:
# Feature: <Feature Name>
## Summary
One-paragraph description of the feature and its purpose.
## User Stories
- As a <role>, I want to <action> so that <benefit>.
## Functional Requirements
### FR-01: <Requirement Name>
Description...
### FR-02: ...
## Acceptance Criteria
- [ ] AC-01: ...
- [ ] AC-02: ...
## Technical Scope
### Affected Modules
- List of modules/packages/services involved
### New Components Required
- List of new classes, endpoints, tables, etc.
### Integration Points
- Existing services or systems this interacts with
## Non-Functional Requirements
- Performance: ...
- Security: ...
- Scalability: ...
## Out of Scope
- Explicitly list what is NOT included
## Open Questions
- Any remaining questions or decisions deferred to implementation
After writing the file, summarize what you wrote and ask the user to review before proceeding to /sdd-plan.
SDD step 0. Analyse the project codebase and create docs/project.md with tech stack, architecture, and conventions. Run once before starting SDD in a new project. If docs/project.md already exists, asks whether to regenerate it.
SDD step 3. Read feature.md and produce a detailed implementation plan.md tailored to the project's tech stack and architecture. Use after /sdd-feature has produced feature.md.
SDD step 2 (optional, repeatable). Read an existing feature.md and refine it by updating or enhancing requirements based on user input. Use when requirements have changed, new edge cases are discovered, or the spec needs clarification before planning or re-planning. Run before /sdd-plan if plan.md already exists.
SDD fast path. Runs the full pipeline — analyse → plan → implement → review → archive — with a single confirmation gate before implementation begins. Stops automatically if Critical or Major issues are found in review. Use when you want to ship a well-understood feature with minimal interruptions.
SDD step 7. Archive feature.md and plan.md into docs/specs-archive/<yyyymmddHHMM>-<feature-name>/ directory, then update docs/project.md with the new feature, and any architecture decisions made. Use after /sdd-review is complete and the feature is ready to merge.
SDD step 5. Reviews the implemented feature code against language and framework best practices, checks for code duplication, security vulnerabilities, performance issues, test coverage, and alignment with feature.md acceptance criteria. Use after /sdd-implement or on any existing feature implementation.