internal/assets/skills/sdd-design/SKILL.md
Create the SDD technical design and architecture approach. Trigger: orchestrator launches design for a change.
npx skillsauth add gentleman-programming/gentle-ai sdd-designInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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 Spanish technical artifacts are explicitly requested, use neutral/professional Spanish unless the user explicitly asks for a regional variant.
Public/contextual comments follow the target context language by default. Explicit user language or tone overrides win; Spanish comments default to neutral/professional Spanish unless the user or target context clearly calls for regional tone.
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.tools
Shared SDD references for installed skills. Not invokable.
tools
<!-- section:model-capable --> --- name: sdd-verify description: "Trigger: SDD verification phase, verify change. Execute tests and prove implementation matches specs, design, and tasks." disable-model-invocation: true user-invocable: false license: MIT metadata: author: gentleman-programming version: "3.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
documentation
Write SDD delta specs with requirements and scenarios. Trigger: orchestrator launches spec work for a change.
tools
Create an SDD change proposal with intent, scope, and approach. Trigger: orchestrator launches proposal work for a change.