/happier-review

name: happier-review
description: Conduct evidence-backed Happier code, plan-completeness, session, worktree, feature, commit, branch, PR, codebase, and release-readiness reviews with affected-corridor analysis, high-confidence finding triage, meaningful parallel lanes, proportionate but comprehensive QA, optional root-cause fixes, and independent closeout. Use for deep review, audit, QA, pre-merge assessment, plan-vs-implementation verification, review-and-fix loops, or when asked to inspect all related code rather than only changed lines.

Happier Review

Use this as the only general review orchestrator for Happier. The superseded generic `review-protocol` and `code-reviewer` skills are archived and must not be invoked here; this skill absorbs their useful review categories and routes to the narrower repository skills that own testing, compatibility, diagnosis, and verification.

1. Normalize the request

Determine five independent values before reviewing:

1. **Target** — session, worktree, plan, feature/corridor, commit, branch/PR, bounded codebase, or release validation. 2. **Intent basis** — user request, plan, issue, PR description, ADR, or documented contract. 3. **Output mode** — `report`, `comment`, `qa`, `staged`, or `fix`. 4. **QA surfaces** — automated, browser, device, CLI/API/daemon, persistence/compatibility, platform, or release. 5. **Review class** — `advisory`, `boundary`, or `ship`.

Infer these from clear wording; ask only when the wrong target/base/mode would materially change the work or authorize writes the user did not request. Read [targets.md](references/targets.md) for target inference and mixed dirty-worktree attribution. For plan targets or plan-backed reviews, identify whether the plan is a draft under pre-approval review or an approved execution contract, then read [plan-completeness.md](references/plan-completeness.md). Do not turn an implementation-completeness audit into a second plan-design review.

Mode rules:

• `report`: review and QA only; recommendations, no source/config/test edits.
• `comment`: same as report, with concise PR-style comments backed by the full evidence record.
• `qa`: exercise the requested behavior and investigate failures without source edits or a general code-review mandate.
• `staged`: finish and present the reviewed finding/fix set, then wait for approval before source edits.
• `fix`: review, triage, implement authorized root-cause fixes, validate, and re-review.

If the request contains several example prompts with different modes, treat them as examples. Follow the user's actual requested deliverable; do not merge contradictory example clauses into one execution mode.

Review-class rules:

• `advisory`: inspect moving, dirty, partial, or completed work and report evidence-backed findings without a completeness or ship verdict;
• `boundary`: review a substantial integrated batch or plan gate and decide whether that boundary is ready to close;
• `ship`: issue a final security/data/schema/user-visible/release verdict using current deciding evidence and a different reviewer where required.

An explicit user review request is sufficient reason to review current work. Do not wait for unrelated work to stop moving; reconcile materially changed observations before a boundary or ship verdict.

2. Establish the review basis

Never equate the diff with the whole review scope.

• **Change basis:** exact staged, unstaged, untracked, commit, branch, PR, session-attributable, or named-feature files being judged.
• **Affected corridor:** canonical owner plus materially coupled callers, callees, producers, consumers, readers, writers, parsers, serializers, persistence, feature decisions, registries, adapters, tests/testkits, compatibility paths, and same-concept split-brains—even when unchanged.
• **Broader search:** risk-triggered searches outside the corridor for competing owners, bypasses, neighboring instances, and other consumers of changed contracts.

Classify observations as `introduced`, `exposed/activated`, `pre-existing corridor debt required for coherence`, or `unrelated observation`. Unrelated pre-existing issues do not enter the merge verdict. Read [review-standard.md](references/review-standard.md).

For architecture or cross-module relationship reviews, follow the repository Graphify instructions before raw exploration when its corpus is relevant.

3. Map intent, ownership, and risk before judging

Create a compact inventory before findings or QA:

• requested outcome and exclusions;
• exact change and intent basis;
• canonical owner and affected corridor;
• existing tests, harnesses, and live interfaces;
• split-brains, bypasses, legacy/compatibility paths, and removals promised;
• two or three highest-risk or quietest failure spots;
• affected user flows, states, failure/recovery paths, and compatibility directions.

Discovery is complete when those facts are sufficient to decide correctness and coverage. Do not stop early to save tokens, and do not keep retrieving optional confirmation after the material gaps are closed.

Run available deterministic inventory, schema, generated-output, formatting, type, and contract checks before spending independent semantic-review effort on the same facts. Their success is supporting evidence only; it never substitutes for behavior, architecture, security, compatibility, UX, or completeness judgment.

4. Select review scopes

Always review:

• functional correctness and completeness;
• regression and blast radius;
• canonical ownership, split-brains, and bypasses;
• error/failure behavior;
• test value and validation sufficiency;
• intent/plan alignment and unjustified scope drift;
• maintainability of the changed corridor.

Activate conditional scopes only when reachable:

• security, auth, authorization, privacy, and secret handling;
• persistence, migrations, data integrity, transactions, idempotency, and concurrency;
• API/wire/CLI/IPC contracts and compatibili