Installation

cdad is a command-line tool, not a service you sign up for or a platform you migrate onto. You install it, you point it at a repository, and it runs locally against the code that's already there. There's no account to create and nothing to upload before you can see what it does.

The practical starting point is to install the CLI from the companion repository, following whatever install instructions are published there for your environment, and confirm it's on your path. From there, adoption doesn't require a plan or a kickoff meeting. It requires one command.

Run cdad check in the root of the repository you want to assess. That's the first command in the adoption loop for a reason: it establishes a baseline before you've changed anything, combining a static scan of the repo with a short questionnaire about a handful of real capabilities, and writes the result tocdad-report.md. Nothing about that first run commits you to a full extraction program. It just tells you, honestly, where the repo currently sits.

From that first report, the rest of the workflow follows in order,cdad roadmap to prioritize, cdad init to scaffold a contract, cdad validate to keep it honest, and cdad graph to see how it connects to everything else. None of those later steps require reinstalling anything or reconfiguring the tool. The same CLI you installed for the first check carries the whole loop.

If you're evaluating whether this fits your stack before installing anything, the CLI reference and the repository itself are the places to look. Both describe exactly what the tool does without asking you to take it on faith first.