SDD Design Orchestrator
Coordinate specialist skills to produce a complete design document.
Role
| Do |
Don't |
| Create skeleton structure |
Write implementation details |
| Assign sections to specialists |
Make design decisions |
| Map REQs to sections |
Choose libraries or patterns |
| Merge specialist outputs |
Override specialist decisions |
| Resolve conflicts between specialists |
Skip specialist review |
Specialists
| Skill |
Domain |
Invocation |
| sdd-design-frontend |
Component architecture, state, patterns |
After skeleton |
| sdd-design-uiux |
Layout, responsive, accessibility |
After skeleton |
| sdd-design-security |
Threats, sandboxing, validation |
After skeleton |
| sdd-design-perf |
Bundle size, lazy loading, caching |
After skeleton |
Workflow
Phase 1: Skeleton
│
├─→ Phase 2: Specialists (parallel)
│ ├── frontend
│ ├── uiux
│ ├── security
│ └── perf
│
└─→ Phase 3: Merge
Instructions
Phase 1: Create Skeleton
Read requirements document
packages/{package}/spec/{package}.requirements.md
Create design file
packages/{package}/spec/{package}.design.md
Write skeleton using template:
---
title: "{Package} Design"
author: Claude
date: {YYYY-MM-DD}
version: 1.0.0
status: draft
depends_on:
- packages/{package}/spec/{package}.requirements.md@{version}
---
# {Package} Design
## Overview
Brief description of the design approach.
@derives: (list all REQ IDs)
**Status:** draft
## Component Architecture
@derives: {REQ-IDs}
<!-- sdd-design-frontend writes this section -->
**Status:** pending
## UI/UX Design
@derives: {REQ-IDs}
<!-- sdd-design-uiux writes this section -->
**Status:** pending
## Security Considerations
@derives: {REQ-IDs}
<!-- sdd-design-security writes this section -->
**Status:** pending
## Performance Strategy
@derives: {REQ-IDs}
<!-- sdd-design-perf writes this section -->
**Status:** pending
## Decisions Log
| ID | Decision | Rationale | Owner |
|----|----------|-----------|-------|
| | | | |
## Cross-Cutting Concerns
> **Note:** Extension to sdd-guidelines for specialist coordination.
| Concern | Primary | Reviewer | Status |
|---------|---------|----------|--------|
| Accessibility | uiux | frontend | pending |
| Error handling | frontend | security | pending |
| Loading states | uiux | perf | pending |
- Initialize state file
# .sdd/state.yaml (add to existing)
documents:
design:
status: draft
sections:
component-architecture:
status: pending
owner: sdd-design-frontend
uiux:
status: pending
owner: sdd-design-uiux
security:
status: pending
owner: sdd-design-security
perf:
status: pending
owner: sdd-design-perf
Map REQs to sections
Read each requirement and determine which section(s) address it:
| Section |
Typical REQs |
| Component Architecture |
Structure, data flow, patterns |
| UI/UX Design |
Layout, interaction, responsive |
| Security |
User input, code execution, XSS |
| Performance |
Loading, bundle size, caching |
Fill @derives for each section
Phase 2: Invoke Specialists
Invoke all specialists in parallel. Each specialist:
- Reads the skeleton
- Reads assigned REQs
- Writes their section
- Adds decisions to Decisions Log
Invocation format:
Use sdd-design-{specialist} to write the {Section Name} section
for packages/{package}/spec/{package}.design.md
Phase 3: Merge
After all specialists complete:
Collect outputs
- Each specialist's section content
- Decisions added to log
Check conflicts
| Conflict Type |
Detection |
Resolution |
| Library choice |
Same need, different lib |
Perf wins unless security concern |
| Pattern choice |
Same problem, different pattern |
Frontend decides |
| Layout vs Perf |
UX wants X, Perf says too heavy |
UX for primary flow, Perf for edge |
| Any vs Security |
Security flags risk |
Security wins, find alternative |
Review cross-cutting concerns
For each concern:
- Primary owner wrote the approach
- Reviewer validates from their perspective
- Mark status:
approved or needs-revision
Ensure consistency
- Terminology matches across sections
- No contradicting decisions
- All REQs have @derives coverage
Update status
- If no conflicts:
status: verified
- If unresolved:
status: blocked + note
Example: react-sample
Skeleton REQ Mapping
| Section |
REQs |
| Component Architecture |
REQ-REACT-001, 002, 003, 004 |
| UI/UX Design |
REQ-REACT-002, 003, 005 |
| Security Considerations |
REQ-REACT-004 |
| Performance Strategy |
REQ-REACT-003, 004 |
Cross-Cutting for react-sample
| Concern |
Primary |
Reviewer |
Notes |
| Accessibility |
uiux |
frontend |
Keyboard nav for playground |
| Error handling |
frontend |
security |
Editable code errors |
| Loading states |
uiux |
perf |
Code viewer lazy load |
| Code display |
frontend |
perf |
Syntax highlighter choice |
| User input |
frontend |
security |
Props playground inputs |
Verification
After merge:
Conflict Escalation
If specialists can't resolve:
- Document both options in Decisions Log
- Set decision status to
escalated
- Flag for human review:
> ⚠️ **Escalated:** {description}
> Options: A) {option1} B) {option2}
> Blocked until human decision.
References
- reference/section-templates.md — Detailed section structures
1---2name: sdd-design3description: Orchestrate design document creation using specialist skills. Use when: starting design phase, merging specialist outputs, resolving design conflicts. Triggers: "create design", "design phase", "merge design", "design skeleton"4---5
6# SDD Design Orchestrator
7
8Coordinate specialist skills to produce a complete design document.
9
10## Role
11
12| Do | Don't |
13|----|-------|
14| Create skeleton structure | Write implementation details |
15| Assign sections to specialists | Make design decisions |
16| Map REQs to sections | Choose libraries or patterns |
17| Merge specialist outputs | Override specialist decisions |
18| Resolve conflicts between specialists | Skip specialist review |
19
20## Specialists
21
22| Skill | Domain | Invocation |
23|-------|--------|------------|
24| sdd-design-frontend | Component architecture, state, patterns | After skeleton |
25| sdd-design-uiux | Layout, responsive, accessibility | After skeleton |
26| sdd-design-security | Threats, sandboxing, validation | After skeleton |
27| sdd-design-perf | Bundle size, lazy loading, caching | After skeleton |
28
29## Workflow
30
31```
32Phase 1: Skeleton
33 │
34 ├─→ Phase 2: Specialists (parallel)
35 │ ├── frontend
36 │ ├── uiux
37 │ ├── security
38 │ └── perf
39 │
40 └─→ Phase 3: Merge
41```
42
43## Instructions
44
45### Phase 1: Create Skeleton
46
471. **Read requirements document**
48 ```
49 packages/{package}/spec/{package}.requirements.md
50 ```
51
522. **Create design file**
53 ```
54 packages/{package}/spec/{package}.design.md
55 ```
56
573. **Write skeleton** using template:
58
59```markdown
60---
61title: "{Package} Design"
62author: Claude
63date: {YYYY-MM-DD}
64version: 1.0.0
65status: draft
66depends_on:
67 - packages/{package}/spec/{package}.requirements.md@{version}
68---
69
70# {Package} Design
71
72## Overview
73
74Brief description of the design approach.
75
76@derives: (list all REQ IDs)
77
78**Status:** draft
79
80## Component Architecture
81
82@derives: {REQ-IDs}
83
84<!-- sdd-design-frontend writes this section -->
85
86**Status:** pending
87
88## UI/UX Design
89
90@derives: {REQ-IDs}
91
92<!-- sdd-design-uiux writes this section -->
93
94**Status:** pending
95
96## Security Considerations
97
98@derives: {REQ-IDs}
99
100<!-- sdd-design-security writes this section -->
101
102**Status:** pending
103
104## Performance Strategy
105
106@derives: {REQ-IDs}
107
108<!-- sdd-design-perf writes this section -->
109
110**Status:** pending
111
112## Decisions Log
113
114| ID | Decision | Rationale | Owner |
115|----|----------|-----------|-------|
116| | | | |
117
118## Cross-Cutting Concerns
119
120> **Note:** Extension to sdd-guidelines for specialist coordination.
121
122| Concern | Primary | Reviewer | Status |
123|---------|---------|----------|--------|
124| Accessibility | uiux | frontend | pending |
125| Error handling | frontend | security | pending |
126| Loading states | uiux | perf | pending |
127```
128
1294. **Initialize state file**
130
131```yaml
132# .sdd/state.yaml (add to existing)
133documents:
134 design:
135 status: draft
136 sections:
137 component-architecture:
138 status: pending
139 owner: sdd-design-frontend
140 uiux:
141 status: pending
142 owner: sdd-design-uiux
143 security:
144 status: pending
145 owner: sdd-design-security
146 perf:
147 status: pending
148 owner: sdd-design-perf
149```
150
1515. **Map REQs to sections**
152
153 Read each requirement and determine which section(s) address it:
154
155 | Section | Typical REQs |
156 |---------|--------------|
157 | Component Architecture | Structure, data flow, patterns |
158 | UI/UX Design | Layout, interaction, responsive |
159 | Security | User input, code execution, XSS |
160 | Performance | Loading, bundle size, caching |
161
1626. **Fill @derives for each section**
163
164### Phase 2: Invoke Specialists
165
166Invoke all specialists **in parallel**. Each specialist:
167- Reads the skeleton
168- Reads assigned REQs
169- Writes their section
170- Adds decisions to Decisions Log
171
172**Invocation format:**
173```
174Use sdd-design-{specialist} to write the {Section Name} section
175for packages/{package}/spec/{package}.design.md
176```
177
178### Phase 3: Merge
179
180After all specialists complete:
181
1821. **Collect outputs**
183 - Each specialist's section content
184 - Decisions added to log
185
1862. **Check conflicts**
187
188 | Conflict Type | Detection | Resolution |
189 |---------------|-----------|------------|
190 | Library choice | Same need, different lib | Perf wins unless security concern |
191 | Pattern choice | Same problem, different pattern | Frontend decides |
192 | Layout vs Perf | UX wants X, Perf says too heavy | UX for primary flow, Perf for edge |
193 | Any vs Security | Security flags risk | Security wins, find alternative |
194
1953. **Review cross-cutting concerns**
196
197 For each concern:
198 - Primary owner wrote the approach
199 - Reviewer validates from their perspective
200 - Mark status: `approved` or `needs-revision`
201
2024. **Ensure consistency**
203 - Terminology matches across sections
204 - No contradicting decisions
205 - All REQs have @derives coverage
206
2075. **Update status**
208 - If no conflicts: `status: verified`
209 - If unresolved: `status: blocked` + note
210
211## Example: react-sample
212
213### Skeleton REQ Mapping
214
215| Section | REQs |
216|---------|------|
217| Component Architecture | REQ-REACT-001, 002, 003, 004 |
218| UI/UX Design | REQ-REACT-002, 003, 005 |
219| Security Considerations | REQ-REACT-004 |
220| Performance Strategy | REQ-REACT-003, 004 |
221
222### Cross-Cutting for react-sample
223
224| Concern | Primary | Reviewer | Notes |
225|---------|---------|----------|-------|
226| Accessibility | uiux | frontend | Keyboard nav for playground |
227| Error handling | frontend | security | Editable code errors |
228| Loading states | uiux | perf | Code viewer lazy load |
229| Code display | frontend | perf | Syntax highlighter choice |
230| User input | frontend | security | Props playground inputs |
231
232## Verification
233
234After merge:
235
236- [ ] All REQs appear in at least one @derives
237- [ ] No section has placeholder comments
238- [ ] Decisions Log has entries from each specialist
239- [ ] Cross-cutting concerns all `approved`
240- [ ] No contradicting decisions
241- [ ] Frontmatter complete (title, version, depends_on)
242
243## Conflict Escalation
244
245If specialists can't resolve:
246
2471. Document both options in Decisions Log
2482. Set decision status to `escalated`
2493. Flag for human review:
250 ```markdown
251 > ⚠️ **Escalated:** {description}
252 > Options: A) {option1} B) {option2}
253 > Blocked until human decision.
254 ```
255
256## References
257
258- [reference/section-templates.md](reference/section-templates.md) — Detailed section structures