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 tranhieutt/software_development_department --skill receiving-code-reviewgit clone --depth 1 https://github.com/tranhieutt/software_development_departmentWrote 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/tranhieutt/software_development_department/receiving-code-review)<a href="https://agentmods.dev/skills/tranhieutt/software_development_department/receiving-code-review"><img src="https://agentmods.dev/badge/skills/tranhieutt/software_development_department/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/tranhieutt/software_development_department/receiving-code-review"><img src="https://agentmods.dev/badge/skills/tranhieutt/software_development_department/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.00035 | $0.01534 |
| Opus 5 | $0.00017 | $0.00767 |
| Sonnet 5 | $0.00007 | $0.00307 |
| Haiku 4.5 | $0.00003 | $0.00153 |
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 8d 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 — 189 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Receiving Code Review
Purpose
receiving-code-review turns review feedback into controlled engineering work.
It prevents agents from blindly applying every suggestion, ignoring blockers, or
quietly expanding scope while "addressing comments."
This workflow is for response and remediation after review. It complements
code-review, which produces findings.
Core Rule
Every review comment must be classified, resolved with evidence, deferred with
an explicit owner, or rejected with a technical reason.
Do not mark a comment resolved because code changed nearby. Do not say feedback is addressed until the specific finding has fresh verification evidence.
Workflow
1. Collect Review Inputs
Gather the review material:
- PR or review comments
code-revieworcode-review-checklistoutput- Subagent spec-compliance or code-quality review findings
- The approved spec/plan, if the review refers to requirements
- The changed files or diff relevant to each finding
If the review feedback is missing, ask for it or inspect the available PR/review source. Do not invent likely comments.
2. Normalize Findings
Create one item per distinct finding. Preserve file and line references when available.
For each finding, record:
- Reviewer concern
- File/line or affected behavior
- Severity:
BLOCKER,MUST_FIX,SHOULD_FIX,NIT,QUESTION - Category:
correctness,security,performance,test,architecture,maintainability,style,docs,spec-drift, orunclear - Proposed disposition:
fix,reject,defer,needs-clarification, orroute-to-spec-evolution
When the finding is architectural or maintainability-oriented, also ask:
- Is reviewer pointing at a genuinely shallow module or only at code they dislike?
- Would the proposed fix deepen the seam, or only move complexity into another wrapper?
- Does the deletion test support the abstraction being kept, changed, or removed?
3. Decide Disposition
Use these rules:
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.
- 8d ago First seen · 189 lines · 35 tokens per session scan A 67e23f7947c7
receiving-code-review is a skill published in the GitHub repository tranhieutt/software_development_department (72 stars, last pushed 3mo ago), licensed MIT. It adds 35 tokens to every session and 1,534 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
review
Plan-aware graph-enhanced code review before merge. CRITICAL issues block merge. Use after fix/verify.
flutter-dart-code-review
Library-agnostic Flutter/Dart code review checklist covering widget best practices, state management patterns (BLoC, Riverpod, Provider, GetX, MobX, Signals), Dart idioms, performance, accessibility, security, and clean architecture.
verify-code-review
A code-review workflow that sends a change to several independent reviewers at the same time. The reviewers work in separate contexts and return their findings to the main review.
verify-multispec
A verification workflow for major releases or large code refactors. It uses four specialist teammates to review the change, question each other’s findings, and then shut down cleanly.
verify-paranoid
A conditional review workflow for critical modules before a pull request, which is a proposed code change awaiting review. It uses a strict senior-engineer review for important code and skips ordinary modules.
verify-second-opinion
A workflow for getting a second AI review when changes affect the rules and tools that coordinate other workflows.