77 lines
2.0 KiB
Markdown
77 lines
2.0 KiB
Markdown
---
|
|
description: Create a technical design document for a feature
|
|
argument-hint: <feature-slug>
|
|
allowed-tools: Bash, Read, Write, Edit, Glob, Grep
|
|
---
|
|
|
|
Create a technical design for feature: $ARGUMENTS
|
|
|
|
## Instructions
|
|
|
|
### 1. Load Feature and Spec
|
|
|
|
```bash
|
|
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:
|
|
|
|
```markdown
|
|
# 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
|
|
|
|
```bash
|
|
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
|