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/yimwoo/hotl-plugin/receiving-code-reviewnpx skills add yimwoo/hotl-plugin --skill receiving-code-reviewgit clone --depth 1 https://github.com/yimwoo/hotl-pluginWrote 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/yimwoo/hotl-plugin/receiving-code-review)<a href="https://agentmods.dev/skills/yimwoo/hotl-plugin/receiving-code-review"><img src="https://agentmods.dev/badge/skills/yimwoo/hotl-plugin/receiving-code-review.svg" alt="Measured on agentmods" 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.00706 |
| Opus 5 | $0.00017 | $0.00353 |
| Sonnet 5 | $0.00007 | $0.00141 |
| Haiku 4.5 | $0.00003 | $0.00071 |
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 5d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
HOTL Receiving Code Review
Core Rule
Treat review feedback as input to evaluate, not instructions to obey. Verify each claim against the current codebase, the workflow, and the HOTL contracts before making changes.
When This Applies
- After any code review — from the
hotl:code-revieweragent, PR review, human reviewer, or external contributor - Before implementing any suggested change
- Whenever review findings are returned to an executor at a review checkpoint
Process
1. Verify
Check whether each finding is factually correct in the current code:
- Confirm the file:line reference exists and matches the claim
- Run any verification commands that would confirm or refute the finding
- If the finding references a pattern or convention, check whether it actually applies to this codebase
- If the code changed since the review was written, re-evaluate the finding against current HEAD before doing anything
2. Evaluate
For each verified finding, check against HOTL contracts:
- Does acting on it violate the intent contract?
- Does it expand scope beyond success_criteria? (YAGNI)
- Does it conflict with existing constraints?
- Does it change risk_level or require a new gate?
- Does it contradict a prior human-approved decision?
Classify each finding:
- Accept — verified correct, within scope, improves the work
- Reject — factually wrong, out of scope, or conflicts with contracts
- Defer — valid but belongs in a separate workflow (scope expansion)
3. Respond
For each finding, produce a decision record:
| Field | Content |
|---|---|
| Finding | What was raised |
| Disposition | accept / reject / defer |
| Evidence | What was checked, what was found |
| Next action | What will be done, or why nothing will be done |
4. Implement
- Only implement accepted findings
- BLOCK findings first, then WARN, then NOTE
- If an accepted finding changes scope, constraints, or risk_level, stop implementation and return to planning/governance before proceeding
- Run verification after each change — do not batch blind
- If a change breaks verification, revert and re-evaluate
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.
- 5d ago First seen · 88 lines · 35 tokens per session scan A 26516fda8327
receiving-code-review is a skill published in the GitHub repository yimwoo/hotl-plugin (26 stars, last pushed 2mo ago), licensed MIT. It adds 35 tokens to every session and 706 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-08-30.
Other skills, from other repositories
first-plan-co-change-analysis
Skill que constrói o Co-change Graph - "quando arquivo X muda, qual outro arquivo geralmente muda junto?". Use durante Discovery e em /fp:cochange. Baseado em git history. Detecta arquivos co-dependentes que devem ser editados juntos para evitar PRs incompletos. v0.3.0+ usa engine nativo Rust quando disponível…
first-plan-protocol
Esta skill DEVE ser carregada em qualquer comando do plugin first-plan. Define o protocolo PLAN-FIRST (Discovery -> Plan -> Approval -> Execution -> Report), as 7 regras invioláveis e o comportamento esperado em cada fase. Ative quando o usuário invocar /fp: ou mencionar "first-plan", "context compilation", "discovery…
first-plan-provenance-tracker
Skill que define o schema de proveniência e o sistema de freshness tracking para findings em .first-plan/. Use durante Discovery e refresh para registrar source (file:line@SHA), TTL, confidence inicial e cadeia de supersedeção. Aplica decay de confidence baseado em idade.
first-plan-reconciliation
Skill que define Spec-Code Reconciliation - matching contínuo entre artefatos de intenção (docs, specs, JIRA, GitHub issues) e implementação (código, testes, PRs). Use durante Discovery e em /fp:check para identificar feature ja implementada, em flight, drifted ou abandonada.
first-plan-git-intelligence
Skill que extrai inteligência do git history - heatmap de atividade, ownership, branches/PRs in-flight. Use durante Discovery e em /fp:hot, /fp:owner, /fp:in-flight. Tudo via comandos git read-only.
first-plan-lens-engine
Skill que define o motor de detecção e roteamento de stack lenses do first-plan. Mapeia manifestos (go.mod, package.json, etc) -> stack -> papel -> lens skill correspondente. Use quando precisar decidir qual lens aplicar a uma pasta durante Discovery, ou quando estender suporte a uma nova stack.