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 FradSer/dotclaude --skill receiving-code-reviewgit clone --depth 1 https://github.com/FradSer/dotclaudeWrote 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/fradser/dotclaude/receiving-code-review)<a href="https://agentmods.dev/skills/fradser/dotclaude/receiving-code-review"><img src="https://agentmods.dev/badge/skills/fradser/dotclaude/receiving-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/fradser/dotclaude/receiving-code-review"><img src="https://agentmods.dev/badge/skills/fradser/dotclaude/receiving-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.00055 | $0.00938 |
| Opus 5.5 | $0.00022 | $0.00375 |
| Sonnet 5.5 | $0.00011 | $0.00188 |
| Haiku 4.5 | $0.00006 | $0.00094 |
Grade A, and why
receiving-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 22d 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Receiving Code Review (the evaluator REWORK loop)
The superpowers-evaluator returns REWORK with file:line evidence. Your job is to fix the right thing — not to please the evaluator.
Core principle: Verify before implementing. Ask before assuming. Technical correctness over social comfort. The evaluator is a red-team reviewer, not an order-giver.
The Response Pattern
Run this for each rework item before changing code:
- READ the full rework item (file:line + what failed + corrective action) without reacting.
- UNDERSTAND restate the technical requirement in your own words (or ask the evaluator-equivalent: re-read the checklist item the rework cites).
- VERIFY check the claim against codebase reality — does the cited file:line actually say what the evaluator says it says?
- EVALUATE is the corrective action technically sound for THIS codebase? (see Push Back below)
- RESPOND with a technical acknowledgment or a reasoned pushback — never performative agreement.
- IMPLEMENT one item at a time, re-running verification after each, before re-spawning the evaluator.
Forbidden Responses
NEVER output, even when the evaluator is right:
- "You're absolutely right!" / "Great point!" / "Excellent feedback!" / "Thanks for catching that"
- "Let me implement that now" before verification
- Any gratitude expression or performative agreement
INSTEAD:
- Restate the technical requirement
- Ask a clarifying question if the item is unclear
- Push back with technical reasoning if wrong
- Just fix it and show the diff — actions speak, the code shows you heard it
Handling Unclear Items
If ANY rework item is unclear, do NOT implement the clear ones and defer the unclear ones. Items may be related — partial understanding produces wrong implementation.
Evaluator: 4 rework items. You understand items 1,2,4. Unclear on item 3.
WRONG: implement 1,2,4 now, ask about 3 later
RIGHT: re-read the cited checklist item for 3; if still unclear, note the
ambiguity in your return and implement 1,2,4 only after 3 is resolved
(or explicitly mark 3 as [AUTO-RESOLVED] per the sprint contract's
Autonomous Resolution Protocol with the most concrete interpretation)
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.
- 22d ago First seen · 81 lines · 55 tokens per session scan A fcb7e8babb56
receiving-code-review is a skill published in the GitHub repository FradSer/dotclaude (593 stars, last pushed 7d ago), licensed MIT. It adds 55 tokens to every session and 938 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-24.
Other skills, from other repositories
adversarial-reviewer
Stress-test a code change for concrete correctness defects, unsafe assumptions, and failure modes. Use when the user explicitly asks for an adversarial review, a deep bug hunt, or to tear a change apart. Do not use for ordinary review, style feedback, or general improvement suggestions.
gsd-ns-review
quality gates | code review debug audit security eval ui.
gitnexus
A code-graph analysis add-on for examining an existing codebase, including symbols, call paths, execution flows, and effects across repositories. It can query GitNexus through its command-line or MCP interfaces.
issue
Use when starting a chain from a GitHub issue — turning an issue URL or number into a triaged, planned, dispatched, and reviewed pull request. Classifies the thread (bug → root-cause discipline, feature → plan chain, question → drafted reply), synthesizes a spec from the issue's own acceptance criteria, then runs the…
cleanup-code-inspections
Reduce technical debt and improve code quality by systematically resolving static analysis warnings.
superlint
This skill describes the mandatory standard operating procedure for using our internal SuperLint tool. Use this when tasks require fixing code quality issues according to corporate standards.