## Definition The **spec-as-prompt pattern** is the practice of pointing an agent at the canonical spec file rather than paraphrasing it in chat. The prompt collapses to a *pointer* plus operational constraints. ## Canonical Template ``` Implement openspec/changes/<slug>/proposal.md. Constraints: - Touch only files listed under "Files touched" in the proposal. - Every acceptance criterion must have a corresponding test. - If you discover an open question is unresolved, STOP and ask. Run the new tests after each file. Stop on the first failure and explain. ``` ## Why It Works 1. **Canonical, not paraphrased.** The agent reads the same source the team reviewed. 2. **Operational constraints, not goal restatement.** Constraints shape *how* the agent works; the spec defines *what* it builds. 3. **Explicit stop conditions.** Open questions are escape hatches, not silently-resolved gotchas. ## Measured Effect In head-to-head tests, the spec-as-prompt form requires fewer mid-session "actually, no…" corrections, produces tighter diffs, and benefits dramatically from [[Prompt Caching]] (the spec is stable across PRs). ## When Not To Use It Throwaway scripts, quick experiments, and tiny one-shot edits don't justify the spec file. The prose form is faster for genuinely throwaway work. ## Related - [[Spec-Driven Development]] - [[Executable Acceptance Criterion]] - [[OpenSpec]] - [[Prompt Caching]]