cdad check Output Walkthrough

Running cdad check produces one file,cdad-report.md, and that file follows the same output shape every command in the CLI uses: a header, a divider, the content block, any generated file paths, and a closingNext step line. The illustration below shows the structure a report takes. Treat the specific numbers as illustrative, not as a real score pulled from a real customer's repository.

Near the top sits the overall score, a single number from zero to ten, next to a band that names roughly where the repo sits, from something like "early" or "developing" up toward "agent-ready." The score is a summary, not the useful part on its own. It exists so a team can compare one run against a later one and see whether the direction is right.

Below the headline score sits the part that actually matters day to day: per-capability findings from the questionnaire. For each of the capabilities walked through during the run, the report notes how it scored across the four legibility questions, where the answer was clearly there, where it was partial, and where there was nothing to point to but tribal memory. This is the section a team actually reads together, because it names specific gaps instead of leaving everyone to infer them from one number.

The report closes with a Next step line, and that line is what turns the check into a workflow instead of a one-off diagnostic. It's the reminder that the report itself isn't the destination. It's the input cdad roadmap reads next, the file that turns "here's where the gaps are" into "here's what to contract first."

Run the check again after a few extraction passes and you get a second report to set beside the first one. The value isn't in any single run's number. It's in watching the band move, and the per-capability findings shrink, as more of the system starts declaring itself instead of relying on whoever happens to remember why it works.