Sdd Design

Execution Role

Confirm your role before acting. You are the dedicated sdd-design sub-agent unless you loaded this skill directly through the skill() tool.

• If you are the sdd-design sub-agent, continue with the phase work below. Do not delegate. Do not call the Skill tool.
• If you loaded this skill through the skill() tool, you are the orchestrator. Stop here and delegate to the dedicated sdd-design sub-agent using your platform's delegation primitive (for example, task(...) or a sub-agent invocation).

Language Domain Contract

Generated technical artifacts default to English. Do not inherit the user's conversational language or the active persona's regional voice for SDD artifacts unless the user explicitly requests that artifact language or the project convention requires it.

If technical artifacts are explicitly requested in another language, use a neutral/professional register unless the user explicitly requests a different tone or regional variant.

Public/contextual comments follow the target context language by default. Explicit user language or tone overrides win; otherwise use a neutral/professional register unless the target context clearly calls for another tone or regional variant.

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 2a: Applicability-Driven Threat Matrix

If the design changes routing, shell commands, subprocesses, VCS/PR automation, executable-file classification, or process integration, read references/threat-matrix.md and include its matrix in the design. Mark every row Applicable or explicit N/A with a reason. Define expected safe/failure behavior and planned RED tests for every applicable case. If none of these boundaries exists, record the matrix as not applicable; do not manufacture irrelevant tasks.

Step 3: Write design.md

IF mode is openspec or hybrid: Create the design document:

Copy code
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

markdownCopy code
# 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} |

## Threat Matrix

{For routing/shell/process integration, include the applicability matrix from `references/threat-matrix.md`. Otherwise: `N/A — no routing, shell, subprocess, VCS/PR automation, executable-file classification, or process-integration boundary.`}

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

markdownCopy code
## 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
• Sufficient detail: Include enough detail to explain decisions, alternatives, rationale, interfaces and testing. Use tables or code snippets where they clarify non-obvious behavior. Do not truncate required detail to meet a word or line cap.
• Applicable threat-matrix rows are design requirements and MUST propagate to tasks and RED tests unchanged; explicit N/A rows require no task.
• Return envelope per Section D from skills/_shared/sdd-phase-common.md.

References

• references/threat-matrix.md — load only for routing, shell, subprocess, VCS/PR automation, executable-file classification, or process-integration designs.