From sdd-triad
Help write or improve a specification document for the SDD Triad (spec-driven proposal system). Guides the user through hard constraints, soft constraints, proposal format, and static evaluation metrics — and checks the result for common weaknesses. Use when the user says "write an SDD spec", "help me write a spec", "create a spec for the triad", "improve my spec", "check my spec", or "spec review".
How this skill is triggered — by the user, by Claude, or both
Slash command
/sdd-triad:sdd-spec-writerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Help the user author or improve a specification document that will be consumed by the `sdd-writer` agent inside the SDD Triad loop. A good spec produces better proposals in fewer rounds. A vague spec produces proposals that stall.
Help the user author or improve a specification document that will be consumed by the sdd-writer agent inside the SDD Triad loop. A good spec produces better proposals in fewer rounds. A vague spec produces proposals that stall.
The spec is the writer agent's primary input. The writer never sees the evaluation scenarios. Everything the writer needs to produce a valid proposal must be in the spec. If information is missing, the writer will guess or the loop will stall.
The spec is not where use cases, stress tests, or evaluation scenarios belong — those go in a separate scenarios file (see sdd-scenario-writer).
Walk the user through each section. Ask questions to draw out specifics. Push back on vague or qualitative language.
Everything a valid proposal must satisfy. Subdivide by domain if there are many (structural, functional, boundary conditions, personnel rules, etc.).
Quality bar: every requirement must be falsifiable — you can say clearly whether a proposal passes or fails it.
Good:
Bad:
When the user offers a vague requirement, ask: "How would you know whether a proposal passes or fails this? What number or condition makes it pass?"
The exact sections and content a valid proposal must include. The writer follows this literally — it is the deliverable definition.
State every required heading and what it must contain. If the user says "just produce a proposal," push back: "The writer will follow the format section exactly. If it's vague, you'll get proposals in unpredictable shapes. What sections do you want to see?"
Pass/fail criteria the writer self-checks against before returning. These are pre-flight checks the writer should be able to verify from the spec and context alone.
Each metric needs: an ID, a name, and an unambiguous pass condition.
Examples:
M-01 Span compliance: every manager has 5–15 direct reportsM-02 Period minimum: no custody period is shorter than 7 daysM-03 Day ceiling: actual days ≤ 25The writer includes a self-check table at the end of every proposal scoring itself against these metrics. If a metric is vague, the writer will always mark it green. Make metrics testable.
These belong in the scenarios file. If the user starts putting them in the spec, flag it:
Tell the user: "That sounds like a scenario, not a requirement. If you put it in the spec, the writer sees the test — that breaks the information barrier. Move it to your scenarios file."
Your job is not to transcribe what the user says — it is to draw out what they haven't said yet. The user knows their domain; you know what makes a spec work. Interview them like a curious, rigorous collaborator.
Use these throughout the interview. They are not a script — deploy them when the conversation calls for them.
Boundary probes — find the edges of a constraint:
Assumption surfacing — expose what the user takes for granted:
Consequence probes — test whether a constraint matters:
Completeness probes — find what's missing:
Definition probes — force precision on ambiguous terms:
Conduct the interview in four phases. Each phase has a goal, opening questions, and follow-up patterns. Do not rush through phases — stay in each one until you have concrete, testable material.
Phase 1: Domain orientation
Phase 2: Constraint discovery
Phase 3: Proposal format
Phase 4: Static metrics
After all four phases, run the quality checklist. Then write the spec.
Run this against every spec before finalizing. Report each item as pass or fail with a note.
| # | Check | Pass condition |
|---|---|---|
| 1 | Every requirement is falsifiable | You can say clearly whether a proposal passes or fails it — no qualitative-only language |
| 2 | Requirements use testable thresholds | Numbers, conditions, or formulas — not vibes ("reasonable", "effective", "minimize") |
| 3 | Proposal format names every heading | Each required section is listed with what it must contain |
| 4 | Proposal format is explicit | "Produce a proposal" is not a format definition |
| 5 | Static metrics have IDs and pass conditions | Each metric has an ID (M-01, etc.) and an unambiguous pass condition |
| 6 | No scenario content in the spec | No use cases, stress tests, sensitivity analyses, or health metrics |
| 7 | No overlap with scenarios | If the user has a scenarios file, check that requirements don't duplicate scenario content |
| 8 | Hard vs soft constraints are separated | Hard constraints are non-negotiable facts; soft constraints are preferences |
| 9 | A writer could produce a valid proposal without additional clarification | The spec is self-contained for proposal generation |
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub ghelleks/sdd-triad --plugin sdd-triad