cdad init

Once cdad roadmap tells you which capability to contract first, cdad init <capability-id> is what actually creates the files. Run it and you get a contract triple: acontract.yaml, a contract.json, and acontract.md, all written undercdad/<capability-id>/.

The capability ID isn't a free-text label. It has to follow thedomain/subdomain/action shape, something likepayments/retries/schedule-retry, and cdad initvalidates that shape before it writes anything. That structure is what lets cdad graph later group and connect capabilities sensibly instead of treating every contract as an unrelated island.

By default the command prompts you through the basics as it scaffolds, but --no-prompts skips that and writes placeholders instead, handy if you're generating several contracts in a script and plan to fill them in by hand afterward. If the capability needs more than the minimum fields, such as a longer constraint history or a wider set of dependencies, --extendedscaffolds the extended template rather than the baseline one.--output <dir> changes the base directory from the default cdad if your repo keeps generated artifacts somewhere else.

One detail worth knowing: if you ran cdad roadmap first,cdad init can pull the notes it gathered about that capability straight into the new contract, so the criticality and frequency reasoning you already worked out doesn't have to get retyped from scratch.

cdad init payments/retries/schedule-retry
cdad init payments/retries/schedule-retry --extended