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 skills add owainlewis/blueprint --skill reviewgit clone --depth 1 https://github.com/owainlewis/blueprintWrote 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/owainlewis/blueprint/review)<a href="https://agentmods.dev/skills/owainlewis/blueprint/review"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/review/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/owainlewis/blueprint/review"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- Socket pass
- Snyk warn
- NVIDIA SkillSpector pass
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.00053 | $0.01226 |
| Opus 5.5 | $0.00021 | $0.00490 |
| Sonnet 5.5 | $0.00011 | $0.00245 |
| Haiku 4.5 | $0.00005 | $0.00123 |
Grade A, and why
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 11d 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 — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
- 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.
- 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.
- 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.
- 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.
- 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.
- Run focused checks that can confirm or disprove a claim that could change a finding or verdict.
- 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
Blockedwhen that gap could hide a problem that breaks a rule and no qualified reviewer covers it. - Report findings. Return actionable findings in priority order using the format below.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 11d ago Changed · +1 lines c0c07685522d
- 17d ago Changed 822087b0d7b2
- 1mo ago First seen · 93 lines · 53 tokens per session scan A 87b186529dae
review is a skill published in the GitHub repository owainlewis/blueprint (419 stars, last pushed 7d ago), licensed MIT. It adds 53 tokens to every session and 1,226 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-reviewer
Review completed implementation batches for spec compliance and code quality. Invoke after execution batches complete, before merging, or when a review gate is reached in the workflow.
review
Adversarial senior review of the spec before any code is written. Constructs a skeptical reviewer whose authority comes from the codebase, §R research, and live best-practice — then tries to REFUTE the spec, not rubber-stamp it. Every finding cites evidence (file:line or source); unverifiable ones are flagged.…
speq-code-review
Code review tag taxonomy and findings format for the code-reviewer agent during /speq-implement. Not for general code review.
review-spd
Findings-first code review workflow for AI coding agents. Use when the user asks to review uncommitted changes, commits in a date range, or a branch compared to the main branch / PR-style diff. Focuses on bugs, regressions, correctness risks, missing tests, security/data-safety issues, and other behavior-changing…
deepen
Optional design-improvement pass for when you have spare usage to drain. Finds the shallowest modules in the code the spec touches, researches a deeper design, and proposes refactors that shrink interfaces and hide decisions — behavior held constant, tests green before and after. Proposes §I/§V/§T edits, never silent…
code-simplifier
Always-active simplicity rules: no speculative abstractions, one job per function, max 30 lines, flat over nested with early returns, descriptive names, comments explain why.