Borrowing it
Nothing to install: this file belongs to nianyi778/jira-dev-mcp. 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/nianyi778/jira-dev-mcp/main/.agents/skills/code-review/SKILL.mdgit clone --depth 1 https://github.com/nianyi778/jira-dev-mcpWrote 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/nianyi778/jira-dev-mcp/code-review)<a href="https://agentmods.dev/skills/nianyi778/jira-dev-mcp/code-review"><img src="https://agentmods.dev/badge/skills/nianyi778/jira-dev-mcp/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/nianyi778/jira-dev-mcp/code-review"><img src="https://agentmods.dev/badge/skills/nianyi778/jira-dev-mcp/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.00028 | $0.03018 |
| Opus 5.5 | $0.00011 | $0.01207 |
| Sonnet 5.5 | $0.00006 | $0.00604 |
| Haiku 4.5 | $0.00003 | $0.00302 |
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 — 366 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review Skill
Comprehensive code review skill that combines PR review, self-review, and quality checks.
Usage
/code-review # Self-review: current branch vs main
/code-review <branch> # Self-review: current branch vs specified branch
/code-review pr <number> # PR review: review the specified PR
The argument is available as $ARGUMENTS.
Argument Parsing
$ARGUMENTS parsing:
- Empty → Self-review mode (base=main)
- "pr <number>" → PR review mode (use gh pr diff)
- Otherwise → Self-review mode (base=specified branch)
Review Process
IMPORTANT: Use Serena MCP extensively to analyze code efficiently while minimizing token consumption.
CRITICAL: Before starting any code review, you MUST read and understand the implementation guidelines:
- Read
@~/.claude/templates/frontend-implementation-guidelines.mdfor frontend code reviews - Read
@~/.claude/templates/backend-implementation-guidelines.mdfor backend code reviews - Apply the specific principles from these guidelines during your review
Step 1: Get Changes
For Self-Review (no args or branch name):
# Get current branch name
git branch --show-current
# Determine base branch (use main if $ARGUMENTS is empty, otherwise use $ARGUMENTS)
BASE_BRANCH=${ARGUMENTS:-main}
# Get list of changed files
git diff $BASE_BRANCH...HEAD --name-status
# Get commit history
git log $BASE_BRANCH..HEAD --oneline
# Get detailed diff
git diff $BASE_BRANCH...HEAD
For PR Review (pr <number>):
# Get PR information
gh pr view <number>
# Get PR diff
gh pr diff <number>
Step 2: Quality Check (All Files)
Perform quality checks on all changed files before detailed review:
Code Quality:
- Detect unused code (variables, parameters, functions, classes)
- Detect commented-out code blocks
- Detect unreachable code branches
Comment Quality:
- Detect progress/completion declarations ("implemented", "done", etc.)
- Detect date or version references in comments
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 · 366 lines · 28 tokens per session scan A 465d942588a3
code-review is a skill published in the GitHub repository nianyi778/jira-dev-mcp (0 stars, last pushed 6mo ago), licensed MIT. It adds 28 tokens to every session and 3,018 once invoked, about $0.0001 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-31.
Other skills, from other repositories
code-review
Review code for quality, maintainability, and correctness.
release-pr-review
Review pass on an open release PR (release/ → main) — the step between git-wrapup and release-and-publish when a project releases in gated release PR mode. Reads the PR's commit range through the code-simplifier lens plus a correctness review, verifies whatever an automated reviewer left on the PR, lands fixes as…
github-commenting
How to post clean, rich, deduplicated GitHub PR review comments — suggestion blocks, multi-line anchors, markers, formatting rules. Load before posting or fixing any PR comment.
vibecheck
Use immediately before declaring a task or session done—run the discipline checks that catch scope creep, leftover artifacts, unsolicited refactoring, and inflated prose, and block the completion claim on any failure unless the operator supplies a recorded override reason.
differential-review
Use when a proposed change claims to preserve or intentionally alter behavior and the delta must be proven between baseline and candidate—run both states, predict each observable shift, then compare return values, persistence, emitted events, logs, exit codes, wire formats, timing, errors, empty cases, and boundaries.…
semgrep-rule-author
Use after a defect pattern is confirmed and you need a reusable Semgrep detector for sibling instances: derive syntactic or taint rules from vulnerable and safe fixtures, encode project sanitizers, and measure repository-wide false positives. Not for choosing generic rulesets or scanning only a change.