Tidy

Tidy

Review the diff, then fix it when asked. One pass produces the report; the same pass, in apply mode, lands the fixes along with the simplifications a clean diff still hides.

• IS: review of a local diff, branch diff, PR, or named security scope, returning severity-tiered findings with file:line evidence; in apply mode, the smallest complete fixes for those findings plus diff-scoped simplification.
• IS NOT: creating PRs (pr-creator), CI failures and review threads (pr-babysitter), user-facing UX, accessibility, or rendered quality (ui-design Audit mode), library or CLI ergonomics (dx-audit), architecture briefs and repo-wide guardrails (codebase-architecture), reviewing plans (planning), suite-wide test pruning to a measured target (test-audit).

Report or apply

Report is the default: "review my changes", "code review", a mode phrase below, or a PR number. Done is the report in the format under Output, carrying the range reviewed, each baseline command's last line, and the references read. The working tree stays as it was. Do not edit a file in report mode, even for a one-character fix; the moment the tree changes the user loses the read-only report they asked for.

Apply when the user says "tidy", "simplify", "fix", "apply the findings", or asks for the changes to be made. Done is the confirmed findings and supported simplifications in the working tree, the affected checks passing or their failures shown to be baseline, and a summary of what changed, what was left and why, and the check results. Apply mode edits any file the diff touches or a fix requires, and runs the repository's documented lint, type, and test commands without asking: they run locally against the working tree, and landing the changes is what was asked for. It does not commit, push, open PRs, add or upgrade dependencies, run migrations, or write outside the working tree. A report from earlier in the session is input, not authority: apply what current evidence supports and say why anything was not applied.

Harness precedence

Claude Code bundles /code-review (correctness plus cleanups, with --fix) and /security-review. A typed slash command runs the bundled skill; this one runs when named or when a mode phrase matches, and adds the Structural and Deslop modes, a whole-repo Security audit, the plausible tier the bundled commands filter out, REVIEW.md support, and the same report on any harness with git and the file tools. Findings from a bundled review already run this session enter the verdict step as candidates rather than being re-derived.

Mode dispatch

Pick one lens from the user's wording. references/severity-rubric.md loads in every mode; the table adds the mode's own rubric.

Conditional loads, in any mode:

• references/context-errors.md when the diff was agent-written, or adds, changes, or removes a module, system boundary, guard, or fallback.
• references/security-checklist.md for auth, input handling, external APIs, uploads, dependency or lockfile changes, or environment config.
• references/performance-checklist.md for fetching, rendering, images, dependencies, or bundle-affecting imports.
• references/test-gate.md when the diff adds or changes a test. A diff with no test changes loads nothing extra here.
• agents/openai.yaml only for the optional second-opinion pass in step 3. Otherwise it is launcher metadata for external runners and never loads.

Workflow

1. Discover target. Staged and unstaged changes first (git diff --stat, git diff --staged --stat); if clean, the branch diff against git merge-base HEAD origin/<default>. For a PR, gh pr diff <n> with the branch checked out. Record the range or ref pair; it goes in the report.

2. Gather context. Open the mode references and the conditional loads with the file tools. A filename in this skill is a pointer, not loaded content; if a required read fails, report the coverage gap rather than claiming the rubric was applied. Capture intent from the user's words, the commit messages, and the PR description. Load scoped AGENTS.md / CLAUDE.md and a root REVIEW.md where one exists: both override this skill's defaults when they conflict, so a pattern they mandate is not a finding. Reuse checks already run on this revision; when a candidate needs execution, run the documented command and preserve its exit status.

3. Review. Apply the loaded rubric and the high-signal criteria; shard large diffs. Five passes, because each finds what the others cannot:

   • Claims. Map each claim in the description or commit messages to a hunk, and each hunk to a claim. A claim with no hunk is a finding. A hunk with no claim goes under the readiness summary as an unstated change.
   • Added lines. Read every hunk, then the enclosing function. A bug on an unchanged line of a touched function is in scope: this diff re-exposed it.
   • Removed lines. For every deleted or replaced line, name the invariant it enforced, then find where the new code re-establishes it. If you cannot, that is the finding: a removed guard, a dropped error path, a narrowed validation, a deleted test that covered a real case.
   • Call sites. For each changed function, grep its callers for a new precondition, changed return shape, new exception, or ordering dependency; then check its callees.
   • Outside the diff. For each new module, guard, or fallback, open what the diff did not: the directory's existing exports, sibling implementations, every writer of the guarded value. A reimplemented helper, a change filed in the wrong system, and a fallback for a state nothing produces all read as clean code until you look at the file the diff never opened. references/context-errors.md carries the searches and the evidence each finding needs.

   Optional: where a different-model CLI is installed (codex exec, droid exec, or equivalent), run it read-only with agents/openai.yaml's default_prompt, then verdict its findings like your own. Its agreement is not corroboration; both instances read the same diff with the same missing context.

4. Verdict. Every candidate is confirmed (you can name the triggering input or state and the wrong output; quote the line), plausible (the mechanism is real, the trigger uncertain; say what would confirm it), or refuted (factually wrong or already guarded; quote the line that proves it). Plausible is the default: concurrency races, nil on a rare but reachable path, falsy-zero read as missing, an off-by-one on an unexcluded boundary, a regex that lost its anchor are all realistic. Refute only what the code disproves. Drop duplicates, mis-attributions, and pre-existing issues outside any touched function. File references/test-gate.md findings into the same two tiers, not a separate section.

5. Report or apply. Report per Output, structural blockers under Must fix before push, plausible findings marked. In apply mode, continue below.

Apply

Merge findings by root cause. Correctness fixes first, then ownership fixes, then simplification of what remains. Alongside the confirmed findings, sweep the diff on five angles:

Constraints:

• Guard deletion requires system evidence. Before removing a fallback, retry, lock, or validation, identify the writers, reachable states, staleness tolerance, and recovery owner. If its state cannot be ruled out, keep it and report the uncertainty.
• No whole-file rollback of unrelated edits. Scope formatters; git restore <path> discards the user's earlier edits in the same file.
• No abstraction quota. Fewer lines is not a win if it hides different lifecycles or drops behaviour. An existing owning subsystem beats a preferred generic pattern.
• Tests follow risk. Add or update a regression check when the edit changes behaviour that can independently regress; not for copy, a literal config change, or framework behaviour covered elsewhere.
• Confirmed test-gate findings get deleted or rewritten. A new or changed test that fails references/test-gate.md at confirmed tier does not stay in the diff; delete it, or rewrite it at the boundary the gate names. A plausible gate finding is reported, not auto-deleted.
• Stop on evidence. Once affected checks pass, repeat only for new changes or unresolved concerns. A second pass that keeps adding guards to the same spot means the mechanism, not the guard, is the problem: put the simpler shape to the person who owns the system.

Run the checks the changes affect plus repository-required gates, preserving exit codes and distinguishing baseline failures, then write the summary described under Report or apply.