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 architecture-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/architecture-review)<a href="https://agentmods.dev/skills/owainlewis/blueprint/architecture-review"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/architecture-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/architecture-review"><img src="https://agentmods.dev/badge/skills/owainlewis/blueprint/architecture-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- 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.00054 | $0.00973 |
| Opus 5.5 | $0.00022 | $0.00389 |
| Sonnet 5.5 | $0.00011 | $0.00195 |
| Haiku 4.5 | $0.00005 | $0.00097 |
Grade A, and why
architecture-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 15d 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 — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Architecture review
Find choices that could make a technical proposal wrong, unsafe, or impossible to prove. Review the proposed behavior and tradeoffs, not the document's size or format.
Use one fresh subagent that did not write the proposal. Give the reviewer the complete context. Tell the reviewer to work directly without delegating. If you are that reviewer, review directly. Stay read-only.
If fresh subagents are unavailable, stop and report that independent review is blocked. Continue only if the user explicitly accepts a documented self-review.
Process
- Read the goal, proposal, requirements, intended architecture, repository instructions, relevant current code, tests, schemas, configuration, and linked material. Treat claims about the current system as unverified until code, tests, schemas, configuration, infrastructure, or relevant runtime evidence supports them.
- State the problem, affected user, intended outcome, success measure, scope, constraints, and main tradeoff. Report any that the proposal leaves unclear.
- Trace one real case from input to observable outcome. Include ownership, validation, state changes, side effects, response timing, failure, retry, cleanup, and what the user sees where they matter.
- Challenge the chosen design with the review focus below. Look for a simpler choice that reaches the same outcome and proof with less state, coupling, duplication, or operational work.
- Surface material open questions. Recommend an answer when evidence supports one. Do not invent questions that cannot change the design.
- Return findings, open questions, a short assessment, and one verdict. Do not rewrite the proposal, plan the work, review implementation code, or implement changes.
Review focus
- Check fit with requirements and accepted architecture. Verify current-state claims without requiring a new system to have code.
- Check ownership, boundaries, interfaces, data, compatibility, migration, rollout, and rollback.
- Trace partial failure, retry, cancellation, concurrency, startup, shutdown, and recovery where they affect the proposal.
- Check claimed scale, limited resources, latency, throughput, storage, cost, dependency failure, and operator recovery only where they can change the choice.
- Check identity, authorization, untrusted input, credentials, destructive authority, and sensitive data handling.
- Require observable acceptance criteria and proof for important rules and failure paths. Do not let implementation invent user-visible behavior, interfaces, data rules, security policy, or failure behavior.
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.
- 15d ago Changed · +1 lines 75b3a9d48b96
- 21d ago Changed · +1 lines · +1 tokens per session 7a0453afc3a7
- 1mo ago First seen · 96 lines · 53 tokens per session scan A e20d7b8f5a5d
architecture-review is a skill published in the GitHub repository owainlewis/blueprint (421 stars, last pushed 4d ago), licensed MIT. It adds 54 tokens to every session and 973 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.