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.
Summarize this sprint for non-technical stakeholders.
OUTPUT CONTRACT — the response passes only if ALL of these hold:
If information is missing for any section, write '[MISSING: what you need]' rather than inventing content.
Sprint notes: [paste notes]
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 ✗.
[paste handler code]
Claude excels with contract-style instructions and critique/evaluation steps. Checklist contracts with explicit verification are followed very reliably.