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 agentmods add skills/kraitdev/skill.md/code-review-guidelinesnpx skills add KraitDev/skiLL.Md --skill code-review-guidelinesgit clone --depth 1 https://github.com/KraitDev/skiLL.MdWhat 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 | $0.00017 | $0.01323 |
| Opus 5 | $0.00009 | $0.00661 |
| Sonnet 5 | $0.00003 | $0.00265 |
| Haiku 4.5 | $0.00002 | $0.00132 |
Grade A, and why
code-review-guidelines 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 — 140 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Review Guidelines
Purpose
Code review catches bugs, ensures maintainability, and builds team knowledge. This skill provides a structured, objective, empathetic framework for reviewing code without causing friction. The goal is to improve the codebase while growing the team.
When to use
- Evaluating a Pull Request or Merge Request
- Providing constructive feedback to peers
- Ensuring code quality and architectural standards are met
- Building new team members' skills through feedback
When NOT to use
- Nitpicking personal coding style (use linters/formatters)
- Blocking on subjective preferences
- Reviewing without understanding context
Inputs required
- Pull request with code changes
- PR description explaining the why
- Linked ticket with context
- Test coverage (unit/integration tests)
Workflow
- Understand the Goal: Read the PR description and linked ticket FIRST. Understand WHY the change exists before reading code.
- Review Architecture: Check structural integrity and design. Does it fit the codebase? Are new dependencies justified? Is it the right abstraction level?
- Review Logic: Check for correct error handling, edge cases, off-by-one errors, and security implications.
- Check Tests: Verify new logic is covered by unit/integration tests that test actual behavior (not just code coverage).
- Consider Performance: Check for obvious performance issues (N+1 queries, memory leaks, synchronous blocking in async code).
- Provide Feedback: Leave comments that explain the WHY. Differentiate between blocking requests and suggestions (use "Nit:" or "Note:").
- Be Constructive: Phrase feedback as questions when possible ("Have you considered...?"). Assume positive intent.
Rules
- MUST assume positive intent; critique the code, not the author
- MUST automate style and formatting checks via Linters/Formatters (do NOT argue over spacing in PR)
- MUST approve immediately if code improves the codebase, even if not perfect
- MUST provide context and links when referring to standards or patterns
- MUST distinguish between blocking requests and optional suggestions
- MUST NOT block on personal coding style preferences
- MUST NOT require unrelated changes (keep scope focused)
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 · 140 lines · 17 tokens per session scan A 9c95e86f71bf
code-review-guidelines is a skill published in the GitHub repository KraitDev/skiLL.Md (7 stars, last pushed 2mo ago), licensed MIT. It adds 17 tokens to every session and 1,323 once invoked, about $0.0001 per session on Opus 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
evaluate-pattern-adoption
Run or plan this repository's pattern-adoption evidence evaluation locally with signed-in Codex agents. Use when asked to refresh stale evidence, assess stable or exploratory patterns, evaluate one or all catalog patterns, discover possible new patterns, or prepare a reviewable evidence PR without model-backed GitHub…
code-review
Systematic code review for bugs, security, style, and performance.
contributing-to-awesome-claude
Use when writing, testing, or preparing ANY contribution or pull request to the JSONbored/awesome-claude (HeyClaude) repo — adding a community content entry (agent/MCP server/skill/hook/command/rule/guide/collection/statusline), or making a platform/code change (website, registry package, MCP package, scripts). The…
contributor-pipeline-gardening
Maintenance of the contributor issue pipeline for JSONbored/awesome-claude (HeyClaude) — closing issues that are already done but not marked so, and keeping a small, high-value contributor-available backlog stocked with real website/content/feature/bugfix work. Runs every 24h via a dedicated scheduled task. Invoke for…
代码审查员
专业代码审查专家，提供建设性、可操作的反馈，聚焦正确性、可维护性、安全性和性能，而非代码风格偏好。.
pr-review
Review a GitHub pull request and post one formal review — advance the existing discussion and give precision-first, high-signal feedback. Judgement on the diff, not a build gate — CI validates that it builds, and a targeted probe is allowed as evidence. Use when asked to review a PR or on a cron PR scan.