name: bubble-review description: Review a change at a stated depth (glance, delta, standard, full bubble) from a scratch copy, and give a PASS or FAIL verdict with REQUIRED, SHOULD and NOTE findings across nine bubble categories. Use when asked to review a diff, branch or tip. when_to_use: When asked to review, "find bubbles", "any bubbles?", or to judge a builder's tip before landing. allowed-tools: Bash(hh-resolve ) Bash(hh-gate-verify ) Bash(hh-slot status) Bash(hh-slot release ) Bash(hh-settings resolve ) Read Grep Glob metadata: version: "1.0.1"

hivehouse: bubble-review

Run hh-resolve rules and hh-resolve role reviewer and read the files they print first (the project's or the user's own custom/ file when there is one, else the plugin's). A bubble is anything in a diff that fits one of the nine categories in ${CLAUDE_SKILL_DIR}/categories.md; read that file before a standard or full review. You are read-only: you change no code in any worktree.

Call every hh-* executable and every git command on its own, never inside a compound command. No git rule is pre-approved, so each git call asks. Test runs go through hh-slot run, which is not pre-approved and will ask; that is intended.

Depth

The orchestrator states the depth in the request. You may raise it with a reason; never lower it.

If no depth is stated, ask; if you cannot ask, take standard and say so.

Procedure

1. Task and diff. Read the task first, then git log <base>..<tip> and git diff <base>..<tip>. Note every file

and function changed and whether it is the right place.

1. Scratch copy. Work in a scratch directory, never the builder's worktree or the main tree: `git archive -o

<scratch>.tar <tip>, then tar -x -f <scratch>.tar -C <scratch> (two commands, no pipe). Save a copy of any file before you break it and restore it with cp, never git checkout`.

1. Gate log. For a log hh-gate wrote: hh-gate-verify log <file> --commit <tip>. For a project's own headerless log:

hh-gate-verify log <file> --expect <steps> instead, never with --commit (that is always RED), and say in the verdict that the log names no commit. Then the commit rules with hh-gate-verify commits <base>..<tip> --style <style> --attribution <allow|deny>, each value from hh-settings resolve, so a project cannot loosen the owner's.

1. Changed tests only, through hh-slot run --wait <label> -- <command>. Do not run the whole suite unless asked.
2. Break each new guard with one change: count that the change matched exactly once, confirm the test fails, restore

by copy. A break that matched twice or not at all is not evidence.

1. Scan the nine categories against the diff (full bubble: probe each with a concrete input). Look also at

what consumes each changed thing (callers, other services, exports), not only the changed lines.

1. Second opinion (a read-only Codex run or a Fable subagent) only when the orchestrator relays the owner's request

for one. Treat its findings as claims to verify, not verdicts.

Verdict

First line: PASS or FAIL, the depth, and the tip hash reviewed. Then findings grouped by category, each with file:line and the evidence, as:

• REQUIRED: blocks landing;
• SHOULD: fix soon, does not block;
• NOTE: information.

Then what you did not run and why (unrun checks are never implied). FAIL if any REQUIRED exists.