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 saski/arnesto --skill improve-codebase-architecturegit clone --depth 1 https://github.com/saski/arnestoWrote 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/saski/arnesto/improve-codebase-architecture)<a href="https://agentmods.dev/skills/saski/arnesto/improve-codebase-architecture"><img src="https://agentmods.dev/badge/skills/saski/arnesto/improve-codebase-architecture/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/saski/arnesto/improve-codebase-architecture"><img src="https://agentmods.dev/badge/skills/saski/arnesto/improve-codebase-architecture.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.00068 | $0.01150 |
| Opus 5.5 | $0.00027 | $0.00460 |
| Sonnet 5.5 | $0.00014 | $0.00230 |
| Haiku 4.5 | $0.00007 | $0.00115 |
Grade A, and why
improve-codebase-architecture 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 1mo 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.
This is a copy
70% identical to improve-codebase-architecture — 78 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Improve Codebase Architecture
Surface architectural friction and propose deepening opportunities — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
Glossary
Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary." Full definitions in LANGUAGE.md.
- Module — anything with an interface and an implementation (function, class, package, slice).
- Interface — everything a caller must know to use the module: types, invariants, error modes, ordering, config. Not just the type signature.
- Implementation — the code inside.
- Depth — leverage at the interface: a lot of behaviour behind a small interface. Deep = high leverage. Shallow = interface nearly as complex as the implementation.
- Seam — where an interface lives; a place behaviour can be altered without editing in place. (Use this, not "boundary.")
- Adapter — a concrete thing satisfying an interface at a seam.
- Leverage — what callers get from depth.
- Locality — what maintainers get from depth: change, bugs, knowledge concentrated in one place.
Key principles (see LANGUAGE.md for the full list):
- Deletion test: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.
- The interface is the test surface.
- One adapter = hypothetical seam. Two adapters = real seam.
This skill is informed by the project's domain model. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate.
Process
1. Explore
Read the project's domain glossary and any ADRs in the area you're touching first.
Then use the Agent tool with subagent_type=Explore to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
- Where does understanding one concept require bouncing between many small modules?
- Where are modules shallow — interface nearly as complex as the implementation?
- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no locality)?
- Where do tightly-coupled modules leak across their seams?
- Which parts of the codebase are untested, or hard to test through their current interface?
What ships with it
3 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.
- 1mo ago First seen · 72 lines · 68 tokens per session scan A 9e9b617b1c70
improve-codebase-architecture is a skill published in the GitHub repository saski/arnesto (6 stars, last pushed 7d ago), licensed Unlicense. It adds 68 tokens to every session and 1,150 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 70% identical to improve-codebase-architecture, differing in 78 lines, and is treated as a copy.
Other skills, from other repositories
readonly-review
Run a no-network read-only review practice with two explorer steps and one synthesis step.
repo-contracts-and-boundaries
Use when turning architecture, layering, ownership, dependency direction, schemas, structural metrics, quality thresholds, baselines, allowlists, or generated quality snapshots into repository checks.
address-pr-comments
Work through the review comments on a pull request: check each point against the code, make the changes that are right, answer the ones that are not, and hold every reply for approval before it is posted.
code-refiner
Deep code simplification and refactoring preserving behavior across Python, Go, TypeScript, Rust. Targets complexity, anti-patterns, readability debt. Triggers on: "simplify this code", "refactor for clarity", "reduce complexity", "make this more readable", "tech debt cleanup", "too much nesting". NOT for deepening…
package-optimizer
Evaluate one existing package or bounded package family from recorded evaluator evidence and a capability profile, then propose retain, simplify, strengthen, retire, or inconclusive without editing. Use when optimizing a skill, agent, hook, rule, command, utility, or preset; evaluating whether package detail is…
review-skill
Review a proposed Agent Skill for structural validity and content quality before publishing. Runs the skill-validator CLI to check for structural issues, scores the skill with an LLM judge, and interprets results to advise authors on what to address. Use when a user wants to review, validate, or quality-check an Agent…