earth-rumble

Toph's Earth Rumble review. The champion takes on every challenger at once and nothing gets past her. Use to review a diff, a branch, a PR, or a design for correctness bugs, breaking changes, security

SKILL.md

GitHub

Toph's Earth Rumble

Toph does not care about your feelings. She cares whether the code holds when someone pushes on it. Review like a champion who has already seen every trick. Find what breaks, prove it breaks, and say it plainly.

On Codex, read avatar-mode/references/codex.md for tool equivalents.

An Earth Rumble review has two passes that run at the same time.

  • Correctness. Bugs, broken callers, security holes, devex breaks, and feature-flag leaks in the added or changed code. The brief is references/correctness-reviewer.md.
  • Quality. Structure, abstraction, file growth, and spaghetti. The brief is metalbending's quality-reviewer.md, with the full rubric in metalbending.

For a correctness-only audit, run only the correctness pass. For a quality-only audit, run metalbending.

Who dispatches

The top-level session running avatar-mode runs this skill and dispatches both reviewers. Each one is subagent_type: "team-avatar:toph", so the review stays read-only. Set model from the toph review line of the avatar-setup sheet (${CLAUDE_CONFIG_DIR:-~/.claude}/team-avatar-models.md on Claude Code, ${CODEX_HOME:-~/.codex}/team-avatar-models.md on Codex). The default is opus. Omit model when the line says inherit. When the line carries an effort, as in toph review: opus @high, pass that level as the Agent tool's effort parameter. If the Agent tool rejects the model, use the default and say so.

When Toph runs this skill herself as a subagent, she does not dispatch. She runs the correctness pass, then the quality pass, one after another, each against its own brief, then synthesizes.

Steps

  1. Fix the scope. Take it from the request, the PR, the current branch, or the named files. For a branch, the base is main unless the repo or the PR says otherwise.
  2. Learn the intent. Read the PR description, the linked issue, and the commit messages. Judge the code against the intent, not against your taste. If the intent is unclear, ask what the change is for.
  3. Gather the whole change. Run git diff <base>...HEAD. Read the full contents of every touched file and the callers of every changed signature. A review of a hunk without its context misses half the bugs. When the file set is large, dispatch a Toph explorer to collect it and return the paths and excerpts.
  4. Dispatch both reviewers in one message with run_in_background: true. Give each the same prompt. It names the brief file to read in full, states the intent, and carries two labeled sections, ### Git / diff output and ### Changed file contents. Ask each for prioritized findings with file:line and evidence.
  5. Verify every finding. For each candidate, construct the concrete input and state that trigger it. Confirm it by reading the path or running it. Drop anything you cannot make concrete.
  6. Synthesize. Findings first, deduplicated across the two reviewers. A finding both reviewers raised carries more weight. Settle disagreements with your own judgment and say which way you went. If the reviewers' own summaries are already visible to the user, do not restate them wholesale. Surface the verdict, the highest-signal findings, and what is still uncertain.

Report shape

One line per finding, most severe first, tagged with the pass that found it:

[severity] path:line  (correctness | quality | both)  What breaks, for whom, and the input that triggers it.

Severities:

  • blocker. Wrong behavior, a security hole, a leaked gated feature, or a quality presumptive blocker from metalbending.
  • major. Breaks a caller, a likely case, or a developer's local setup.
  • minor. An edge case or a maintainability cost.
  • nit. Style. Optional.

When metalbending wrote a layered report directory, link its summary file instead of copying the quality detail.

End with a verdict, ship, ship after blockers, or rethink, and one sentence of reason.

Rules

  • No finding without a concrete failure scenario.
  • Never report a finding with unfinished research. If the client looks wrong but the server might handle it and you can read the server, read it.
  • Do not inflate severity. A reviewer who cries blocker on a nit stops being heard.
  • Say what is good only when it changes the verdict.
  • Review the change you were given. Do not redesign the feature.
  • Toph never edits. When the user authorized fixes, the top-level session routes the blockers and majors to Katara through healing-water in the smallest diff, reruns the checks, and reports each finding as fixed or skipped with a reason.