Borrowing it
Nothing to install: this file belongs to IvanWng97/pixtuoid. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/IvanWng97/pixtuoid/main/.github/prompts/pr-review.prompt.mdgit clone --depth 1 https://github.com/IvanWng97/pixtuoidWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/ivanwng97/pixtuoid/pr-review)<a href="https://agentmods.dev/commands/ivanwng97/pixtuoid/pr-review"><img src="https://agentmods.dev/badge/commands/ivanwng97/pixtuoid/pr-review.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00000 | $0.02634 |
| Opus 5 | $0.00000 | $0.01317 |
| Sonnet 5 | $0.00000 | $0.00527 |
| Haiku 4.5 | $0.00000 | $0.00263 |
Grade A, and why
pr-review scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 171 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review briefs — what a reviewer can't derive on its own
Canonical for both scopes of two-lens-review (diff gate / whole-codebase
audit). The skill owns when to invoke and the convergence contract (round
caps, blocking bar, churn budget).
One-in-one-out. A line lives here only if it
changes reviewer BEHAVIOR: a repo-specific trap whose obvious reading is
wrong, a rule about what NOT to flag, or a verification act beyond reading
the diff. Generic defect hunting (logic, races, error handling, unwrap,
perf, design-debt judgment) is assumed — do it as on any codebase.
Architecture invariants and house conventions live in CLAUDE.md, which
every reviewer reads first; don't restate them here. An issue# appears only
where the rule would otherwise look arbitrary enough to get "fixed" away.
Repo-specific traps (the default instinct is wrong here)
- Creation polarity: only a proof-of-LIFE event may create/resurrect an entry; a death/exit/TTL signal for an absent id must no-op.
- Lifecycle authority: user/model-controllable CONTENT (transcript text, message bodies, tool args) never drives lifecycle/state transitions — structural markers + liveness signals only.
- Config writes: atomic AND never destructive on ANY error/skip/default arm — existing-but-unparseable is never rewritten, a skip never strips pre-existing hooks.
- A SET-but-EMPTY env var reads as unset (
io::nonempty_env). - Terminal egress strips Cc controls AND Cf bidi overrides (Trojan-Source).
- IPC endpoints: owner-only at creation (create-restricted-then-rename, never a process-global umask); treat a pre-existing endpoint as hostile.
- Per-CLI resolution POLICY is mirrored from that CLI's own resolver — the generic dirs/shellexpand answer IS the bug (#343).
- Upgrade path: state written by RELEASED versions survives; a fresh-install assumption that wipes an upgrader's config is a HIGH (#457).
- Compare
PathBufstructurally — a path-string assert with a hardcoded separator reds only in windows-test. - A dead fallback is debt, not safety: an arm whose trigger cannot fire, or that duplicates/contradicts an authority, gets flagged — but documented load-bearing defense (shim exit-0, config-never-wipe, liveness ladders) STAYS.
- Version adjudication: does THIS diff move the public surface or ship a feature, and is the 0.x bump right (patch=fix, minor=feature/breaking)?
- Comments follow CLAUDE.md's comment rules verbatim (WHY-only, semantic, no length cap for an earned WHY).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 171 lines · 0 tokens per session scan A 86c79a9f0a8a
pr-review is a command published in the GitHub repository IvanWng97/pixtuoid (469 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 2,634 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-06.
Other commands, from other repositories
review-branch
Review the current branch's diff against base by dispatching atomic-reviewer. No orchestration loop, no spec required — pre-flight before /commit pr or /commit merge.
advanced-code-review-context
Advanced Code Review Phase 2: Context Analysis - load previous reviews, PR history, declined items.
code-review-give
Give mode for code-review: Review someone else's code with multi-pass analysis and structured recommendations.
mach12:issue-review
Read a GitHub issue and all comments, review the implementation plan, and present findings.
pr-distill
Analyze a PR and generate a review distillation report that categorizes changes by review necessity.
review-design-verify
Phases 4-5 of reviewing-design-docs: Interface Verification + Implementation Simulation.