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.00053 | $0.00944 |
| Opus 5 | $0.00026 | $0.00472 |
| Sonnet 5 | $0.00011 | $0.00189 |
| Haiku 4.5 | $0.00005 | $0.00094 |
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 10d 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 — 96 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, 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 the current system, 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 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.
- 10d ago First seen · 96 lines · 53 tokens per session scan A e20d7b8f5a5d
architecture-review is a skill published in the GitHub repository owainlewis/blueprint (388 stars, last pushed 3d ago), licensed MIT. It adds 53 tokens to every session and 944 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.
speckit-resolve-pr
Address actionable review feedback on a pull request, push the fixes, and resolve review threads. Reads the PR comments, updates the code, runs project verification, replies to review threads, and reports what changed.