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/phuonghx/aim-cli/receiving-code-reviewnpx skills add phuonghx/aim-cli --skill receiving-code-reviewgit clone --depth 1 https://github.com/phuonghx/aim-cliWhat 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.00083 | $0.01133 |
| Opus 5 | $0.00042 | $0.00566 |
| Sonnet 5 | $0.00017 | $0.00227 |
| Haiku 4.5 | $0.00008 | $0.00113 |
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 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 — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Receiving Code Review
Feedback is data about the change, not a verdict on you. Triage it, act, reply.
The Loop
Read all comments → Triage → Act (grouped) → Reply to each → Re-request review
↑ │
└──────────────── repeat until approved ───────────────────┘
Read every comment before touching code — later comments often reframe earlier ones.
Triage Each Comment
| Bucket | Meaning | Action |
|---|---|---|
| 🔴 Must-fix | Bug, security issue, broken contract, blocking concern | Fix before merge |
| 🟡 Should-fix | Real improvement, maintainability, clarity | Fix, or defer with a tracked follow-up |
| 🟢 Nit | Style/taste, non-blocking | Apply if cheap; it's polite to |
| ❓ Question | Reviewer is unsure, not (yet) asking for a change | Answer; a change may or may not follow |
| 💬 Discussion | Design disagreement | Resolve in thread before coding |
When a bucket is ambiguous, ask the reviewer rather than guessing.
Respond to Every Comment
Leave no comment unanswered — silence reads as "ignored."
- Made the change → reply
Done(link the commit if not auto-linked). - Disagree → give a one-line rationale and propose an alternative.
- Need clarification → ask a specific question, not "what do you mean?"
- Out of scope → acknowledge and link the follow-up issue.
Sample Reply Patterns
✅ Agreeing:
Good catch — fixed in a3f9c21. Added a test for the null case too.
🤔 Pushing back (with evidence, not ego):
I left this synchronous on purpose: it runs once at startup and the async
version complicated error handling (see benchmark in the thread). Open to
changing if you still prefer async.
❓ Clarifying:
Do you mean validate at the API boundary, or also in the service layer?
I went with the boundary to keep the service pure.
📌 Deferring:
Agreed this needs refactoring, but it's outside this PR's scope.
Filed #482 and linked it.
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 · 136 lines · 83 tokens per session scan A 9be341bee647
receiving-code-review is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 2mo ago), licensed MIT. It adds 83 tokens to every session and 1,133 once invoked, about $0.0004 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
hs-release
Cut a core Hindsight release (vX.Y.Z) and open the changelog + blog PR. Use when asked to cut/start a release, bump the version, or publish a new Hindsight version.
hindsight-local
Store user preferences, learnings from tasks, and procedure outcomes. Use to remember what works and recall context before new tasks. (user).
research-repository
Build a repository that makes findings findable, reusable, and cumulative across teams. Use when the same research keeps getting redone. For synthesising one study, use affinity-diagram.
design-negotiation
Advocate for design quality, scope, and timeline with partners and leadership using evidence and shared goals. Use in the conversation itself. For the commercial vocabulary behind it, use business-design (ux-strategy).
user-persona
Build research-grounded personas with goals, frustrations, and behavioural patterns. Use when decisions need a consistent user reference. For one session's emotional snapshot use empathy-map; for motivation framing use jobs-to-be-done.
version-control-strategy
Define version control for design files, components, and libraries — branching, naming, and release. Use when file history is chaotic. For design system contribution rules, use design-system-governance (design-systems).