A bench for sections, not a form for everything
Most spec templates pretend every change needs the same twelve headings. That is how a spike grows a rollout plan it cannot honor, and how a feature ships without a command a reviewer can run. The Spec Bench treats sections as trays. A change class seats the required kit. Optional trays stay in the rack until the risk earns them. You fill the active tray against a probe, not against a blank page.
The existing Spec Builder remains the linear dump: fill every field, get a markdown file. Use it when the kit is already decided. Use this bench when the craft question is which sections exist, and whether each one can pass inspection.
Not a PRD bench, not an agent gate
A PRD aligns people on what should exist, for whom, and why it matters. Atlassian’s product-requirements guidance still lives on that side of the line: audience, problem, goals, assumptions, success measures. This bench does not seat personas, north-star metrics, or launch narrative. If those decisions are still open, they belong on idea2prd.com first. A technical spec starts after the product decision is stable enough to implement.
An agent gate asks whether a coding agent should do the work at all. That question belongs on idea2agent.com. The Spec Bench assumes implementation is happening and makes the contract determinate: current truth, fences, obligations, examples, and verification. A person and an agent can both execute that contract. The bench does not score autonomy.
"what is a product requirements document"
How to assemble a spec on the bench
- Pick the change class. Feature, bug fix, API contract, data migration, or spike. The class seats the trays this change actually needs and leaves the rest in the rack.
- Seat only the sections that carry risk. A spike that fills twelve trays is over-specified. A feature that skips verification is under-specified. Optional trays stay in the rack until the risk earns them.
- Fill each tray against its probe. Every tray has a pass condition: evidence in Problem, fences in Non-goals, RFC 2119 in Requirements, Given/When/Then in Acceptance, a runnable check in Verification.
- Read the IEEE lamps before handoff. IEEE 830 still names the quality bar: unambiguous, complete, consistent, verifiable, traceable. The lamps are a local inspection, not a paper result.
- Export the markdown and review it. Copy or download the assembled spec, then run the Ambiguity Checker and the Spec Review Checklist before a person or an AI coding agent starts implementing.
Change-class kits
The kit is the teaching. Over-specification is filling trays the change cannot honestly know. Under-specification is leaving a required tray empty because the heading felt ceremonial.
| Class | Required trays | Why this kit |
|---|---|---|
| Feature | 11 seated | Seat the full implementation contract: current truth, fences, requirements, examples, verification, and rollout. |
| Bug fix | 7 seated | Prove the current failure, name the intended behavior, and make the regression check runnable. |
| API contract | 9 seated | Lock method, shape, auth, errors, compatibility, and a call a reviewer can repeat. |
| Data migration | 10 seated | Name the before/after records, backfill order, rollback, and the query that proves both sides. |
| Spike | 6 seated | Fence the question, the time box, what will be learned, and the artifact that ends the spike. |
What each probe is checking
ISO/IEC/IEEE 29148:2018 and the older IEEE 830-1998 both treat a requirement as a testable obligation, not a wish. RFC 2119 gives the vocabulary — MUST, SHOULD, MAY — and RFC 8174 reminds you the keywords only carry that meaning in capitals. Cucumber’s Gherkin reference is here because Given/When/Then forces starting state, action, and observable result. NASA Systems Engineering Handbook Appendix still frames the move from stakeholder expectation to a statement you can validate.
- Anatomy of a spec is the prose map of these trays.
- AI-executable specs add fences and reporting an agent needs on top of the same kit.
- Worked example is the weekly-digest specimen loaded on this bench, written out as a narrative.
"absolute requirement of the specification"
Client-side, on purpose
Spec drafts contain system truth: routes, tables, flags, sometimes customer-adjacent examples. The bench never submits the form. Inspection is deterministic string checks — word counts, RFC keywords, Given/When/Then shape, command-like tokens, a short vague-term list — not a model review and not a hosted store. If you want a second pass on a finished dump, paste it into the Ambiguity Checker.
How do I write a good technical spec?
Write it as an implementation contract. Name the system and the observable outcome, record current behavior, fence the change with concrete non-goals, write individually testable requirements, and attach Given/When/Then examples plus verification commands a reviewer can run. IEEE 830 still names the quality bar: unambiguous, complete, consistent, verifiable, and traceable.
What goes in a spec vs a PRD?
A PRD decides what should exist, for whom, and why. A technical spec decides how an approved change should work inside a real system and how completion will be verified. The Spec Bench seats engineering trays — current behavior, contracts, acceptance examples, verification — not product strategy, personas, or go-to-market.
What makes a spec AI-executable?
Local truth, explicit scope fences, examples that break ambiguity, non-goals, and done criteria a second person could run. The Spec Bench does not decide whether a coding agent should do the work; it makes the implementation contract determinate enough that a person or an agent is not inventing product policy.
How is the Spec Bench different from the Spec Builder?
The Spec Builder is a linear form that dumps every section into markdown. The Spec Bench is a section assembler: the change class seats the trays this job needs, optional trays stay in the rack, and each seated tray has a probe and an IEEE 830 lamp. Use the Bench to decide which sections exist. Use the Builder when you already know the kit and want a fast dump.
Does the Spec Bench send my draft anywhere?
No. It runs in the browser. Nothing you type is submitted to a backend. Copy or download the markdown if you want it to leave the tab.