New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Independent Implementation Review

by owainlewis in owainlewis/blueprint

Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge.

MITAuto-check passedDevelopment

Install Independent Implementation Review

skills CLI
$ npx skills add owainlewis/blueprint --skill review -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install owainlewis/blueprint review --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/owainlewis/blueprint.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/review .claude/skills/review && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review
GitHub stars
412
Token cost
~1.5k tokens
SKILL.md length
775 words
Files
1
Skills in repo
11
Repo updated
First seen
Licence
MIT

At a glance

Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge.

  • Works in 8 steps: Set the frame. Give the reviewer the… → Take the broad view. Read the change… → Review the main behavior. Start with the… → …
  • Getting a second opinion on a finished change before merge
  • SKILL.md covers Scope, Standard, Review order and Code review findings, plus 2 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

The skill hands an implemented change to a fresh subagent that had no part in writing it. The reviewer stays read-only: it edits no files and posts no comments. The target can be a file, diff, branch, commit or GitHub pull request. When none is named, the whole local change set is reviewed, meaning branch commits against the default branch plus staged, unstaged and untracked files. Proposals that are not built yet go to the separate /architecture-review skill instead.

The reviewer works in a set order. It confirms the change matches its spec or ticket, studies the main behavior and failure paths, reads each human-written changed line in context, and checks that the tests and other evidence actually prove the change. The standard is to approve only when the change meets its source and no known defect or unhandled risk remains, citing technical evidence or repository conventions rather than taste. The verdict counts as independent agent evidence, not as a GitHub approval or a substitute for human review.

When your agent uses it

  • Getting a second opinion on a finished change before merge
  • Reviewing a pull request or diff without letting the reviewer edit it
  • Checking a branch for security, regression and missing-test problems

Example prompts

  • “Review the changes on this branch before I open a pull request.”
  • “Review the open pull request for the billing refactor and tell me if it is safe to merge.”
  • “Do a security-focused second-opinion review of my staged changes.”

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. Set the frame. Give the reviewer the task, acceptance criteria and invariant IDs from its task or spec, repository rules, complete diff or…
  2. Take the broad view. Read the change summary and the relevant spec or ticket. Confirm that the change belongs in the system, matches the…
  3. Review the main behavior. Start with the files and flows that deliver the outcome. Check behavior, failures, security boundaries…
  4. Review every human-written changed line in context. Read enough surrounding code to judge correctness, regressions, complexity, names…
  5. Review the proof. Check that tests
  6. Run focused checks that can confirm or disprove a claim that could change a finding or verdict.
  7. Check specialist coverage. Identify security, privacy, concurrency, accessibility, internationalization, or domain-specific work. Mark a…
  8. Report findings. Return actionable findings in priority order using the format below.

What it can do on your machine

Read from SKILL.md and the folder at commit 1d74745. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Independent Implementation Review loads about 1.5k tokens when it runs. Until then it costs about 59 tokens; SKILL.md has 775 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~59
When it runs · the whole SKILL.md, loaded when a task matches
~1.5k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from owainlewis/blueprint at commit 1d74745, republished under its MIT licence (© owainlewis). 775 words, ~1,480 tokens.

Download SKILL.mdSave it as .claude/skills/review/SKILL.md (or your agent's skills folder).
name
review
description
Uses a fresh agent to review an implementation change without editing it. Checks behavior, security, regressions, complexity, tests, docs, and missing proof. Use for code, PR, diff, security, second-opinion, or pre-merge reviews.
user-invocable
true
argument-hint
[diff, branch, commit, PR, or file path]

Review

Find defects that can change the result or make the change unsafe. Do not turn personal taste into a finding.

Use a fresh subagent that did not implement the change. Tell it to review directly without delegating. If you are that reviewer, review directly. Stay read-only. Do not edit files or post comments.

Scope

Review the implementation target named by the user. It may be a file, diff, branch, commit, pull request, or other code change on GitHub. Use /architecture-review for a technical proposal that has not been implemented.

If the user does not name a target, review the repository's complete local change set. Include commits on the current branch relative to the default branch, staged changes, unstaged changes, and untracked files.

Use the repository and the immediate surrounding code as context. If there are no local changes, say so. Do not substitute a whole-repository audit.

Standard

Approve only when:

  • The change matches its source and behaves as required.
  • No known defect or unhandled risk could break the source or repository rules for security, data loss, compatibility, or operations.

Do not demand perfection or block on personal taste. Cite technical evidence or repository conventions.

The verdict is independent agent evidence. It is not GitHub approval or a replacement for human review.

Review order

  1. Set the frame. Give the reviewer the task, acceptance criteria and invariant IDs from its task or spec, repository rules, complete diff or pull request, and test evidence. Name the user or developer affected by the change.
  2. Take the broad view. Read the change summary and the relevant spec or ticket. Confirm that the change belongs in the system, matches the intended behavior, and delivers one reviewable outcome. Report a mismatch before reviewing details.
  3. Review the main behavior. Start with the files and flows that deliver the outcome. Check behavior, failures, security boundaries, interfaces, compatibility, migrations, concurrency, and operations.
  4. Review every human-written changed line in context. Read enough surrounding code to judge correctness, regressions, complexity, names, comments, style, and docs. For generated files or large data, inspect the source and spot-check the output. Keep findings within the change's scope.
  5. Review the proof. Check that tests:
    • Cover the changed behavior and affected failure paths.
    • Prove every cited AC-n, REQ-n, INV-n, or task criterion.
    • Assert behavior a user or caller can observe, or a documented internal contract.
    • Would fail under a broken implementation.
    • Do not copy implementation logic or hide the scenario in setup.
  6. Run focused checks that can confirm or disprove a claim that could change a finding or verdict.
  7. Check specialist coverage. Identify security, privacy, concurrency, accessibility, internationalization, or domain-specific work. Mark a risk unverified when the reviewer lacks the evidence or skill to judge it. Use Blocked when that gap could hide a problem that breaks a rule and no qualified reviewer covers it.
  8. Report findings. Return actionable findings in priority order using the format below.
Show full SKILL.md (286 more words)Show less

Code review findings

Report only real bugs, customer-impacting problems, and proven simplifications introduced or exposed by the change. Check security, logic, behavior, reliability, compatibility, regressions, and affected failure paths.

Inspect enough surrounding code to prove each finding. A simplification must deliver the same result and proof with less state, indirection, duplication, or operational work. Report it only as Could fix.

Use this format for every finding:

text
Priority: Must fix / Should fix / Could fix
Confidence: 0 to 5
What I found: Describe the technical problem.
Why it matters: Explain the impact on customers, callers, or the service.
Trigger and effect: State the exact condition and what the customer or service experiences.
Where: File and line.
Suggested fix: Give a short, practical direction.

Priority means:

  • Must fix: Unsafe to merge. The change can cause a security failure, data loss, broken required behavior, or a serious service regression.
  • Should fix: A real defect or reliability risk that should be corrected before merge.
  • Could fix: A proven, limited problem or simplification that does not need to block merge. Do not use this for style preferences.

Confidence means:

  • 5: Confirmed by reproduction, test, or direct code evidence.
  • 4: Strong evidence with no credible alternative explanation.
  • 3: Probable, but some runtime evidence is unavailable.
  • 0 to 2: Do not report. Investigate further or mark the area unverified.

Use plain words. State what breaks, when it breaks, and who it affects. Omit style preferences, theoretical concerns, and problems outside the change.

Verdict

If fresh subagents are unavailable, stop and report that independent review is blocked unless the user explicitly accepts a documented self-review.

If there are no findings, say so. End with Approve, Request changes, or Blocked, then state what remains unverified. A Must fix or Should fix finding requires Request changes. Could fix findings do not prevent Approve.

Boundaries

  • Keep findings within the change, but inspect enough surrounding code to judge each changed line and its system effect.
  • Do not turn preferences into findings. Use technical evidence and repository conventions.
  • Do not approve solely because checks pass.

© owainlewis, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/review of owainlewis/blueprint.

Open the folder on GitHubat commit 1d74745

Compare with similar skills

Independent Implementation Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Independent Implementation Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Independent Implementation Review this skillowainlewis/blueprint412—~1.5kAutomated safety check: PassMIT
GitHub Review Iterationprisma/orm48k—~2.2kAutomated safety check: PassApache-2.0
Cherry Studio PR ReviewCherryHQ/cherry-studio52k—~3.9kAutomated safety check: PassAGPL-3.0
PR Reviewjaemk/self_update961—~1.5kAutomated safety check: NotesMIT
PR Reviewjaemk/cached2.1k—~2.5kAutomated safety check: NotesMIT
Pull Request Code Review Orchestratoropeninterpreter/openinterpreter69k2 repos~163Automated safety check: PassApache-2.0

Similar skills

  • GitHub Review Iteration

    prisma/orm

    Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed

  • Cherry Studio PR Review

    CherryHQ/cherry-studio

    Reviews Cherry Studio branches, pull requests, commits, files and docs against the project's own architecture, naming, API-boundary and UI rules, report-only by default.

    52k GitHub stars~3.9k tokensUpdated today
    DevelopmentAuto-check passed

  • PR Review

    jaemk/self_update

    Targeted, read-only review of a PR or checked-out branch. An agent skill from jaemk/self_update.

    961 GitHub stars~1.5k tokensUpdated 1 mo ago
    DevelopmentAuto-check: notes

  • PR Review

    jaemk/cached

    Targeted, read-only review of a PR or checked-out branch. An agent skill from jaemk/cached.

    2.1k GitHub stars~2.5k tokensUpdated 8 days ago
    DevelopmentAuto-check: notes

  • .NET MAUI Code Review

    dotnet/efcore

    Official

    Deep code-only review of a pull request or candidate patch for correctness, safety and .NET MAUI conventions, judging the code before reading the PR description.

    15k GitHub stars~2.1k tokensUpdated today
    DevelopmentAuto-check passed

More from owainlewis/blueprint

All 11 skills in this repo

  • Markdown PRD to HTML Renderer

    owainlewis/blueprint

    Converts a complete Markdown PRD or technical design into one verified, static HTML reading page without changing what it says.

    412 GitHub stars~1.3k tokensUpdated 3 days ago
    Auto-check passed

  • Codex Issue Coordinator

    owainlewis/blueprint

    Lets one Codex thread run a batch of GitHub issues through separate worker threads, each with its own worktree, branch, tested pull request and gated merge.

    412 GitHub stars~2.6k tokensUpdated 3 days ago
    Auto-check passed

  • Vertical-Slice Task Planner

    owainlewis/blueprint

    Breaks a reviewed spec into ordered, vertical-slice tasks that each fit one agent run and one pull request, grouped into milestones when useful.

    412 GitHub stars~1.5k tokensUpdated 3 days ago
    Auto-check passed

  • Architecture

    owainlewis/blueprint

    Designs and maintains root ARCHITECTURE.md for the intended system, including its data model and shared technical rules.

    412 GitHub stars~1.3k tokensUpdated 3 days ago
    Auto-check passed

  • Architecture Review

    owainlewis/blueprint

    Reviews a technical proposal before implementation through an independent subagent, returning findings, open questions and a verdict without rewriting it.

    412 GitHub stars~1.2k tokensUpdated 3 days ago
    Auto-check passed

  • Product Requirements Document

    owainlewis/blueprint

    Creates or updates a long-running REQUIREMENTS.md that defines a system's users, outcomes, capabilities, business rules, scope and acceptance conditions.

    412 GitHub stars~766 tokensUpdated 3 days ago
    Auto-check passed

Works with

Categories

Questions about Independent Implementation Review

What does Independent Implementation Review do?

Has a separate agent review a code change without editing it, checking behavior, security, regressions, complexity, tests and docs before merge. The skill hands an implemented change to a fresh subagent that had no part in writing it. The reviewer stays read-only: it edits no files and posts no comments.

When should I use Independent Implementation Review?

Independent Implementation Review fits situations like: getting a second opinion on a finished change before merge; reviewing a pull request or diff without letting the reviewer edit it; checking a branch for security, regression and missing-test problems.

How do I install Independent Implementation Review in Claude Code?

Run `npx skills add owainlewis/blueprint --skill review -a claude-code`. Or copy the skill folder (skills/review in owainlewis/blueprint) into .claude/skills/review in your project. Claude Code loads it when a task matches its description.

How do I install Independent Implementation Review in Codex?

Run `npx skills add owainlewis/blueprint --skill review -a codex`. Or copy the skill folder (skills/review in owainlewis/blueprint) into .agents/skills/review in your project. Codex loads it when a task matches its description.

Can I use Independent Implementation Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add owainlewis/blueprint --skill review -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review, .gemini/skills/review, .github/skills/review and .opencode/skills/review in your project.

What does Independent Implementation Review need to run?

SKILL.md names no scripts, command-line tools or credentials: Independent Implementation Review is instructions for the agent only.

Does Independent Implementation Review access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Independent Implementation Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Independent Implementation Review use?

Independent Implementation Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Independent Implementation Review use?

About 1.5k tokens (SKILL.md is roughly 5.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Independent Implementation Review?

Skills that share tags, products or a category with Independent Implementation Review: GitHub Review Iteration (prisma/orm, 48k stars), Cherry Studio PR Review (CherryHQ/cherry-studio, 52k stars), PR Review (jaemk/self_update, 961 stars) and PR Review (jaemk/cached, 2.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Independent Implementation Review?

owainlewis (a GitHub user) maintains it in owainlewis/blueprint, which has 412 GitHub stars. The repository holds 11 skills in this directory. The repository was last updated on October 6, 2026.

Source: owainlewis/blueprint on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.