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

Intro Prompts are the glue between humans and LLMs — but most prompts are fragile notes, not developer-grade interfaces. Treating a prompt like an API (with clear inputs, outputs, and error cases) makes results predictable, testable, and repeatable. In this post I’ll show a compact, practical contract you can apply to any prompt today. Why prompt contracts matter Reduce ambiguity: explicit inputs and constraints. Make prompts testable: define expected outputs and quick checks. Reduce drift: a contract prevents accidental prompt rot. The contract (1 page) Purpose — Single-sentence intent. Inputs — fields, types, and an example. Output schema — what shape the model should return (JSON or bullet list). Constraints — length, style, forbidden content. Error cases & fallback — what to do on unknown input or partial output. Quick test — 1–3 example inputs with expected outputs. Concrete example Purpose: Summarize a PR description into a one-paragraph changelog entry. Inputs: title (string) ch