sdd-design

Original：🇺🇸 English

Translated

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.

2installs

Sourcegentleman-programming/sdd-agent-team

Added on2026-03-05

NPX Install

npx skill4agent add gentleman-programming/sdd-agent-team sdd-design

SKILL.md Content

View Translation Comparison →

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 follow
```
skills/_shared/engram-convention.md
```
. Artifact type:
```
design
```
. Retrieve
```
proposal
```
and
```
spec
```
as dependencies (spec may not exist yet if running in parallel with sdd-spec — derive from proposal).

If mode is

openspec

: Read and follow

skills/_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

markdown

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