| 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.
3. Prove or reject findings
For every candidate gap, capture:
- exact evidence and affected contract;
- plausible failure and impact;
- confidence and important unknowns;
- smallest useful verification;
- fix effort and regression risk.
Reject code-smell findings that do not connect to a failure, change-safety cost, measurable bottleneck, or violated repository rule. Reject optimization claims without a workload and measurable symptom. Reject "add tests" without naming what the test must detect.
Complete when: every retained finding has a verification story and every investigated rejection has a reason.
4. Rank pilot work
Rank by impact, evidence strength, verification cost, fix risk, and reversibility. Prefer one bounded pilot whose result can be measured. Route:
- measured bottlenecks to
performance-proof;
- weak regression protection to
test-strength;
- failure-path exposure to
resilience-audit;
- a selected defect to the repository's triage workflow.
Complete when: the top recommendation names the contract, evidence, first experiment, stop condition, and expected proof.
5. Deliver the baseline
Return a quality matrix, critical-path map, ranked findings, rejected findings, verification gaps, and next pilot. Include a machine-readable representation when the user requests a persistent or repeatable baseline. Do not change target source under this skill.
Complete when: the report distinguishes evidence, inference, and unknowns, and contains no synthetic global quality score.
