The Contract Author

The contract author's job is narrower than "help me write a contract." It helps a practitioner produce acontract.yaml that is machine-readable, precise, and complete enough to pass cdad validate once it's written into a scaffolded file. It's grounded indocs/contract-schema-reference.md, the minimum viable contract schema, and the toolkit's own templates, including the payment-retry worked example, so the YAML it produces matches the schema the CLI actually checks against, not a generic idea of what a contract should look like.

The order it works in is deliberate. It asks for the capability ID first, in the domain/subdomain/action semantic naming format the schema expects, and checks whether the practitioner has already run cdad init <capability-id>. If not, it explains that the toolkit can scaffoldcontract.yaml, contract.json, andcontract.md automatically rather than starting from a blank file. From there it asks for the business intent, what the capability does and why it exists, then the inputs and outputs, then the non-goals, then any known constraints or history: what's gone wrong before, what workarounds exist, what tribal knowledge would otherwise walk out the door with whoever's answering these questions.

What it deliberately doesn't ask for is implementation detail. If a practitioner answers in implementation language anyway, "we cache the result for 90 seconds," the contract author's job is to surface the business rule underneath that sentence and write that down instead of transcribing the caching decision verbatim. It's also watching for signs that a capability needs more than the minimum schema can hold. If dependency, performance, error-handling, or evolution context clearly belongs in the same artifact, it tells the practitioner to scaffold the extended form withcdad init <capability-id> --extended before continuing, rather than cramming that context into fields that weren't built for it.

The output is YAML with every field populated, no placeholders, and no implementation language sitting in the description field.non_goals can't be left empty, every input needs a business constraint attached, every output needs a guarantee, andopen_questions has to be honest, meaning it becomes an empty list before the capability's state can honestly move toactive. After producing the contract, it reminds the practitioner to run cdad validate [path/to/contract.yaml], because writing a contract that reads well isn't the same as writing one that validates.

In the adoption loop, this is the prompt that sits insidecdad init. Something has already been chosen for extraction, likely by the legibility auditor and the extraction agent working together, and now someone has to turn that decision into an actual artifact. The contract author is what fills in the scaffold. What it hands off next is a draft for the contract reviewer to check before anything gets merged.