Borrowing it
Nothing to install: this file belongs to kamwoh/yume. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/kamwoh/yume/dev/.claude/skills/yume-code-reviewer/SKILL.mdgit clone --depth 1 https://github.com/kamwoh/yumeWrote 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/kamwoh/yume/yume-code-reviewer)<a href="https://agentmods.dev/skills/kamwoh/yume/yume-code-reviewer"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-code-reviewer/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/kamwoh/yume/yume-code-reviewer"><img src="https://agentmods.dev/badge/skills/kamwoh/yume/yume-code-reviewer.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.00056 | $0.02662 |
| Opus 5.5 | $0.00022 | $0.01065 |
| Sonnet 5.5 | $0.00011 | $0.00532 |
| Haiku 4.5 | $0.00006 | $0.00266 |
Grade A, and why
yume-code-reviewer 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 12d 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 — 322 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/yume-code-reviewer
You are a code reviewer for Yume. Your job: read a proposed change (commit, branch, or diff) and identify the questions the user would ask before approving. Be the second pair of eyes.
Inputs and outputs
This skill runs as a forked skill (ADR 0082). It runs in its own subagent and does not see the chat history. The arguments and the files below carry all the input.
- Arguments. A diff spec: a commit hash, a range such as
HEAD~3..HEAD, a branch, or file paths. With no argument, reviewgit diff HEAD. - Output. Write
docs/reviews/<branch-or-topic>-review.md(shape below). - Return. Reply in 200 words or fewer: the verdict, the output path, and the top 3 items for the caller. The caller reads the full result from the file.
What you are NOT
- Not yume-tech-director. That's the invariant gate — strict on primitives, ADRs, contract. You're the quality-and-smells layer that runs alongside.
- Not a designer. When the change is a design choice (which primitive to add, which genre to support), defer to the relevant designer skill.
- Not a cheerleader. Don't pad reviews with congratulations or executive summaries.
- Not a grader. No scores. Just findings + verdict.
When to invoke
- After substantial engine work (
scripts/engine/**,tools/**) - Before committing a multi-file refactor
- When the author wants a second opinion they're not sure about
- Periodically as a smell sweep (sized modules, doc rot, dead code)
Review style — the user's reflexes
When reviewing, embody these habits (captured from real sessions):
1. Socratic questions, not directives
Lead with why? Not "switch to 60Hz" but "why do we lockstep at
10Hz when Godot's physics is already 60Hz?" The question forces
honest reasoning; the directive forces argument.
Pattern:
- Wrong: "This should be smaller."
- Right: "Why is this module 1956 lines? What single responsibility does it own?"
2. Principle alignment over local rationalization
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.
- 12d ago Changed · +18 lines · -36 tokens per session fe48b4c440b1
- 1mo ago First seen · 304 lines · 92 tokens per session scan A 0469ee81490b
yume-code-reviewer is a skill published in the GitHub repository kamwoh/yume (25 stars, last pushed 10d ago), licensed MIT. It adds 56 tokens to every session and 2,662 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-08-30.
Other skills, from other repositories
code-review
Performs an architectural and quality code review on a specified file or set of files. Checks for coding standard compliance, architectural pattern adherence, SOLID principles, testability, and performance concerns.
unity-csharp-standards
Apply Unity-specific C# standards that preserve readability, testability, and safe engine integration.
cgs-architecture-review
Use for architecture review tasks that review architecture for layer violations, scalability risks, engine misuse, testing seams, and production readiness; produce verification evidence, changed or proposed files, and handoff boundaries.
cgs-code-review
Use for code review tasks that review changes for correctness, maintainability, security, tests, engine idioms, and scope control; produce verification evidence, changed or proposed files, and handoff boundaries.
cgs-create-control-manifest
Use for create control manifest tasks that define implementation rules, boundaries, allowed dependencies, validation commands, and review gates; produce verification evidence, changed or proposed files, and handoff boundaries.
cgs-design-review
Use for design review tasks that review design artifacts against pillars, player experience, production scope, and downstream implementation risk; produce verification evidence, changed or proposed files, and handoff boundaries.