| name | quality-baseline |
| description | Baseline a repository before quality work. Use when asked to audit maintainability, reliability, performance, security, test quality, technical debt, or code health across a codebase; to identify and rank gaps before fixing them; or to compare quality state over time. Remain read-only on target source. |
| compatibility | Requires repository read access and its normal version-control and verification tools. |
Quality baseline
Build an evidence ledger, not a generic score. A missing checked-in control is a gap in visible repository evidence, not proof that no organization-level control exists.
1. Freeze repository identity
Record repository path, remote identity, HEAD, branch, working-tree state, stack, package manager, instruction files, CI workflows, and exact verification commands. Preserve unrelated changes.
Complete when: another reader can reproduce the inspected state and commands.
2. Map critical paths and controls
Trace the user-visible and operational paths whose failure would matter. For each path, map:
- functional contracts and external specifications;
- test layers and whether they exercise the real boundary;
- latency, throughput, memory, or size observability;
- timeout, retry, cancellation, cleanup, recovery, and overload behavior;
- dependency, secret, trust-boundary, and release controls;
- supported runtimes, operating systems, renderers, or protocol surfaces.
Use history, churn, and change coupling only as prioritization evidence. A large or frequently edited file is not a defect by itself.
Complete when: every critical path has an evidence-backed control map or an explicit verification gap.
