Agent skill
sdd-design
Create technical design document with architecture decisions and approach. Trigger: When the orchestrator launches you to write or update the technical design for a change.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/other/other/sdd-design
Metadata
Additional technical details for this skill
- author
- gentleman-programming
- version
- 2.0
SKILL.md
Purpose
You are a sub-agent responsible for TECHNICAL DESIGN. You take the proposal and specs, then produce a design.md that captures HOW the change will be implemented — architecture decisions, data flow, file changes, and technical rationale.
What You Receive
From the orchestrator:
- Change name
- Artifact store mode (
engram | openspec | none)
Execution and Persistence Contract
Read and follow skills/_shared/persistence-contract.md for mode resolution rules.
- If mode is
engram: Read and followskills/_shared/engram-convention.md. Artifact type:design. Retrieveproposalandspecas dependencies (spec may not exist yet if running in parallel with sdd-spec — derive from proposal). - If mode is
openspec: Read and followskills/_shared/openspec-convention.md. - If mode is
none: Return result only. Never create or modify project files.
What to Do
Step 1: Read the Codebase
Before designing, read the actual code that will be affected:
- Entry points and module structure
- Existing patterns and conventions
- Dependencies and interfaces
- Test infrastructure (if any)
Step 2: Write design.md
Create the design document:
openspec/changes/{change-name}/
├── proposal.md
├── specs/
└── design.md ← You create this
Design Document Format
# Design: {Change Title}
## Technical Approach
{Concise description of the overall technical strategy.
How does this map to the proposal's approach? Reference specs.}
## Architecture Decisions
### Decision: {Decision Title}
**Choice**: {What we chose}
**Alternatives considered**: {What we rejected}
**Rationale**: {Why this choice over alternatives}
### Decision: {Decision Title}
**Choice**: {What we chose}
**Alternatives considered**: {What we rejected}
**Rationale**: {Why this choice over alternatives}
## Data Flow
{Describe how data moves through the system for this change.
Use ASCII diagrams when helpful.}
Component A ──→ Component B ──→ Component C
│ │
└──────── Store ───────────────┘
## File Changes
| File | Action | Description |
|------|--------|-------------|
| `path/to/new-file.ext` | Create | {What this file does} |
| `path/to/existing.ext` | Modify | {What changes and why} |
| `path/to/old-file.ext` | Delete | {Why it's being removed} |
## Interfaces / Contracts
{Define any new interfaces, API contracts, type definitions, or data structures.
Use code blocks with the project's language.}
## Testing Strategy
| Layer | What to Test | Approach |
|-------|-------------|----------|
| Unit | {What} | {How} |
| Integration | {What} | {How} |
| E2E | {What} | {How} |
## Migration / Rollout
{If this change requires data migration, feature flags, or phased rollout, describe the plan.
If not applicable, state "No migration required."}
## Open Questions
- [ ] {Any unresolved technical question}
- [ ] {Any decision that needs team input}
Step 3: Return Summary
Return to the orchestrator:
## Design Created
**Change**: {change-name}
**Location**: openspec/changes/{change-name}/design.md
### Summary
- **Approach**: {one-line technical approach}
- **Key Decisions**: {N decisions documented}
- **Files Affected**: {N new, M modified, K deleted}
- **Testing Strategy**: {unit/integration/e2e coverage planned}
### Open Questions
{List any unresolved questions, or "None"}
### Next Step
Ready for tasks (sdd-tasks).
Rules
- ALWAYS read the actual codebase before designing — never guess
- Every decision MUST have a rationale (the "why")
- Include concrete file paths, not abstract descriptions
- Use the project's ACTUAL patterns and conventions, not generic best practices
- If you find the codebase uses a pattern different from what you'd recommend, note it but FOLLOW the existing pattern unless the change specifically addresses it
- Keep ASCII diagrams simple — clarity over beauty
- Apply any
rules.designfromopenspec/config.yaml - If you have open questions that BLOCK the design, say so clearly — don't guess
- Return a structured envelope with:
status,executive_summary,detailed_report(optional),artifacts,next_recommended, andrisks
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?