2.0 KiB
2.0 KiB
| description | argument-hint | allowed-tools |
|---|---|---|
| Create a technical design document for a feature | <feature-slug> | Bash, Read, Write, Edit, Glob, Grep |
Create a technical design for feature: $ARGUMENTS
Instructions
1. Load Feature and Spec
sdlc feature show $ARGUMENTS --json
Read .sdlc/features/$ARGUMENTS/spec.md. The spec MUST exist and be approved before designing.
2. Analyze Existing Patterns
Search the codebase for:
- Similar features or modules already implemented
- Data models that will be extended or referenced
- API patterns currently in use
- Error handling conventions
- Test patterns for comparable components
3. Write the Design Document
Write to .sdlc/features/$ARGUMENTS/design.md with this structure:
# Design: [Feature Title]
## Architecture Approach
[High-level approach: which layers change, what is new vs modified]
## Data Model Changes
[New types, schema changes, migration requirements]
## API Changes
[New endpoints, modified contracts, request/response shapes]
## Component Diagram
[Text diagram showing how components interact]
## Error Handling Strategy
[Expected failure modes and how each is handled]
## Security Considerations
[Auth, input validation, data exposure, access control]
## Performance Considerations
[Expected load, caching strategy, query complexity]
## Migration / Rollout Plan
[How to ship without breaking existing functionality]
4. Register the Artifact
sdlc artifact create $ARGUMENTS design
5. Report
Summarize the design approach, list key decisions made, and flag any areas that need human review or approval.
Critical Rules
- ALWAYS read the spec before designing -- the design must satisfy the spec
- NEVER design without understanding existing patterns in the codebase
- ALWAYS consider error handling -- every external call can fail
- ALWAYS address security -- auth, validation, data boundaries
- NEVER invent new patterns when existing ones fit