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 MartinPLarsen/claude-architecture-skills --skill architecture-auditgit clone --depth 1 https://github.com/MartinPLarsen/claude-architecture-skillsWrote 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/martinplarsen/claude-architecture-skills/architecture-audit)<a href="https://agentmods.dev/skills/martinplarsen/claude-architecture-skills/architecture-audit"><img src="https://agentmods.dev/badge/skills/martinplarsen/claude-architecture-skills/architecture-audit/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/martinplarsen/claude-architecture-skills/architecture-audit"><img src="https://agentmods.dev/badge/skills/martinplarsen/claude-architecture-skills/architecture-audit.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00244 | $0.01840 |
| Opus 5.5 | $0.00098 | $0.00736 |
| Sonnet 5.5 | $0.00049 | $0.00368 |
| Haiku 4.5 | $0.00024 | $0.00184 |
Grade A, and why
architecture-audit 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 2mo 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 — 68 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Repo Architecture Audit
What this does and why it works
Produce one self-contained Markdown document that explains an entire codebase start-to-finish, with Mermaid flowcharts as the primary medium, grounded in path:line evidence, and verified against the real code before it is handed over. The output is a decision aid: someone reads it and knows how the system connects and where to edit things, without re-reading the repo.
The method is subagent-driven for a reason. A whole-repo audit is too much for one context to hold well, and one reader is blind to the seams between subsystems. Fanning out one reader per subsystem in parallel covers more ground, keeps each reader's context focused, and surfaces contradictions between subsystems that a single pass misses. A dedicated verify pass then catches the failure mode that matters most here: a confident synthesis claiming something the code does not actually do (planned work shown as shipped, wrong gate order, invented field mappings).
You are the orchestrator. Scout first so the fan-out is informed, then run the phases below. Default to the Workflow tool (this skill is explicit opt-in for it). If Workflow is unavailable, fall back to parallel Agent calls; if subagents are unavailable entirely, run the phases inline and sequentially, which is slower and lower-coverage but still works.
Phase 0 — Scout inline (do not fan out blind)
Spend a few cheap tool calls building the work-list before spawning anything. You cannot pick good subsystem boundaries until you have seen the shape of the repo.
- Map the tree and file sizes, excluding vendored/generated noise:
node_modules,.git,dist/build/out,vendor,.next,target, lockfiles, and anyworktrees/mirror copies (read each file once, from the canonical tree only). - Read the entry points and the docs that explain intent:
README,package.json/pyproject/go.mod/Cargo.toml/etc., anyCLAUDE.md/ARCHITECTURE/docs/, migrations, and config. - Identify the subsystems — the natural seams along which to split readers. These are repo-specific; derive them, do not assume. Common seams:
- agents / services / workers (the active units of work)
- executable pipeline or business-logic code (what actually runs, vs specs)
- data layer (schema, migrations, state model, storage)
- the domain's core transform (the thing this system exists to do: image/media generation, schema mapping, ETL, model inference, payment flow)
- external integrations / publishing (APIs, third-party services, webhooks)
- frontend / presentation / rendering
- orchestration / control plane / scheduling / cost or rate guards
- governance / rules / config / requirements contracts
- Decide reader count from repo size: small repo → 4-5 readers, medium → 6-8, large/monorepo → 9-12 (and consider one reader per package). Note language and conventions (so output language matches the repo).
What ships with it
2 files 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.
- 2mo ago First seen · 68 lines · 0 tokens per session scan A d45ad2c72a0a
architecture-audit is a skill published in the GitHub repository MartinPLarsen/claude-architecture-skills (3 stars, last pushed 3mo ago), licensed MIT. It adds 244 tokens to every session and 1,840 once invoked, about $0.0010 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-31.
Other skills, from other repositories
autoreview
Structured code review through the shared OpenClaw agent-skills installation.
agent-teams-simplify-and-harden
Implementation + audit loop using parallel agent teams with structured simplify, harden, and document passes. Spawns implementation agents to do the work, then audit agents to find complexity, security gaps, and spec deviations, then loops until code compiles cleanly, all tests pass, and auditors find zero issues or…
omh-code-review
This is an OMH code-review workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).
revdiff-plan
Review the last Codex assistant message (plan, analysis, or proposal) with inline annotations in a TUI overlay. Extracts the most recent response from Codex rollout files and opens it in revdiff for review and annotation. Activates on "revdiff-plan", "review plan with revdiff", "annotate plan", "review last response"…
explore-unknowns
Guide the user through a quadrant walk that maps the unknowns of a task — open by listing the known knowns, then work through known unknowns, unknown knowns, and unknown unknowns one stage at a time, ending with a complete four-quadrant map in the user's hands. Use when a request is ambiguous or underspecified, the…
re0-merge
Review and land an external contribution the way this suite does: gate it against the thesis, land it with the author's credit intact, complete a new skill rather than merging it raw, then approve, credit, and explain before closing. Use when reviewing a pull request, as any collaborator or maintainer, not only the…