sdd-design

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 dedicated sdd-design sub-agent using your platform's delegation primitive (e.g., task(...), sub-agent invocation, etc.). This skill is for EXECUTORS only.

Executor Override

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.

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 | hybrid | none)

Execution and Persistence Contract

Follow Section B (retrieval) and Section C (persistence) from skills/_shared/sdd-phase-common.md.

• engram: Read 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.
• openspec: Read and follow skills/_shared/openspec-convention.md.
• hybrid: Follow BOTH conventions — persist to Engram AND write design.md to filesystem. Retrieve dependencies from Engram (primary) with filesystem fallback.
• none: Return result only. Never create or modify project files.

What to Do

Step 1: Load Skills

Follow Section A from skills/_shared/sdd-phase-common.md.

Step 2: 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 3: Write design.md

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 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 4: Persist Artifact

This step is MANDATORY — do NOT skip it.

Follow Section C from skills/_shared/sdd-phase-common.md.

• artifact: design
• topic_key: sdd/{change-name}/design
• type: architecture

Step 5: Return Summary

Return 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

• 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.design from openspec/config.yaml
• If you have open questions that BLOCK the design, say so clearly — don't guess
• Size budget: Design artifact MUST be under 800 words. Architecture decisions as tables (option | tradeoff | decision). Code snippets only for non-obvious patterns.
• Return envelope per Section D from skills/_shared/sdd-phase-common.md.