pixtuoid: Skill for Claude Code

local-review — local orchestration of REVIEW.md

Every rule is REVIEW.md's; fill briefs from it, never a paraphrase here.

When to run

• Diff scope: the diff matches a REVIEW.md escalation row marked local. The correctness and design lenses are the automatic review's; never re-run them here.
• Whole-codebase scope: "audit the repo", a pre-release or periodic sweep.

Diff scope

1. Isolate the branch in a worktree (two sessions on one tree race on HEAD). Note path, branch, base and head sha.

2. Dispatch one lens per matching local row, in parallel, in the background: model: sonnet for a lens that reads evidence or runs a mechanical check (test lists, mutations, renders, a walk), opus only for a design gate. Each briefed:

   You are the <row> lens for <PR/branch> on pixtuoid.
   Worktree: <path> (branch <name>, base <sha>, head <sha>), read-only;
   stop if HEAD is not that head.
   Diff: git -C <path> diff <base>..<head>.
   Read AGENTS.md, then apply REVIEW.md's <row> and its Common
   section.
   <change-specific claims (from the PR body's impl-plan answers) or design
   questions, one per line>
   Run the applicable gates; report each exit code as observed, never through
   a pipe. Each finding carries an integer confidence 0–100. Your final
   message is the report, ending in one verdict: APPROVE or
   REQUEST-CHANGES.
   

   The filled slots are the quality lever; a lazily filled one turns every lens generic.

3. Collect and verify. A one-word or placeholder return is a STUB, not a review: re-run that lens alone (#455). Verify every finding's premise yourself before coding a fix — read the comments on the item it names first — and REFUTE deliberate design with its mechanism.

4. Fold accepted findings into ONE commit, with a plan-miss: line per finding the plan never named.

5. Disposition each finding in a review thread. The bots open theirs; open each local finding the same way, then reply and resolve: