Menu
Write a formal specification for a planned change: goals, acceptance criteria, constraints.
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.
Write the technical design for a planned change: components, interfaces, data flows, edge cases.
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.
| name | sdd-spec |
| description | Write a formal specification for a planned change: goals, acceptance criteria, constraints. |
| compatibility | opencode |
| when_to_use | After sdd-propose. Reads the proposal from memory, writes a spec. |
| allowed-tools | ["Read","mcp__n3rv-memory__memory_recall","mcp__n3rv-memory__memory_save"] |
| model | medium |
| effort | medium |
| user-invocable | false |
Produce a specification document that defines exactly what the change must do — precise enough that a reviewer can verify the implementation against it without ambiguity.
memory_recall(topic_key="sdd-<change_id>-proposal")memory_recall(topic_key="sdd-<change_id>-context")SDD Spec: <change_id>sdd-<change_id>-speccontext## Goals
<what this change achieves>
## Non-Goals
<explicit exclusions — what this change does NOT do>
## Acceptance Criteria
- [ ] <testable criterion 1>
- [ ] <testable criterion 2>
...
## Constraints
<technical, operational, backward-compatibility requirements>
## Out of Scope
<related work deferred to a future change>
Every acceptance criterion must be testable — binary pass/fail, no judgment calls.