Quality List

Quality List (SSOT)

Skills that audit or preflight against universal code-quality apply these items by reference. When an item changes, referencing skills pick up the change automatically. This binds the audit runner and the preflight runner alike: a runner may carry a compressed mnemonic of an item in a quick reference, but never the item's full triggers, concern conditions, N/A criteria, or enumerations — that copied detail is the manual-synchronization surface this rule removes — and the mnemonic is never the authority. The item body plus every applicable lang-<lang>.md addendum section is what determines whether an item applies and holds the item's full detail; a stale mnemonic cannot override it. The Items index below is likewise the single source of truth for which of this rule set's items exist and which lane each belongs to: runners derive their active set of universal code-quality items by reading this index, never by hardcoding a parallel slug list. Adding an item here propagates to every runner automatically. A runner that also applies another rule set derives that set from its own SSOT's index the same way; this index says nothing about it.

Item lanes

Each item is tagged for which lane it belongs to when a consumer splits work between a fresh-context subagent and main context. done-check's backward audit (its Step 2 dispatches a subagent for this rule set / main-context Step 3) and todo-check's forward preflight (subagent Step 2 / main-context Step 3) both apply the same split. The tags govern this rule set only; a runner applying another rule set alongside it routes that one by whatever its SSOT declares:

• mechanical — judgable from literal text alone (the diff, for an audit; the planned-scope description, for a preflight) plus literal code text and literal rule text, with no need for conversation history, plan context, or actual command execution. Delegated to a fresh-context subagent (done-check Step 2, todo-check Step 2) to neutralize the author's blindspot for what their own comments, code, or planned scope actually say (vs what they meant them to say).
• contextual — requires plan / intent / review history that only the main context has, OR requires running a command against the working tree to gather evidence. Stays in main context (done-check Step 3, todo-check Step 3).

A small number of items are dual-lane: their detection has both mechanical (literal-grep) and contextual (history-aware) signals. Such items appear in both lanes; consumers (done-check, todo-check) route the relevant signal to the appropriate context. The current dual-lane item is ported-code-attribution (declared port = mechanical, undeclared port = contextual).

Each item's lane is declared once, in the Items index below (the — mechanical / — contextual suffix on each entry). Item files do not carry a lane tag in their H1 heading.

Items

Listed in canonical reading order. Reference items by slug (e.g., behavior-coverage); numbering is not stable and not part of the SSOT.

• invariant-derivation — contextual
• purpose-verification — contextual
• pattern-audit — contextual
• duplication-extraction — mechanical
• scope-discipline — contextual
• behavior-coverage — mechanical
• implementation-guards — mechanical
• impact-verification — mechanical
• test-execution — contextual
• completion-hygiene — contextual
• architectural-boundary — mechanical
• escape-hatch-necessity — contextual
• paired-artifact-drift — mechanical
• docstring-drift — contextual
• discovery-surfacing — contextual
• ported-code-attribution — mechanical (+ contextual half)
• signature-change-regression — mechanical
• public-doc-durability — mechanical
• public-api-surface — mechanical

Where an item body or addendum spells a detection command over the change under audit, <root-rev> in it is the revision form diff-root derives from the root the runner was given, and the range form is that skill's per-command conversion. Substitute the derived form, never the supplied one. A runner with no root does not run those commands: use the item's working-tree form where it offers one, and otherwise judge the item from the sources the run does have. Never substitute a range.

Language-specific addenda live alongside this file as lang-<language>.md and supplement specific items with triggers and mitigation idioms (current examples: lang-cpp.md, lang-rust.md). An addendum section realizes an item concretely; it never bounds the item: its triggers and N/A criteria scope only that realization, and a diff outside the realization's constructs remains subject to the base item's conditions.