Full-Project Thermo Review

Full-Project Thermo Review

This is an orchestration wrapper, not a review standard of its own. It exists because the actual review standard — thermo-nuclear-code-quality-review — is written to review one PR/branch diff at a time, and reading an entire codebase in a single pass either blows the context budget or forces skimming, which defeats the point of a strict maintainability audit. This skill's job is purely the sharding + fan-out + synthesis process: split the codebase into pieces small enough to read in full, review each piece in parallel with the real standard, then roll the results up into one coherent report.

Do not use this for reviewing a single PR or branch diff — hand that straight to the underlying thermo-nuclear-code-quality-review skill (or the equivalent /code-review flow) instead. Use this skill specifically when the ask is "the whole codebase" or "the whole repo" or a large subtree of it.

Step 1 — Locate the actual review standard

The rules you apply in every shard come from thermo-nuclear-code-quality-review, not from this file. Find it in this order:

1. Local first. Check this repo's skill locations for an already-installed copy (naming and directory may vary by tool: .agents/skills/thermo-nuclear-code-quality-review/SKILL.md, .claude/skills/..., .cursor/skills/..., .codex/skills/...). If present, read it directly.
2. Remote fallback. If no local copy exists, fetch the canonical source: https://github.com/cursor/plugins/blob/main/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md (raw content — via gh api repos/cursor/plugins/contents/thermos/skills/thermo-nuclear-code-quality-review/SKILL.md --jq '.content' | base64 -d, or a web fetch of the raw file).
3. Cache it once. Save the resolved standard to a single scratch file for this run. Every sub-agent should Read that same file rather than each re-fetching it — cheaper, and guarantees every shard is judged against identical rules.

The adaptation every sub-agent needs to know: the standard's baseline prompt talks about reviewing "the current branch's changes" — a diff. In full-project mode there usually is no diff. Tell every sub-agent explicitly: apply the same rules and the same severity bar to the code as it currently stands, as a standalone audit, not a diff review. Everything else in the standard (the 1000-line file-size rule, the anti-spaghetti rules, boundary/type cleanliness, canonical-layer discipline, the priority ordering, the output format) applies unmodified.

Step 2 — Shard the codebase

Goal: every shard is small enough that a sub-agent can read every file in it, not sample it, while the union of all shards covers the whole target with no gaps and minimal overlap.

1. Enumerate the natural top-level units: workspaces/apps/packages in a monorepo, or top-level src subdirectories in a single app.
2. Get a quick size read per unit — file count and line count (a one-line find | wc -l loop is enough) — to see where the mass actually is before guessing at boundaries.
3. Group along domain boundaries, not arbitrary line-count buckets: a backend feature/domain folder, a frontend route or feature folder, a shared/canonical package, an infra or cross-cutting layer. Don't split one cohesive feature across two shards; don't lump two unrelated large domains into one shard just to hit a target size.
4. If a single directory alone exceeds the target shard size, split it further along its own subdirectories (feature areas, route segments, sub-domains) instead of reviewing it as one oversized shard.
5. Target roughly 3,000–8,000 lines / well under ~150 files per shard as a starting point — small enough to read in full, large enough that you're not paying fan-out overhead for trivial pieces. Scale the number of shards to the codebase: a small repo might need only 1–3 shards, a large monorepo can reasonably need 15–20. Keep shards roughly balanced so no single sub-agent becomes the long pole the others wait on.
6. Give every shard a short slug and an explicit, unambiguous path list. No shard's scope should overlap another's.

Step 3 — Brief each sub-agent

One file per actionable item, not one file per shard. A single combined report per shard is hard to turn into real work — findings get lost inside a wall of markdown, nobody can hand one item to someone else, and a genuine bug ends up filed next to a cosmetic nit as if they were the same kind of task. Every sub-agent writes its findings as individual, ticket-ready files from the start, laid out like this:

docs/thermo-review/
  README.md                      — overview, written by the orchestrator in Step 5
  bugs/                          — real functional bugs, flat across all shards
    <shard-slug>-<bug-slug>.md
  <shard-slug>/
    00-summary.md                — scope, verdict, size watch list, "explicitly fine" notes,
                                    index of every finding this shard produced
    01-<finding-slug>.md         — one file per maintainability/quality finding