Borrowing it
Nothing to install: this file belongs to FTShare-Lab/agent-claim-network. 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/FTShare-Lab/agent-claim-network/main/.agents/skills/code-review/SKILL.mdgit clone --depth 1 https://github.com/FTShare-Lab/agent-claim-networkWrote 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/ftshare-lab/agent-claim-network/code-review)<a href="https://agentmods.dev/skills/ftshare-lab/agent-claim-network/code-review"><img src="https://agentmods.dev/badge/skills/ftshare-lab/agent-claim-network/code-review/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/ftshare-lab/agent-claim-network/code-review"><img src="https://agentmods.dev/badge/skills/ftshare-lab/agent-claim-network/code-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00041 | $0.01091 |
| Opus 5.5 | $0.00016 | $0.00436 |
| Sonnet 5.5 | $0.00008 | $0.00218 |
| Haiku 4.5 | $0.00004 | $0.00109 |
Grade A, and why
code-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 2mo 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Multi-Pass Code Review
1. Define the review range
Inspect git status, the relevant diff, and the surrounding implementation. Preserve unrelated working-tree changes. Review the code that actually runs; do not substitute an old PRD for the current behavior.
2. Perform the local review
Follow the repository's AGENTS.md and focus on actionable defects:
- business-logic and state-transition gaps;
- persistence, recovery, compatibility, and protocol-boundary problems;
- async blocking, cancellation, locking, process-lifecycle, and resource leaks;
- tool authorization, path handling, secrets, and network exposure;
- user-visible TUI errors, misleading status, and broken interaction flows;
- missing tests for realistic failure paths.
Do not report formatting already covered by rustfmt, speculative low-probability crashes without a credible trigger, or style preferences that do not affect correctness or maintainability.
Unless the user explicitly requests a broader review, use this default severity boundary:
- Ignore extreme edge cases and crashes, layout shifts, or state mismatches assessed as extremely unlikely. Do not inflate them into actionable findings.
- Keep the actionable and automatic-fix set to P0 and P1 findings with a realistic trigger and material impact.
- Prioritize real business-logic, security/data-integrity, and user-visible TUI defects. Do not automatically fix P2/P3 findings; mention a lower-severity item only when it materially affects a decision, and leave it deferred unless the user expands the scope.
3. Obtain an external Codex review
Run one direct, read-only codex exec --json review pass. The external prompt must forbid invoking this skill, running another codex process, calling delegation tools, or modifying files.
Requirements:
- Require
codexto be available onPATH; do not source a personal shell startup file. - Create a run directory with
mktemp -doutside the repository. - Save JSONL, stderr, and the final response so partial output survives interruption.
- Use the Codex CLI's configured default model. Only pass
-mwhenREVIEW_MODELis explicitly set by the caller. - Default the external timeout to 30 minutes (
1800seconds), overridable throughREVIEW_TIMEOUT_SECONDS. - If the review times out, inspect partial artifacts, split the diff into smaller review units, and retry. Do not declare the external pass complete without a usable result.
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.
- 2mo ago First seen · 91 lines · 41 tokens per session scan A b24c890c3e76
code-review is a skill published in the GitHub repository FTShare-Lab/agent-claim-network (44 stars, last pushed 3d ago), licensed Apache-2.0. It adds 41 tokens to every session and 1,091 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-08-30.
Other skills, from other repositories
github-code-review
Review code changes by analyzing git diffs, leaving inline comments on PRs, and performing thorough pre-push review. Works with gh CLI or falls back to git + GitHub REST API via curl.
kverus-review
Review uncommitted or recent Verus code changes for exec-code modifications, unnecessary == introductions, and verification issues. Use before committing to catch regressions in executable semantics, set reasoning, and proof quality.
kverus-postprocess
Final cleanup for Verus proof changes: consume cached dynamic review rules, delegate stale GitHub refreshes to a subagent, verify, simplify redundant proof code through kverus-strip, format, and run local checks. Use after proof-sensitive KVerus work or before finalizing Verus changes.
review
Review code changes, pull requests, patches, or a scoped code area for actionable correctness, security, compatibility, and test risks with file and line evidence. Use for review or audit requests; do not use for general proofreading, feature implementation, or debugging a reported failure when the user wants a fix.
code-review-feedback
Use when receiving code-review feedback, before implementing suggestions — especially when feedback seems unclear or technically questionable. Verify against the codebase and reason about each item instead of agreeing performatively or implementing blindly.
debug
Diagnose a concrete failure, regression, crash, hang, flaky test, or incorrect runtime behavior by reproducing it, testing hypotheses, and identifying the evidence-backed root cause. Use when symptoms or failing output exist; do not use for feature implementation without a failure, general code review, or a conceptual…