# Quality List > Single source of truth for universal code-quality items. Definitions live in items/.md; audit and preflight skills reference items by slug. - Skill: `ultimatile/quality-list` (Agent Skill, multi-file: 22 files) - Install (CLI): `npx skillmds@latest add ultimatile/quality-list` - Raw SKILL.md: https://api.skillmd.com/api/skills/ultimatile/quality-list/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: ultimatile (https://skillmd.com/u/ultimatile) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ultimatile/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-.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](items/invariant-derivation.md) — contextual - [purpose-verification](items/purpose-verification.md) — contextual - [pattern-audit](items/pattern-audit.md) — contextual - [duplication-extraction](items/duplication-extraction.md) — mechanical - [scope-discipline](items/scope-discipline.md) — contextual - [behavior-coverage](items/behavior-coverage.md) — mechanical - [implementation-guards](items/implementation-guards.md) — mechanical - [impact-verification](items/impact-verification.md) — mechanical - [test-execution](items/test-execution.md) — contextual - [completion-hygiene](items/completion-hygiene.md) — contextual - [architectural-boundary](items/architectural-boundary.md) — mechanical - [escape-hatch-necessity](items/escape-hatch-necessity.md) — contextual - [paired-artifact-drift](items/paired-artifact-drift.md) — mechanical - [docstring-drift](items/docstring-drift.md) — contextual - [discovery-surfacing](items/discovery-surfacing.md) — contextual - [ported-code-attribution](items/ported-code-attribution.md) — mechanical (+ contextual half) - [signature-change-regression](items/signature-change-regression.md) — mechanical - [public-doc-durability](items/public-doc-durability.md) — mechanical - [public-api-surface](items/public-api-surface.md) — mechanical Where an item body or addendum spells a detection command over the change under audit, `` 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-.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.