Menu
Write the technical design for a planned change: components, interfaces, data flows, edge cases.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Dual-model adversarial review: local and delegated reviewers audit independently, verdicts are synthesized.
Implement the SDD task list. Read tasks and design from memory, write code, run tests.
Archive all SDD artifacts for a change as a single completed record in memory.
Explore the codebase to build context for a planned change. First phase of the SDD workflow.
Propose 2–3 solution approaches for a planned change, evaluating trade-offs and recommending one.
Write a formal specification for a planned change: goals, acceptance criteria, constraints.
| name | sdd-design |
| description | Write the technical design for a planned change: components, interfaces, data flows, edge cases. |
| compatibility | opencode |
| when_to_use | After sdd-spec. Reads spec and proposal from memory, produces a technical design. |
| allowed-tools | ["Read","mcp__n3rv-memory__memory_recall","mcp__n3rv-memory__memory_save"] |
| model | medium |
| effort | medium |
| user-invocable | false |
Produce a technical design that tells an implementer how to build what the spec describes. Bridge between the spec's what and the code's how.
memory_recall(topic_key="sdd-<change_id>-spec")memory_recall(topic_key="sdd-<change_id>-proposal")SDD Design: <change_id>sdd-<change_id>-designarchitecture## Components
<new or modified modules, classes, functions>
## Interfaces
<public API changes, function signatures, data models>
## Data Flow
<how data moves through the system for this change>
## Error Handling
<failure modes and how they are handled>
## Edge Cases
<boundary conditions, concurrency, empty input, large input>
## Dependencies
<new packages, external services, migration requirements>
## Testing Strategy
<unit tests needed, integration tests, fixtures>