Review

Review code changes for correctness and quality before merging. Use after implementing a meaningful chunk or feature, between plan tasks, or before opening a PR — to catch issues while they're cheap.From its SKILL.md

Install

npx -y skills add vasu-devs/Forge --skill review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
runs commandsInstructs the agent to run 3 commands, including `run the repo's own lint / typecheck / test commands` and 2 more.

SKILL.md

3.7 KB, 814 tokens by cl100k_base, as published. Nobody here has run it

██████╗ ███████╗██╗   ██╗██╗███████╗██╗    ██╗
██╔══██╗██╔════╝██║   ██║██║██╔════╝██║    ██║
██████╔╝█████╗  ██║   ██║██║█████╗  ██║ █╗ ██║
██╔══██╗██╔══╝  ╚██╗ ██╔╝██║██╔══╝  ██║███╗██║
██║  ██║███████╗ ╚████╔╝ ██║███████╗╚███╔███╔╝
╚═╝  ╚═╝╚══════╝  ╚═══╝  ╚═╝╚══════╝ ╚══╝╚══╝

Review on two axes, by a fresh set of eyes

Author-bias elimination

The reviewer must not be the author. A self-review shares the exact blind spots that produced the bug. Dispatch a fresh subagent with crafted context — the diff plus the originating spec/issue — not your session history. The reviewer should reach its verdict without your reasoning leaking in. If you can't spawn a subagent, simulate the reset: review strictly from the diff + spec, deliberately setting aside your implementation reasoning.

Independent axes

Run these reviews so they don't pollute each other (ideally as parallel subagents that never see each other's findings), then present them side by side without merging or reranking:

Spec — does the change do what was actually asked? Right behavior, all the acceptance criteria, nothing missing or scope-crept.
Correctness — is the code actually right, independent of the spec? Edge cases, boundary/off-by-one, error and failure paths, null/empty, concurrency and races, resource leaks, injection. (Code can satisfy the spec and follow every convention and still be wrong — this axis is the "correctness" the skill's name promises.)
Standards — does it follow this repo's conventions and quality bar? Naming, structure, tests, idioms.

Keep them separate because a change routinely passes one and fails another. A merged review lets one mask the others.

First run the repo's own lint / typecheck / test commands and confirm they're green; then the Standards reviewer can skip what tooling already enforces (formatting, lint) and spend its attention on judgment calls. Never skip a check you didn't actually run.

Adversarial framing

Assume there are problems and go find them. "I found zero issues" almost always means you weren't looking hard enough. A clean verdict is only valid if you inspected every changed hunk and can name the single riskiest line you considered and why it's actually safe.

Severity tiers → action

Critical — security hole, data loss, crash, incorrect output, or a regression. Block; fix before anything else.
Important — missing test for new logic, an unhandled error path, or a performance cliff. Fix before proceeding.
Minor — style not enforced by tooling, naming. Note them; don't gate.

Receiving the findings (when feedback comes to you)

Evaluate each point technically. Don't perform agreement ("Great catch!") — just assess and act.
If a finding is wrong, push back with reasoning rather than complying blindly.
If asked to "implement this properly/fully," grep for actual usage first — don't build flexibility nobody needs (forge:principles #2).

Exit

Fix Critical/Important, then forge:verify with evidence, then forge:ship.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most review quality skills give in 814 tokens

Counted across 1,273 of the 2,403 authors here whose files we hold, read 2026-09-06

Ask one question at a timein 63 of 1273, across 62 files
Provide a recommended answer for each questionin 47 of 1273, across 45 files
Rank findings by severityin 44 of 1273
Use parameterized queries for database accessin 38 of 1273, across 20 files
Validate all user input with schemasin 33 of 1273, across 15 files
Store secrets in environment variablesin 32 of 1273, across 14 files
Explore the codebase to answer questionsin 31 of 1273, across 29 files
Store tokens in httpOnly cookiesin 30 of 1273, across 12 files
Implement rate limiting on API endpointsin 30 of 1273, across 12 files
Sanitize user-provided HTMLin 29 of 1273, across 11 files
Return generic error messages to usersin 28 of 1273, across 10 files
Cite file and line for every findingin 28 of 1273, across 25 files

Said here and by no other author read

Review code against spec, correctness, and standards
Inspect every changed hunk
Identify the single riskiest line
Evaluate findings technically without agreement
Push back on incorrect findings
Verify fixes with evidence

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.