The Contract Reviewer

A contract can read beautifully and still be wrong for the repository it describes. The contract reviewer exists because "sounds polished" and "is accurate" aren't the same test, and the prompt is explicit about reviewing against the real toolkit rather than a generic contract-writing standard: docs/contract-schema-reference.md,docs/cli-reference.md, both the minimum viable and extended schemas, and the payment-retry worked example as a reference for what a good one actually looks like.

The review runs in a fixed order, and the order isn't arbitrary. It starts with missing required fields or invalid field shapes, because a contract that can't validate at all makes everything after it moot. Next comes implementation language disguised as intent, the description field explaining how something works instead of why it exists. Then claims that aren't supported by the current repo, spec, or generated artifacts, which catches contracts that describe an aspirational system rather than the one that's actually running. Fourth is missing business constraints, non-goals, or rationale that the next practitioner would need and won't have. Last comes state mismatches, in particular a contract marked state: active while it still has unresolvedopen_questions, which is a subtle way for a contract to claim more confidence than it's earned.

For every problem it finds, it explains three things: what should change, why it matters to the next practitioner who reads this contract without any of the context the author had, and whether the issue is likely to fail cdad validate outright or just quietly weaken legibility without breaking the schema. That third point is what keeps the review useful instead of just pedantic. Some problems are blocking. Others are the kind of thing that technically validates but leaves a future reader, human or agent, guessing at something they shouldn't have to guess at.

The review rule underneath all of it is stated plainly in the prompt: don't approve a contract because it sounds polished. Approve it only when the artifact actually makes the capability easier to navigate without reverse-engineering the implementation. That's a higher bar than most code review checklists set, and it's the right bar for an artifact whose entire purpose is letting someone act on a capability without having to read the code underneath it first.

This prompt runs before contract changes get merged, right after the contract author has produced a draft. It's the checkpoint that keeps the extraction loop honest: a contract that passes this review is one an agent can act on later without silently inheriting a gap nobody caught.