The Extraction Agent

A legibility audit tells you which capabilities are illegible. It doesn't tell you which one to fix first, and in a brownfield codebase with dozens of low scores, that second question is the one that actually blocks progress. The extraction agent's job is to identify the capabilities that should be contracted first, explain why each one is risky, and turn that into a sequencing plan a team can act on instead of arguing about.

It always starts from the legibility signal, the scores coming out of the audit or out of cdad check, and then layers in two more inputs before it recommends anything: business criticality and how often agents actually touch that capability. A capability that scores badly but rarely gets touched, by a person or an agent, is a different kind of risk than one that scores badly and sits in the path of every third change anyone makes. The prompt works from the toolkit's real flow: cdad check producescdad-report.md, cdad roadmap reads that report and turns it into cdad-roadmap.md, andcdad init <capability-id> scaffolds the first contract for whichever capability comes out on top. For the shape of a good handoff, it referencestemplates/audit/legibility-audit.md,templates/extraction-priority/extraction-priority-matrix.md, and the payment-retry worked example.

What it produces is a prioritized extraction plan with four parts: the capability IDs that should be contracted first, the specific risk or missing tribal knowledge that makes each one urgent, a recommended phase ordering across the whole set, and the first capture note the team should preserve while the contract gets authored, so the knowledge doesn't evaporate between the audit and the actual writing.

It's also built to prevent three specific mistakes. It won't prioritize by code churn alone without legibility evidence backing it up, because a file that changes often isn't automatically a file nobody understands. It won't select a capability just because it scored badly if there's no business criticality attached to it. And it won't recommend extraction without naming what tribal knowledge would otherwise be lost, because a recommendation without that reasoning is just a ranking nobody can defend later.

In the workflow, this prompt runs right after cdad check has produced its report, either beforecdad roadmap or alongside it. Its output is what a team actually hands to the contract author: not a vague sense that "the payments code is scary," but a specific capability ID, a specific reason, and a place to start.