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.svg" alt="Measured on agentmods" height="20"></a>- Socket pass
- Snyk pass
- 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.01196 |
| Opus 5 | $0.00026 | $0.00598 |
| Sonnet 5 | $0.00011 | $0.00239 |
| Haiku 4.5 | $0.00005 | $0.00120 |
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 8d 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 — 93 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. 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 design, 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 design 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,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 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.
- 8d ago First seen · 93 lines · 53 tokens per session scan A 87b186529dae
review is a skill published in the GitHub repository owainlewis/blueprint (383 stars, last pushed yesterday), licensed MIT. It adds 53 tokens to every session and 1,196 once invoked, about $0.0003 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
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.…
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-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…
speq-code-review
Code review tag taxonomy and findings output format — guardrail violations, dead code, test quality, bad comments, optimizations, YAGNI/over-engineering, error handling, and design depth. Triggered by code-reviewer.
review
Review in three modes — code (diff vs standards/spec), design (NOTES + tech-spec before planning), drift (implementation vs tech-spec before ship). Pick mode from Flow Conductor phase or user intent; do not mix artifact types.