review-health

What this skill does

# Review-Health — Strategic Orientation for a Repository

A first-pass review skill for the moment you want to step back and assess a repo strategically: you've just inherited it, you're evaluating a FOSS project for adoption, you're onboarding a teammate, or you're revisiting your own project to decide where to invest. The skill produces an evidence-cited map of the repo's state — not a grade. Its output is built to inform strategic decisions about engagement, not to itemize every imperfection.

**This skill is advisory only. It makes no changes.** To act on findings, hand off to `/refactor`, `/review-arch`, `/review-test`, `/review-security`, or other specialists as the findings indicate.

## Philosophy

**Observation before interpretation.** The skill's procedure enforces an OODA cadence — Observe, Orient, Decide, Act — with strict phase gates. The Observe phase collects signals without verdicts. Only after observation is complete does interpretation begin. This is the structural countermeasure to the most common failure mode of informal code review: fixating on the first file opened and building a distorted mental model from there.

**"Good" is relational, not absolute.** A 34% test-coverage finding is a different finding in a research prototype than in an OSS library with external consumers. The skill's calibration is anchored in **reference classes** (`references/classes/`): the repo is classified into a class first, and each dimension is evaluated against class-specific expectations. Classification is a cited, overridable output — the user sees which class was applied and can correct it in one line. Every downstream finding reflows against the correct class.

**Every claim carries evidence.** A finding without a `file:line` citation or a tool-output reference is not a finding; it is an assertion and must be dropped or demoted to the Coverage Manifest. This is enforced structurally (the phase-integrity check in §Evidence Discipline), not stylistically.

**Named unknowns beat silent unknowns.** The Coverage Manifest is first-class output. Tools that weren't available, signals that couldn't be computed, and questions that couldn't be answered are named explicitly with the reasons they couldn't be resolved. A honest "we couldn't assess X" beats a confident assessment that silently excluded X.

**Breadth first. Compose, don't reinvent.** This skill is the wide-and-shallow pass. When a finding warrants a deep-and-narrow follow-up, the skill routes to a sibling specialist (`/review-arch`, `/refactor`, `/review-test`, `/review-security`, etc.) with a scoped argument. The skill does its own work at breadth level; it defers to siblings only when a sibling is an exact fit for what needs doing.

## Cognitive Failure Modes This Skill Countermands

New-repo orientation has a small set of predictable cognitive failures. The skill's procedure is designed to counter each:

- **Inheritor's paralysis + availability bias** — fixating on the first file opened, building a distorted mental model from a non-representative sample. *Countermeasure: systematic Observe phase that enumerates signals from fixed collection points before any interpretation.*
- **Unknown-unknowns dominance** — not knowing what you don't know about the repo. *Countermeasure: Coverage Manifest elevates missing tooling and un-assessed dimensions to first-class output.*
- **Premature closure** — committing to a verdict before evidence is complete. *Countermeasure: phase-integrity gates — Orient cannot cite anything not captured in Observe; Decide cannot cite anything not captured in Orient.*
- **Expert deference** — accepting prior-author choices without questioning. *Countermeasure: differential-diagnosis classification forces candidate alternatives to be considered with evidence for and against each.*
- **Free-floating adjectives** — "health: good" with no reference point. *Countermeasure: reference-class calibration with cited per-class rubrics.*

The practitioner traditions this skill draws from — OODA (Boyd), medical differential diagnosis, home inspection (ASHI severity tiers), marine surveying (reference-class calibration), technical due diligence (M&A), intelligence situational-awareness briefings — are all codifications of these countermeasures in domains that have had to solve "rapid assessment of unfamiliar systems under uncertainty" at higher stakes than software review.

## Workflow Overview

```
┌────────────────────────────────────────────────────────────────┐
│                      REVIEW-HEALTH                             │
├────────────────────────────────────────────────────────────────┤
│  Phase 0 — Preflight                                           │
│    • Elicit lens (what's the user doing?)                      │
│    • Determine scope (whole repo / directory / module)         │
│                                                                │
│  Phase 1 — OBSERVE (no interpretation allowed)                 │
│    • Repo enumeration (size, structure, entry points)          │
│    • Git-history signals (cadence, churn, bus factor)          │
│    • Tooling signals (lint, coverage, CI, deps, secrets)       │
│    • Documentation signals (README, inline, architectural)     │
│    • Coverage Manifest: what couldn't be collected and why     │
│                                                                │
│  Phase 2 — ORIENT (classification + rubric application)        │
│    • Differential diagnosis → reference class (cited)          │
│    • Apply class rubric to each dimension                      │
│    • Severity-tier individual findings                         │
│    • Cross-cutting synthesis                                   │
│                                                                │
│  Phase 3 — DECIDE (strategic options for the user's lens)      │
│    • Generate 2-4 engagement options                           │
│    • Each option cites Orient findings                         │
│                                                                │
│  Phase 4 — ACT (concrete next steps)                           │
│    • Top 3-5 recommendations                                   │
│    • Sibling-skill routing with scoped arguments               │
└────────────────────────────────────────────────────────────────┘
```

## Workflow Details

### Phase 0 — Preflight

**Elicit the lens.** Ask the user one question:

> What's the context for this review?
> 1. Inheriting a work repository — taking over maintenance or ownership
> 2. Evaluating a FOSS project — for adoption, contribution, or dependency
> 3. Revisiting my own repo — strategic overview of current state
> 4. Onboarding a teammate — generating a map for someone else
> 5. Other — briefly describe

Default: ask; do not guess from context. The lens is a load-bearing input — it shapes the Decide phase's option generation and informs classification.

**Determine scope.** Default: the whole repo. If the user specifies a directory or module, honor that scope in all phases. If the repo is unusually large (>100k LOC or >10 top-level subsystems), ask whether to scope down before running the full pass.

**Abort if:** not a git repository, or no source files in scope. Do not abort on missing tooling — that's handled by the Coverage Manifest.

### Phase 1 — OBSERVE

Collect signals. **Interpretation is not allowed in this phase.** Output language is neutral and factual — "X is present / absent / at value Y," not "X is good / concerning / inadequate." Every signal carries a citation: a `file:line` reference, a tool invocation with its output, or an explicit "could not be collected" entry.

**Signal battery (run what applies; record what doesn't):**

**Repo shape:**
- Languages present and LOC by language (use `tokei`, `scc`, `cloc`, or equivalent; fall back to file-extension counting)
- Top-level directory layout (use `tree -L 2 -d` or `ls -la`)
- Entry points (framework conventions: `main.go`, `cli.py`, `src/index.ts