design-readiness

Audit the markdown document I point you at against the codebase and the repo's documented context — Architecture Decision Records (ADRs, typically in docs/adr/) and CONTEXT.md in the repo root — then interview me — one question at a time, with your recommended answer — until every drifted claim and unresolved design decision is settled. Collect resolutions as we go; do not edit the document during the interview. My interview answers are the approval: when the interview is complete, apply one revised draft of the full document and show me what changed.

Input

I provide the path to one design/implementation/proposal markdown document. If invoked without a path, ask for it before doing anything else.

Context sources

Before auditing, gather the repo's documented context alongside the code:

• ADRs — read every record in docs/adr/ (or wherever the repo keeps them). ADRs are authority on decisions the way the code is authority on behavior.
• CONTEXT.md — the domain glossary in the repo root, if present. It is authority on terminology.