SpecOps Agents File — Prompts
Verbatim Excerpt 1: Core Principle Statement
## Core Principle
**The specification is the source of truth.** All code implements behavior defined in specifications.
When in doubt, defer to the spec. If the spec is unclear or incomplete, flag it for human review
rather than making assumptions.
Prompting technique: Three-sentence iron law with a decision procedure for ambiguity: don't interpret, don't assume, flag and stop. The "when in doubt" clause prevents the agent from filling gaps with reasonable-seeming defaults.
Verbatim Excerpt 2: Spec-Before-Code Enforcement
## The SpecOps Workflow
### Specification First
1. **Read specifications before code.** Before implementing, modifying, or analyzing any feature,
locate and read the relevant specification in the `specifications/` directory.
2. **Propose spec changes before code changes.** If implementation requires behavior not covered
by a specification, draft a specification update for human review before writing code.
3. **Never implement undocumented behavior.** All system behavior must trace back to a
verified specification.
### Human Verification
4. **Domain experts verify specifications, not code.** Specifications are written in plain
language so non-technical stakeholders can review them. Code is an implementation detail.
5. **Flag ambiguity for human review.** When specifications contain ambiguous requirements,
edge cases without clear guidance, or apparent contradictions, stop and request clarification
rather than interpreting.
6. **Preserve institutional knowledge.** When you encounter implicit business rules, policy
interpretations, or undocumented edge cases in existing code, extract them into specification
language for human verification.
Prompting technique: Numbered workflow with explicit role separation between specifications (human-readable, human-verified) and code (implementation detail). Rules 4-6 encode the "specification as communication medium between humans and agents" pattern — specs are not for the agent, they are for domain experts to verify.
### Analysis Approach
1. **Identify business logic.** Distinguish business rules from infrastructure, error handling,
and technical implementation details.
2. **Trace to authoritative sources.** Look for references to statutes, regulations, form
numbers, or policy documents in comments or naming.
3. **Document edge cases.** Pay special attention to conditional logic, boundary conditions,
and error handling — these often encode important business rules.
4. **Preserve original intent.** Capture what the code *does*, not what you think it *should* do.
Specification review will determine correctness.
Prompting technique: "Preserve original intent" instruction prevents the agent from "improving" during analysis — a common failure mode where AI agents subtly change behavior while extracting it into specs. The instruction to distinguish business logic from infrastructure creates a classification task that surfaces the actual spec-worthy content.