Prompt Contracts: Treat Prompts Like APIs (Inputs, Outputs, Errors)

If you’ve ever shipped a prompt that worked yesterday and mysteriously fails today, you’ve already learned the core lesson: Prompts aren’t “just text”. They’re an interface. And interfaces need contracts. In software, we don’t call a function without knowing what it expects and what it returns. We don’t expose an API without documenting error cases. Yet a lot of prompt work is still “try a few words and hope”. That approach breaks the moment you: add a second consumer (a teammate, a cron job, a different model) change upstream inputs (new fields, longer docs, weird formatting) introduce tools (retrieval, code execution, web browsing) A prompt contract is a lightweight way to treat prompts like APIs: explicit inputs, explicit outputs, and explicit failure behavior. This post shows a practical template you can copy, plus a concrete example (with validation + a repair loop) that you can drop into a real workflow. What is a prompt contract? A prompt contract is a short, structured specific