In this section: Toolkit

CLI Reference

Five commands cover the full loop. This page is the quick version of each. For a longer walkthrough of any single command, including flags and sample output, the dedicated pages underHow C-DAD Works go deeper than what's here.

cdad check establishes the baseline. It combines a static scan of the repository with a short legibility questionnaire covering up to five capabilities, then writes a score from zero to ten, with a band, to cdad-report.md. Everything else in the loop starts from this file.

cdad roadmap reads that report and prioritizes. It factors in business criticality and touchpoint frequency alongside the tribal knowledge density the check already surfaced, multiplies the three together, and writes a ranked list to cdad-roadmap.md.

cdad init <capability-id> scaffolds a contract. Given a capability ID in domain/subdomain/action form, it creates the contract triple, YAML, JSON, and Markdown, undercdad/, and can pull relevant notes straight from the roadmap into the new contract.

cdad validate <path> keeps contracts honest over time. It checks schema conformance, versioning rules, and whether the generated JSON and Markdown artifacts still match the YAML source of truth. Run it with --all across the whole repo, --strict to treat warnings as failures, or--install-hook to run it automatically before every commit.

cdad graph renders every contracted capability and its dependencies as Mermaid, JSON, and Markdown output at once. The JSON adjacency list is the stable, agent-consumable format if you're building anything on top of the graph rather than just looking at it.

Put together, the recommended pattern is check, roadmap, init, validate, graph, and then check again once the work has landed, so the score becomes a trend you can watch instead of a single snapshot.