SpecSmith — Prompts
Prompt 1: Canonical Spec Template
Source: spec/specsmith-spec-template.md
Technique: Structured outcome-first template with explicit authorial perspective instruction.
# [Spec Title]
[1-2 sentences: What this spec covers. State the capability or system being specified,
not the implementation approach.]
---
## 1. Outcome
[Define what done looks like. This is the single most important section. Write it from
the perspective of someone who will accept or reject the result, not someone who will
build it.]
[A good outcome statement is verifiable without reading the implementation. It describes
the observable state of the world after the work is complete.]
---
## 2. Test Gates
[Each gate is a concrete verification that the outcome has been achieved. Gates should
be runnable: CLI commands, test assertions, inspection steps, or documented evidence.]
| Gate | Verification |
|------|-------------|
| [What is proven] | [How it is proven] |
---
## 3. Constraints
[Non-negotiable boundaries the implementation must respect. Constraints define what
cannot be violated, distinct from outcomes which define what must be achieved.]
---
## 4. Scope
**Pre-existing (do not create or modify):**
**Create:**
**Out of scope:**
---
## 5. Dependencies
| Dependency | Relationship |
|------------|-------------|
| [Spec or module name](path) | What it provides to this spec |
Notable technique: The outcome section explicitly instructs the writer to adopt the acceptor's perspective, not the builder's. This is a deliberate framing to prevent outcome statements that describe implementation steps rather than observable results.
Source: README.md
Technique: Minimal schema enforcement — only outcome + test_gates required.
# The contract at its simplest
outcome: Web service responding on HTTPS with sub-20ms latency
test_gates:
- curl -k https://localhost returns 200
- p95 latency < 20ms under 100 concurrent connections
- SSL Labs score >= A
Notable technique: YAML-format minimum form allows machine-readable specs at zero verbosity. The three test gates are all runnable CLI commands — no ambiguity about what "done" means.
## The Core Contract
SpecSmith specs are built around a stable contract: define the outcome,
define the proof. The level of specificity can range from a lightweight
build spec to a compliance-grade verification matrix, but the contract
does not change.
The outcome:test keypair is the irreducible primitive. Everything else
in this template is optional structure added as needed.