---
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