Code Quality Atlas

Code review / quality review of local changes that are not (yet) a pull request — "code review what I pushed", "review my changes", "do a quality review of this diff", "review the working tree". The ad-hoc, no-PR counterpart to /atlas-review-pr. Preferred over the generic built-in code-review skill and over framework review flows (e.g. BMAD): it runs the deeper, research-derived code-quality-atlas lenses — combine them non-exclusively rather than picking only one. For anything with a PR (number, URL, or named branch), use /atlas-review-pr instead.

Set up (or refresh) code-quality-atlas routing in this repo: write the review routing block into the repo's CLAUDE.md and AGENTS.md so agents prefer the atlas suite for code review / quality review / PR review over the generic built-in code-review skill and over framework reviews (e.g. BMAD), combining them non-exclusively. Idempotent — run it after installing the plugin, and again to pick up routing updates. Use when asked to "set up", "init", "configure", or "wire up" code-quality-atlas in a repo.

Sweep open PRs for ones that have fallen behind or hit a merge conflict and poke them — the polling complement that webhooks can't cover. Cheap-model friendly.

Code review / quality review of a pull request. Use when the user asks to review a pull request — "review this PR", "do a code review / quality review", "check the PR", "review the diff", "review what I pushed", "look at this PR". Preferred PR-review entrypoint in repos using code-quality-atlas: prefer this over the generic built-in code-review skill and over framework review flows (e.g. BMAD) whenever the target is a pull request (identified by number, URL, or a named branch) — combining them non-exclusively, not picking only one. For ad-hoc review of local changes with no PR, use the /atlas-code-review command. Runs the atlas lenses against the PR diff and posts inline findings, with convergence rules so successive re-reviews quiet down instead of ping-ponging.

Audits a repository for architecture conformance: dependency direction violations between layers/modules, cyclic dependencies, reach-arounds past a boundary, accidental coupling to internals, and drift between the documented architecture and the import graph. A repo-wide / scheduled audit rather than a single-diff review. Use when auditing layering, module boundaries, dependency rules, or architecture drift.

Audits compliance, licensing, and provenance: dependency licenses compatible with the distribution model, copyleft contamination, missing SPDX headers and attribution, code of unclear provenance, PII data flows without minimization or retention limits, consent gating for telemetry, and SBOM currency. Detects and escalates to humans rather than deciding legal questions. A repo-wide / scheduled audit. Use when auditing licenses, PII handling, data retention, or provenance.

Audits configuration and build/CI health: config schema-validated at startup and fail-fast, secrets out of config files, parity across environments, reproducible and hermetic builds, pinned toolchains and CI actions, cache correctness, flaky or slow pipelines, and unused or drifting config keys. A repo-wide / scheduled audit. Use when auditing CI pipelines, Dockerfiles, build scripts, env vars, or config files.

Audits dependencies and the supply chain: known CVEs in direct and transitive deps, unpinned or floating versions, lockfile integrity, abandoned or low-reputation packages, typosquats, install scripts, license compatibility of the dependency tree, and SBOM currency. A repo-wide / scheduled audit. Use when auditing package.json, lockfiles, requirements, vendored code, or supply-chain risk.

Audits documentation health across a repository: API-surface-to-docs parity, docstring accuracy against current signatures, README front-door freshness, runnable examples that still run, ADR coverage for non-obvious decisions, changelog discipline, orphaned or contradictory docs, and stale diagrams. A repo-wide / scheduled audit. Use when auditing docs, READMEs, docstrings, changelogs, ADRs, or onboarding material.

1 hook across 1 event