happier-review

# 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/co...