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 Vimalk0703/shipworthy --skill receiving-code-reviewgit clone --depth 1 https://github.com/Vimalk0703/shipworthyWrote 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/vimalk0703/shipworthy/receiving-code-review)<a href="https://agentmods.dev/skills/vimalk0703/shipworthy/receiving-code-review"><img src="https://agentmods.dev/badge/skills/vimalk0703/shipworthy/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/vimalk0703/shipworthy/receiving-code-review"><img src="https://agentmods.dev/badge/skills/vimalk0703/shipworthy/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.00030 | $0.00432 |
| Opus 5.5 | $0.00012 | $0.00173 |
| Sonnet 5.5 | $0.00006 | $0.00086 |
| Haiku 4.5 | $0.00003 | $0.00043 |
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 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.
What it actually says
Receiving Code Review
Core Principle
Technical verification over performative agreement. Don't accept feedback just because it comes from a reviewer. Verify that the feedback is correct before acting on it.
Processing Feedback
For each issue raised:
1. Understand the Issue
Read the feedback carefully. What exactly is the concern? Is it about correctness, style, architecture, or performance?
2. Verify the Claim
- If the reviewer says "this will break when X": test it. Does X actually cause a break?
- If the reviewer says "this violates architecture rule Y": check architecture.md. Does it?
- If the reviewer suggests "use pattern Z instead": is pattern Z actually better here?
3. Respond with Evidence
If the feedback is correct:
- Fix the issue
- Show the fix with test evidence
- Thank the reviewer for catching it
If the feedback is incorrect:
- Explain why with evidence (test results, documentation, architecture.md)
- Don't be confrontational — provide facts
- If it's a judgment call, explain your reasoning
If the feedback is partially correct:
- Acknowledge the valid part and fix it
- Explain why the other part doesn't apply
Anti-Patterns
- Performative agreement — "Yes, you're right, I'll fix that" without verifying
- Defensive rejection — dismissing feedback without investigation
- Scope creep — using review feedback as an excuse to refactor unrelated code
- Fix-and-forget — fixing the symptom without understanding the root cause
After Addressing All Feedback
- Run the full test suite
- Verify all Critical and Important issues are resolved
- Summarize what was changed and why
- Request re-review if significant changes were made
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 · 54 lines · 30 tokens per session scan A 4d0bc427f656
receiving-code-review is a skill published in the GitHub repository Vimalk0703/shipworthy (6 stars, last pushed 6mo ago), licensed MIT. It adds 30 tokens to every session and 432 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-comment-discipline
Apply whenever writing or editing source code in any core's build agent (backend-eng, ui-builder, or equivalent). Governs when a comment belongs at all and what it may say. Default is no comment; a comment is only for the non-obvious. Never restates what the code does, never narrates the task, fix, or conversation…
dare-review
Audita uma task DARE implementada — cruza a spec com o código real para detectar stubs, mocks fora de testes, funções vazias, TODOs e validar critério-a-critério se a implementação satisfaz o que a spec prometeu. Use antes de marcar uma task como DONE, ou quando o dev pedir revisão manual. Combina análise estática…
code-review
Reviews code following team development standards. Use when reviewing code, checking PRs, or before merging.
tech-debt
Track, categorize and prioritize technical debt across the codebase — scans for debt indicators, maintains a register.
review-pr
Perform a comprehensive code review of a pull request.
sonarqube
Analyze SonarCloud quality issues for a specific PR.