Borrowing it
Nothing to install: this file belongs to asgarovf/locusai. 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/asgarovf/locusai/master/.agents/skills/code-review/SKILL.mdgit clone --depth 1 https://github.com/asgarovf/locusaiWrote 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/asgarovf/locusai/code-review)<a href="https://agentmods.dev/skills/asgarovf/locusai/code-review"><img src="https://agentmods.dev/badge/skills/asgarovf/locusai/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/asgarovf/locusai/code-review"><img src="https://agentmods.dev/badge/skills/asgarovf/locusai/code-review.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.00049 | $0.02179 |
| Opus 5.5 | $0.00020 | $0.00872 |
| Sonnet 5.5 | $0.00010 | $0.00436 |
| Haiku 4.5 | $0.00005 | $0.00218 |
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 1mo 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- code-review — 95% identical, 9 lines differ
How it starts
The opening of the file, as written. The whole thing — 392 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review
When to use this skill
- Reviewing pull requests
- Checking code quality
- Providing feedback on implementations
- Identifying potential bugs
- Suggesting improvements
- Security audits
- Performance analysis
Instructions
Step 1: Understand the context
Read the PR description:
- What is the goal of this change?
- Which issues does it address?
- Are there any special considerations?
Check the scope:
- How many files changed?
- What type of changes? (feature, bugfix, refactor)
- Are tests included?
Step 2: High-level review
Architecture and design:
- Does the approach make sense?
- Is it consistent with existing patterns?
- Are there simpler alternatives?
- Is the code in the right place?
Code organization:
- Clear separation of concerns?
- Appropriate abstraction levels?
- Logical file/folder structure?
Step 3: Detailed code review
Naming:
- Variables: descriptive, meaningful names
- Functions: verb-based, clear purpose
- Classes: noun-based, single responsibility
- Constants: UPPER_CASE for true constants
- Avoid abbreviations unless widely known
Functions:
- Single responsibility
- Reasonable length (< 50 lines ideally)
- Clear inputs and outputs
- Minimal side effects
- Proper error handling
Classes and objects:
- Single responsibility principle
- Open/closed principle
- Liskov substitution principle
- Interface segregation
- Dependency inversion
Error handling:
- All errors caught and handled
- Meaningful error messages
- Proper logging
- No silent failures
- User-friendly errors for UI
Code quality:
- No code duplication (DRY)
- No dead code
- No commented-out code
- No magic numbers
- Consistent formatting
Step 4: Security review
Input validation:
- All user inputs validated
- Type checking
- Range checking
- Format validation
Authentication & Authorization:
- Proper authentication checks
- Authorization for sensitive operations
- Session management
- Password handling (hashing, salting)
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.
- 1mo ago First seen · 392 lines · 49 tokens per session scan A a0d8668746db
code-review is a skill published in the GitHub repository asgarovf/locusai (23 stars, last pushed 7mo ago), licensed MIT. It adds 49 tokens to every session and 2,179 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
code-review
Use to judge a concrete diff, branch, or GitHub PR on its own merits with no rsc-SDD spec/plan chain to key off — the spec-less giving pass behind /code-review: only findings you can defend, one verdict, read-only unless --comment or --fix. NOT the SDD gate keyed to 02-DOCS/wiki/sdd/ that also processes incoming…
argot-setup
Set argot up for a repository end to end — audit its history, decide what should shape its voice, fit, verify the fit actually catches things, tune the rules its own history says are noisy, and wire the places it runs (pre-write hook, pre-commit, MCP, CI). One sitting, one decision at a time, each proposed with the…
argot-check
Score your working changes with argot — flag code foreign to this repo's own patterns (unfamiliar dependencies, APIs, constructs), functions the repo already has, code filed in the wrong place, imports that break the repo's layering, and tests weakened, disabled, or deleted alongside a production change — before…
argot-review-pr
Review a specific pull request (or diff range) against this repo's learned patterns with argot, without checking it out — flag dependencies, APIs, and constructs foreign to how the repo is written, duplicated functions, misfiled code, layering breaks, and tests weakened, disabled, or deleted alongside a production…
argot-write-rule
Codify a repo convention argot's built-ins don't cover into a scripted custom rule — a .argot/rules/NAME/rule.toml manifest plus a sandboxed Rhai script that fires exactly like a built-in, gated on a green fixture suite before it ever sees a real diff. Use when the user asks to "write an argot rule for X", "codify…
argot-refresh
Refresh Argot's committed fit snapshot safely — first diagnose why maintenance is recommended, re-audit corpus scope and structural path changes, review stale mutes and policy entries with the user, then fit locally, verify, and prepare the reviewed .argot/ update. Use when argot status, argot check, MCP, or CI…