git:20260910.cf5c534 to git:20260910.3f60a9f

---

name: radin-review

description: |

Run a thermo-nuclear code quality review over a scope (commit, PR, directory,

or a range like "since yesterday"), triage the findings with the user, and

log the ones they keep as backlog entries 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 the strict review passes against a caller-specified scope and persist

every finding the user agrees to as a backlog entry instead of terminal

output. That leaves a durable backlog `radin-execute` (or a human) works

through later.

## Step 1: Resolve scope argument

Resolve the argument (or its absence) via the shared CLI. Don't probe

git/gh by hand:

```bash

```

It settles commit hashes, PR references, directory paths, and the

no-argument default (working branch's diff against its merge-base with

main/master). Route on exit code:

- **0**: resolved. It prints `type`/`scope`/`command` lines; run the

printed command to get the scope's content.

- **1**: not a commit, PR, or directory. A natural-language range ("the

last 5 commits", "since yesterday") is yours to translate into concrete

`git log`/`git diff` invocations. Anything else: report it as

unresolvable.

- **2**: ambiguous (candidates on stderr, e.g. both a PR number and a

directory). Interactive: ask which one. Non-interactive (e.g.

radin-execute's reviewer sub-agent): report both readings and stop, so the

caller retries with an unambiguous scope or resolves it with the user.

State the resolved scope in one line before proceeding, e.g.

`Scope: commit a1b2c3d` or `Scope: directory src/auth/`.

## Scope discipline

The resolved scope is the whole review surface. A finding qualifies only if

the scope introduced it.

- **Diff scope** (commit, PR, branch, range): only lines the diff adds or

changes. Code that already existed and the diff left alone is out of

scope, even in a file the diff touches, even when it is worse than what

the diff added. Read surrounding code for context, never to find

findings.

- **Directory scope**: every file under that path, nothing outside it.

- Out-of-scope problem the diff makes worse: report it only when the

in-scope change is what makes it wrong, and say which changed line

causes that.

A finding you cannot tie to a specific in-scope line is not a finding here,

however real the problem is.

## Step 2: Record backlog baseline

Backlog writes go through

task files. Record the baseline for the end-of-run count:

```bash

```

## Step 3: Run reviews

If `code-review-graph` is installed and wired for this repo, use

`detect_changes` + `get_review_context` against the scope first, because

risk-scored context beats reading raw diffs cold. Otherwise fall back to

`git show`/`git diff`/reading files.

Invoke `/thermo-nuclear` against the scope.

Then invoke the ponytail pass over the same scope: `/ponytail:ponytail-review` for a

diff scope (commit/PR/range), `/ponytail:ponytail-audit` for a directory. It hunts a

different axis (over-engineering, dead flexibility, reinvented stdlib/native

code) and complements thermo-nuclear.

Name the exact scope in each invocation and restate the scope discipline

above. It narrows what both rubrics look at, never how hard they look.

## Step 4: Present findings and get agreement

Nothing reaches the backlog until the user agrees to it. First, drop the

out-of-scope findings yourself: for a diff scope, check each finding's cited

line against the diff, because both passes read whole files and surface

findings this skill must drop.

Then classify each survivor:

- **fix**: an actual bug, meaning incorrect behavior rather than structure.

- **refactor**: structural. That covers anything thermo-nuclear's rubric

flags without a behavior change, and every ponytail finding

(`delete:`/`stdlib:`/`native:`/`yagni:`/`shrink:`) by definition.

Print the numbered list — one line each: number, category, location, the

finding in a clause. Mark the ones you recommend tackling. Recommend on

severity and effort, not on count; recommending all of them is a valid

answer when they all earn it.

Then gate on `AskUserQuestion` (single select):

1. **Recommended only** — log the ones you marked.

2. **All** — log every in-scope finding.

The tool's own free-text field already covers a hand-picked subset, so don't

add a third option for it. If the user types numbers instead of picking,

restate the surviving set in one line before continuing. Iterate if they

correct it.

**Non-interactive caller** (e.g. radin-execute's reviewer sub-agent, which

has no `AskUserQuestion`): skip this gate and Step 5, log every in-scope

finding, and say in Step 7's report that no triage happened.

## Step 5: Optional refinement pass

Ask one yes/no on `AskUserQuestion`: refine the selected findings before

logging?

**No**: go to Step 6 with the entries as reviewed.

**Yes**: invoke `/mattpocock-skills:grilling` over the selected findings, one

finding at a time, in order. Name the finding and what is open about it

(scope too wide, remedy wrong, priority off, a constraint the review cannot

see). Grilling asks the actual questions one at a time and won't finalize

until the answer is settled — don't restate a finding's problem back to the

user as a yes/no, and don't batch findings into one pass. Fold each settled

answer into that finding's category, title, and body before moving to the

next finding. Drop a finding the user argues away, and say so.

## Step 6: Log the agreed findings to backlog

Append each via the CLI:

```bash

**Scope:** <what was reviewed, from Step 1>

**Location:** <file path(s) and function/line if applicable>

**Finding:**

<the problem, stated the way the review skill states it: direct, specific>

**Preferred remedy:**

<the concrete restructuring suggested>

EOF

```

Those four labels are the description's own internal structure. Make the

body as exhaustive as the finding warrants, and carry Step 5's refinements

into it.

Log one entry per agreed finding, in the order presented. Log nothing the

user discarded.

## Step 7: Report back

- The resolved scope reviewed.

- Findings logged (net-new vs. the Step 2 baseline).

- Findings the user discarded, as a count.

- Count of findings dropped as out of scope, if any, in one line with no

detail.

- The backlog index path.

- Zero findings: say the review passed both bars, and don't write an empty

entry to prove the skill ran. Same when the user discarded all of them —

report that, and write nothing.

## Step 8: Backlog now, or execute now

Logged entries stay in the backlog either way — this only decides what

happens next. Ask one `AskUserQuestion` (single select):

1. **Leave in backlog** — stop here.

2. **Tackle now** — invoke `/radin-execute`. It prioritizes and executes the

whole backlog, not only these entries. Say that before it runs.

Skip this step when nothing was logged, and when the caller is

non-interactive.