torch-ice-review

Files (3)

• README.md
• SKILL.md
• checklist.md

SKILL.md (first lines)

# Torch-ICE Architecture Review

Review torch-ice PRs that touch `SKILL.md`, `skills/`, `frameworks/`,
`.agents/skills/`, or `.claude/skills/` for architectural alignment with Torch-ICE's conventions —
not accelerator backends themselves (that's `torch-integration-capability-evaluation`;
don't confuse the two).

## Usage Modes

### No Argument

If invoked with nothing, don't guess — ask:

> What would you like me to review?
> - A PR number or URL (e.g. `16`, or the full GitHub URL)
> - A local branch (diffed against `main`)

### PR Number or URL

```
gh pr view <pr> --json number,title,body,author,headRefName,baseRefName,files,additions,deletions,reviews
gh pr diff <pr>
base_repo=$(gh pr view <pr> --json url -q .url | sed -E 's#https://github.com/([^/]+/[^/]+)/pull/.*#\1#')
git fetch https://github.com/$base_repo.git pull/<number>/head:pr-<number>-head
```

Fetch by explicit HTTPS URL parsed from `gh pr view <pr>`'s own `url` field —
never from a separate `gh repo view` call, and never from a local remote
named `origin`/`upstream`. `gh repo view` resolves whatever repo is
"current" for the local clone's remote config, independent of which PR was
asked for; in a clone with `origin` pointing at a personal fork and
`upstream` pointing at the canonical repo, it can resolve to a *different*
repo than the one the PR argument actually points at, silently fetching an
unrelated PR with the same number from the wrong repo. Deriving `base_repo`
from the PR's own resolved `url` instead ties the fetch to the exact repo
`gh pr view` already used for metadata, so it can't diverge.

This fetch matters even for a dry run: most PRs come from forks, so the
changed files won't exist on disk without it, and it's what inline-comment
line numbers (see Posting, below) get anchored against.

Wrap all of this in error handling: if `gh` isn't authenticated, the PR
doesn't exist, or the repo can't be resolved, report the exact error and
stop — don't guess at PR content.

### Local Branch Mode

```
git branch --show-current
git diff --name-only main...HEAD
git diff main...HEAD
git log main..HEAD --oneline
```

Use the branch name in place of a PR number throughout; there's no `gh pr`
context (title/body/author), so build the Summary from commit messages and
the diff instead.

### GitHub Actions Review Agent

`@torch-ice-review-agent` is a separate, comment-triggered Actions agent. It
posts an advisory PR comment and does not run this skill or submit a formal
GitHub review. This skill remains manual; use `--post` when a formal review
is wanted. Any future Actions wrapper for this skill would be separate.

## Applicability

Compare the changed-files list against `SKILL.md`, `skills/**`,
`frameworks/**`, `.agents/skills/**`, and `.claude/skills/**`. If none match, say so and stop — don't
produce a review.

## Review Philosophy

1. **Only report problems.** The review's job is to say what's wrong and
   what to change. Never write "X is fine," never praise a correct decision,
   never mention a passing check. If a category has nothing wrong, omit it
   entirely.
2. **Investigate, don't guess.** Read the actual diff and the referenced
   files before deciding something violates (or satisfies) a checklist item.
   A guess that's wrong is worse than no comment.
3. **Get the classification right first.** The "Framework vs. Evaluation
   Dimension" call at the top of the checklist decides which items even
   apply — most findings follow from getting this right.
4. **Fail closed on uncertainty.** If a claim can't be verified from the
   diff (e.g. it requires running code you don't have access to), say so
   explicitly — "requires manual verification" — rather than treating it as
   passing.
5. **Be specific.** Every finding cites a file:line or a diff excerpt, and
   names the fix. "This should use flags instead" beats "structure could be
   improved."
6. **No repetition.** Each finding appears in exactly one place in the
   output, under the one category it best fits.

## Review Workflow

### Step 1: Gather context

Use the commands from the relevant Usage Mode above.

### Step 2: Classify

Determine PR type using this precedence — check top to bottom, stop at the
first match (a PR commonly matches more than one bullet, e.g. adding a
`frameworks/` entry *and* editing the dispatch table in the same diff; that
dispatch edit is still checked under Dispatch & Orchestration, it doesn't
make the PR `mixed`):

1. Diff adds or substantively changes content under `skills/` or
   `frameworks/` → apply the "Framework vs. Evaluation Dimension" test from
   the checklist → `new-framework` or `new-evaluation-dimension`. Wins even
   when the same diff also touches `SKILL.md`.
2. Else, diff touches only `SKILL.md` dispatch/routing/flag logic, no new or
   changed `skills/`/`frameworks/` content → `orchestrator-change`.
3. Else, diff touches only `README.md`/prose → `docs-only`. Only the
   General Conventions category applies (specifically README/structure
   sync); skip straight to Step 6.
4. Else, diff is scoped to `.agents/skills/torch-ice-review/**` or
   `.claude/skills/torch-ice-review/**`
   (the review skill's own files) with no changes to `skills/`,

From TorchedHat/torch-ice, Apache-2.0.

More from TorchedHat/torch-ice