radin-review

name	radin-review
description	Run a thermo-nuclear code quality review over a scope (commit, PR, directory, or a range like "since yesterday") and log each finding as a BACKLOG.md entry instead of printing to terminal. Use for /radin-review, "review and log to backlog", "audit this commit/PR/directory and file backlog entries", "turn this review into a backlog".

Review to Backlog

Run /thermo-nuclear code quality review against caller-specified scope, persist every finding as structured entry in BACKLOG.md instead of just printing to terminal. Turns one-off strict review into durable backlog radin-execute (or human) can work through later.

Step 1: Resolve scope argument

User passes one argument, can be any of:

• Commit hash (e.g. a1b2c3d) — review that single commit's changes: git show <hash> / git diff <hash>^..<hash>.
• PR reference (e.g. #123, 123, or GitHub PR URL) — resolve via gh pr diff <number> (add --repo <owner>/<repo> if URL points elsewhere than current repo's remote).
• Directory path — review current state of everything under that path (not diff — read files as they stand today).
• Natural-language range (e.g. "last commits since yesterday", "commits since Monday", "the last 5 commits") — translate into concrete git log / git diff invocation, e.g. git log --since=yesterday --oneline then git diff <oldest-of-those>^..HEAD.
• No argument — default to working branch's diff against its base (git merge-base main HEAD or master, whichever exists), same default /code-review would use.

Argument ambiguous (e.g. could be commit hash or directory name, or PR number doesn't resolve via gh) — ask user, don't guess.

State resolved scope back in one line before proceeding, e.g.: Scope: commit a1b2c3d or Scope: PR #123 (algolia/foo) or Scope: directory src/auth/.

Step 2: Resolve project namespace, locate BACKLOG_FILE

Radin never writes backlog/state files into target repo. Run the shared namespace-resolution script — single source of truth for this logic, shared by every radin agent/skill — and read REPO_ROOT, NAMESPACE_DIR, and BACKLOG_FILE from its output:

bash "$HOME/.claude/radin-lib/radin-namespace.sh"

This creates $NAMESPACE_DIR/state, $NAMESPACE_DIR/plans, and $NAMESPACE_DIR/reviews, and best-effort upserts registry.json (a skipped upsert never blocks $BACKLOG_FILE from being written correctly). Use the printed REPO_ROOT / NAMESPACE_DIR / BACKLOG_FILE values for the rest of this session.

• Record baseline line count (wc -l "$BACKLOG_FILE" 2>/dev/null || echo 0) so you can report net-new findings at end.

Step 3: Run reviews

If code-review-graph is installed and wired for this repo (command -v code-review-graph succeeds, and its MCP tools are available) use detect_changes + get_review_context against the resolved scope first — risk-scored, token-efficient source context beats reading raw diffs/files cold. Not installed or not wired here: fall back to git show/git diff/reading the files directly, same as Step 1's scope resolution.

Invoke /thermo-nuclear against the resolved scope. Apply full standards: ambitious code-judo restructuring, 1k-line file smell, spaghetti branching, boundary/type cleanliness, canonical-layer leaks, orchestration atomicity — see that skill for complete rubric. Don't water down for this skill.

Then invoke the ponytail complexity pass over the same scope — /ponytail-review for a commit/PR/range (diff scope), /ponytail-audit for a directory (whole-tree scope). It hunts a different axis than thermo-nuclear (over-engineering, dead flexibility, reinvented stdlib/native code) and is meant to complement it, not duplicate it.

Step 4: Log every finding to BACKLOG.md

BACKLOG_FILE is organized into top-level category sections — ## feat, ## fix, ## chore, ## refactor — same vocabulary as a conventional-commit type. Create the file with a # Backlog heading first if it doesn't exist yet.

For each finding review surfaces, classify it:

• fix — the finding is an actual bug: incorrect behavior, not just structure.
• refactor — the finding is structural: spaghetti branching, a canonical- layer leak, a 1k-line-file smell, orchestration atomicity, or any other restructuring thermo-nuclear calls for that doesn't change behavior. Every ponytail-pass finding (delete:/stdlib:/native:/yagni:/shrink:) is structural by definition — classify these as refactor too.

If the section for that category doesn't exist yet, create it (in canonical order feat → fix → chore → refactor relative to whichever sections already exist), then append the entry under it:

### <short title>
**Scope:** <what was reviewed — commit hash / PR / directory / range from Step 1>
**Location:** <file path(s) and function/line if applicable>
**Finding:**
<the structural problem, stated the way the thermo-nuclear skill states it — direct,
specific, no hedging>
**Preferred remedy:**
<the concrete restructuring suggested — extract helper, delete wrapper, split file,
reframe state model, etc.>

The description under the title should be as exhaustive as the finding warrants — Scope/Location/Finding/Preferred remedy are that description's internal structure, not a separate schema.

Log every finding clearing either pass's bar — thermo-nuclear's or ponytail's — don't filter down to only the scariest one, but also don't pad the file with cosmetic nits neither skill would have raised itself. One entry per finding, appended in order the reviews produced them.

Step 5: Report back

Tell user:

• Resolved scope reviewed.
• How many findings logged (net-new lines/entries vs. Step 2 baseline).
• Path to BACKLOG.md written.
• Zero findings: say clearly the review passed both thermo-nuclear's and ponytail's approval bar with no logged issues — don't write an empty entry just to prove the skill ran.