with one click
sdd-design
// Create the SDD technical design and architecture approach. Trigger: orchestrator launches design for a change.
// Create the SDD technical design and architecture approach. Trigger: orchestrator launches design for a change.
Trigger: judgment day, dual review, adversarial review, juzgar. Run blind dual review, fix confirmed issues, then re-judge.
Write warm, direct collaboration comments. Trigger: PR feedback, issue replies, reviews, Slack messages, or GitHub comments.
Shared SDD references for installed skills. Not invokable.
Archive a completed SDD change by syncing delta specs. Trigger: orchestrator launches archive after implementation and verification.
Explore SDD ideas before committing to a change. Trigger: orchestrator launches exploration or requirement clarification.
Trigger: sdd init, iniciar sdd, openspec init. Initialize SDD context, testing capabilities, registry, and persistence.
| name | sdd-design |
| description | Create the SDD technical design and architecture approach. Trigger: orchestrator launches design for a change. |
| disable-model-invocation | true |
| user-invocable | false |
| license | MIT |
| metadata | {"author":"gentleman-programming","version":"2.0","delegate_only":true} |
ORCHESTRATOR GATE: If you loaded this skill via the
skill()tool, you are the ORCHESTRATOR ā STOP. Do NOT execute these instructions inline. Delegate to the dedicatedsdd-designsub-agent using your platform's delegation primitive (e.g.,task(...), sub-agent invocation, etc.). This skill is for EXECUTORS only.
If you ARE the sdd-design sub-agent (NOT the orchestrator), the gate above does NOT apply to you. Continue with the phase work below. Do NOT delegate. Do NOT call the Skill tool. You are the executor ā execute.
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.
From the orchestrator:
engram | openspec | hybrid | none)Follow Section B (retrieval) and Section C (persistence) from
skills/_shared/sdd-phase-common.md.
sdd/{change-name}/proposal (required) and sdd/{change-name}/spec (optional ā may not exist if running in parallel with sdd-spec). Save as sdd/{change-name}/design.skills/_shared/openspec-convention.md.design.md to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback.Follow Section A from skills/_shared/sdd-phase-common.md.
Before designing, read the actual code that will be affected:
IF mode is openspec or hybrid: Create the design document:
openspec/changes/{change-name}/
āāā proposal.md
āāā specs/
āāā design.md ā You create this
IF mode is engram or none: Do NOT create any openspec/ directories or files. Compose the design content in memory ā you will persist it in Step 4.
# 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}
This step is MANDATORY ā do NOT skip it.
Follow Section C from skills/_shared/sdd-phase-common.md.
designsdd/{change-name}/designarchitectureReturn to the orchestrator:
## Design Created
**Change**: {change-name}
**Location**: `openspec/changes/{change-name}/design.md` (openspec/hybrid) | Engram `sdd/{change-name}/design` (engram) | inline (none)
### 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.design from openspec/config.yamlskills/_shared/sdd-phase-common.md.