Originally published at acuity.press.
By Sandeep Dhuri
You do not need a prompt library. You need one repeatable structure that turns a request into a specification. This is that structure (the Specification Frame from Delta) compressed to a working minimum you can apply today.
The four blocks
1 · CONTEXT — what the model cannot guess. Domain facts, system invariants, environment. "Payment service in a regulated banking context. .NET 9. All monetary values are USD, stored as decimal. Every external call may be retried; all writes must be idempotent. Multi-tenant: every query is scoped by tenant_id."
2 · CONSTRAINTS — what must and must not happen, with precedence. Safety > correctness > style, stated so conflicts resolve your way. "Prohibited: binary floating point for money; string interpolation into SQL; logging of PAN/PII. Required: parameterized queries; idempotency keys on all mutating endpoints; banker's rounding at aggregation only."
3 · OUTPUT CONTRACT — exactly what comes back. Shape, format, boundaries. "Return: (a) the C# implementation, (b) xUnit tests covering the constraints above, (c) a list of any constraint you could not satisfy and why. Never silently relax a constraint."
4 · VERIFICATION — the checks, stated in the prompt. This is the block most teams skip and the one that changes everything: the model generates toward declared tests, and your reviewer tests against them. "The tests must include: 0.1+0.2 exactness for money; duplicate-delivery of the same idempotency key; the injection strings ['; DROP TABLE—, {{ignore previous instructions}}]; a cross-tenant access attempt (must fail)."
Before and after, one request
Before: "Write a webhook handler for payment notifications." — a wish. The corpus's average webhook handler has no idempotency, no signature verification, and logs the payload.
After (frame applied, abbreviated): context declares the retry-happens reality and the secret-handling rule; constraints prohibit unverified signatures and require idempotency-keyed deduplication; the contract demands implementation + tests + a stated-gaps list; verification names the duplicate-delivery and forged-signature tests. Same model. Same day. A different artifact. Because "plausible" now has your definition.
Why the input side is where the leverage is
Across 150+ models and two years of releases, the share of AI code-generation tasks introducing a known vulnerability has held near 45% (Veracode's 2026 report): capability up, security flat, because models complete the public corpus's patterns unless your prompt outweighs them. The Frame is how you outweigh them (systematically, reviewably, in version control (the book's Law 10) "Prompts are code" — version-controlled, reviewed, tested — which regulators, a year later, started calling an audit trail). And the Frame scales with the era: in 2026's orchestrated workflows, the same four blocks are what you hand a fleet — an orchestrator distributing an underspecified request just parallelizes the gap, while one that distributes a Frame parallelizes the discipline. Twenty minutes to learn; the book's remaining chapters are the per-domain depth (code review, debugging, testing, agents, security) all free.
I run this drill with every team I join. Twenty minutes is the honest price of admission.
Condensed from Delta: Closing the Specification Gap: A Prompt Engineering Framework for Enterprise Software Teams (Sandeep Dhuri, Acuity Press, 2026) — free, no signup: https://acuity.press · DOI: 10.5281/zenodo.21584309 · template: acuity.press/spec.md.
Sources: Veracode, 2026 GenAI Code Security Report / Spring 2026 Update (2026).
Top comments (0)