The Legibility Auditor

The legibility auditor's entire job is to run one specific audit, the four-question framework from the book's Appendix B, against a software system or codebase, and the prompt is unusually strict about wording: it's instructed not to paraphrase the diagnostic question or the four follow-up questions, and to use them exactly as written. That's not a stylistic preference. The questions were written precisely enough that rewording them changes what they're actually testing.

Every assessment starts with the same diagnostic question: could you hand this capability to a capable engineer who has never spoken to anyone on your team, and have them make a safe change to it using only what the system makes available? If the answer is yes without hesitation, the capability scores a full 4 out of 4 and the auditor moves on. Most capabilities don't clear that bar cleanly, which is where the four follow-up questions come in.

Each follow-up targets a different kind of missing knowledge. Can someone understand why the capability works this way, not just what it does, which is business rules legibility. Can someone identify what was tried before, what failed, and why, without asking anyone who was there, which is constraint history legibility. Can someone understand why this capability calls what it calls, in the way it does, rather than the more obvious alternative, which is dependency rationale legibility. And can someone identify every code path that exists because of a specific customer, regulatory, or historical condition without relying on tribal knowledge, which is exception logic legibility.

What comes out the other end is a completed audit table for each capability assessed, plus a ranked list ordered by score ascending, so the lowest-scoring capabilities surface first as the highest priority for extraction. The auditor doesn't stop at the number. It also names the specific tribal knowledge that's missing for each capability, meaning it says what an agent would actually fail to find, not just that something scored low. When the practitioner wants a reusable artifact out of this, the prompt points attemplates/audit/legibility-audit.md ortemplates/audit/legibility-audit.csv for the output shape.

This audit is the same interview cdad check runs automatically against up to five capabilities by default, so running the legibility auditor by hand is a way to extend that same diagnostic to more capabilities, or to walk through it with more narrative detail than a CLI report gives you. Either way, its output is what the extraction agent reads next to build an actual sequencing plan.