The #1 cause of prompt failure in 2026 isn't model limitations — it's undefined "done". An output contract specifies format, length, tone, and required sections in a testable way. Success criteria define how you'll judge if the output passed.
Structure beats length. A short prompt with a clear contract outperforms a long prompt with vague hopes.
02 Weak vs. Strong
EX 01Sprint summary with a real contract
Summarize this sprint for non-technical stakeholders.
OUTPUT CONTRACT — the response passes only if ALL of these hold:
1. Exactly 3 sections: Shipped / At Risk / Needs Decision
2. Each section: max 3 bullets, max 15 words per bullet
3. Zero technical terms (no API, deploy, refactor, latency, schema)
4. 'At Risk' items each name a business consequence, not a technical cause
5. 'Needs Decision' has exactly one ask with a deadline — or states 'No decisions needed'
If information is missing for any section, write '[MISSING: what you need]' rather than inventing content.
Sprint notes:
[paste notes]
→ Why it works
Every contract clause is mechanically checkable: count sections, count bullets, scan for banned terms. The uncertainty clause ('[MISSING: ...]') prevents hallucinated filler — the most common failure in status summaries.
EX 02API doc generation with verification
Write API documentation for this Go handler.
SUCCESS CRITERIA (verify your output against these before responding):
□ Every parameter in the code appears in the docs with its exact type
□ Every error status the code can return is documented with its trigger condition
□ The example request uses realistic values, not 'foo'/'bar'/'string'
□ The example response matches the actual struct fields in the code — no invented fields
□ Auth requirements stated in the first 2 lines
After writing the docs, add a section 'VERIFICATION' listing each criterion with ✓ or ✗ and a note for any ✗.
```go
[paste handler code]
```
→ Why it works
The self-verification step forces the model to check its own work against the contract. 'No invented fields' targets the exact failure mode of AI-generated docs: plausible-looking fields that don't exist in the code.
03 Key Points
01Write success criteria BEFORE writing the prompt: what does 'done' look like?
02Output contract = format + length + tone + required sections, all testable
03Include 'what to do when uncertain' — the most-skipped contract clause
04If you can't check the output against the contract mechanically, it's not a contract
05Contracts make prompts team-shareable — anyone can verify the output
04 Model-Specific Notes
Claude excels with contract-style instructions and critique/evaluation steps. Checklist contracts with explicit verification are followed very reliably.
05 For Your Role
Before prompting, write one sentence: 'This worked if ___.' Then put that sentence in the prompt.