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

All radin state for a project lives inside that project's repo, in .claude/.radin/ at the repo root (example: repo /Users/x/proj → /Users/x/proj/.claude/.radin/BACKLOG.md). Do not compute this path yourself — run the shared namespace-resolution script and read REPO_ROOT, NAMESPACE_DIR, BACKLOG_FILE from its output in the same Bash call (record baseline line count there too so you can report net-new findings at end):

source <(bash "$HOME/.claude/radin-lib/radin-namespace.sh" | sed 's/^/export /')
wc -l "$BACKLOG_FILE" 2>/dev/null || echo 0

Re-run the source line in any later Bash call before using these variables.

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.