Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add cboone/agent-harness-plugins --skill review-colleague-prgit clone --depth 1 https://github.com/cboone/agent-harness-pluginsWrote 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/skills/cboone/agent-harness-plugins/review-colleague-pr)<a href="https://agentmods.dev/skills/cboone/agent-harness-plugins/review-colleague-pr"><img src="https://agentmods.dev/badge/skills/cboone/agent-harness-plugins/review-colleague-pr/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/cboone/agent-harness-plugins/review-colleague-pr"><img src="https://agentmods.dev/badge/skills/cboone/agent-harness-plugins/review-colleague-pr.svg" alt="Reviewed on agentmods" width="80" 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.00038 | $0.10290 |
| Opus 5.5 | $0.00015 | $0.04116 |
| Sonnet 5.5 | $0.00008 | $0.02058 |
| Haiku 4.5 | $0.00004 | $0.01029 |
Grade A, and why
review-colleague-pr 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 14d ago.
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 — 396 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Review Colleague PR
Assess a colleague's pull request and brief the user in chat, so they can write considerate, well-founded feedback in their own words.
A good review of someone else's work is not a count of findings. It understands what the author set out to do, judges fairly whether they did it and whether the change moves the codebase in a good direction, and raises the few things that matter in a way that respects the work. The report is for the user, not the author: plain, direct, and short. The user decides what to say and how.
This skill reviews someone else's PR. For the user's own branch, use the review-branch skill instead.
Options
The user may provide these inline:
<pr-number>: The PR to review (e.g.,/review-colleague-pr 123). Defaults to the PR for the current branch- Requirement docs: Any URLs or pasted text after the number are external requirements (a spec, a design doc, a ticket in another tracker)
- --fast (default): Focus on what would block merge or change the verdict, reading and reporting less (see Review Modes)
- --thorough: Run the full review: every requirements source, every reviewable diff, attribution on re-reviews, and every report section
- --full: Review the whole PR even if the user has reviewed it before
- --since
<ref>: Treat this commit as the point of the user's last review instead of detecting it
If both --fast and --thorough are supplied, ask which one the user meant and stop. --full and --since control re-review scope (the whole PR or only the change since the last review), not depth, so they combine freely with either mode.
Review Modes
Fast mode is the default. It answers one question: is there anything significant wrong with this PR? It skips nits, follow-up-level points, and small details. Thorough mode runs every step as written below.
Fast mode changes only these stages. Everything else runs identically in both modes. The Ground Rules, secret exclusions, snapshot fetching, revalidation, the two-restart limit, and the confirmation bar never relax in fast mode.
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.
- 14d ago Changed · +1 lines · -3 tokens per session 39057750d763
- 15d ago Changed · +58 lines 4f4e0e976c06
- 26d ago Changed · -11 lines · -153 tokens per session 6c2db8a33426
- 28d ago First seen · 348 lines · 194 tokens per session scan A a5242c543663
review-colleague-pr is a skill published in the GitHub repository cboone/agent-harness-plugins (2 stars, last pushed yesterday), licensed MIT. It adds 38 tokens to every session and 10,290 once invoked, about $0.0002 per session on Opus 5.5. 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-17.
Other skills, from other repositories
review-pr
Review a pull request for conceptual fit, architecture impact, adversarial failure modes, security risk, docs impact, regression risk, test coverage, and merge readiness. Use when asked to review a PR, check whether a PR is safe to merge, decide if more tests are needed, perform adversarial or security review, or…
software-code-refactoring
Improve production code quality while preserving all existing test behavior. Commonly used for the Refactor phase of TDD red-green-refactor, but applicable to any codebase with tests. Use when production code works but needs cleanup — reducing duplication, improving naming, simplifying complexity, aligning with…
drift-check
Pre-PR advisory check for deviations from the project spec. Read-only analysis.
review-preflight
Review tooling for a PR: review-preflight prints REVIEW.md's criteria and the PR's live gate state before a review; ci-triage maps a PR's failing checks to already-filed issues.
remarc
Manage Remarc session comments and contextual feedback. Use when the user mentions Remarc sessions, comments, handoff, triage, review, addressing, resolving, status updates, or summaries.
fuck-over-engineering
Use when the user asks what could be deleted or reduced to simplify a codebase, says "simplify", "over-engineered", or wants a repo-, folder-, or file-wide audit for over-engineering — hunts dead code, reinvented stdlib, needless dependencies, and single-implementation abstractions, reports ranked cuts, applies only…