Improve architecture
Skill OutlineDriven/odin-claude-plugin/skills/improve-architecture
Surface deepening refactors that turn shallow modules into deep ones, raising testability and agent-navigability.From its SKILL.md
npx -y skills add OutlineDriven/odin-claude-plugin --skill improve-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
5.2 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
Iteration loop: explore for friction, present deepening candidates, grill the chosen one, update domain artifacts inline. Vocabulary is load-bearing. See references/LANGUAGE.md.
Vocabulary [LOAD-BEARING]
Use these terms exactly. Do not substitute "component," "service," "API," or "boundary." Full definitions in references/LANGUAGE.md.
- Module: anything with an interface and an implementation (function, class, package, slice). Scale-agnostic.
- Interface: every fact a caller must know: types, invariants, ordering, error modes, config, performance shape. Not just signature.
- Depth: leverage at the interface. Deep = much behaviour behind a small interface. Shallow = interface as complex as implementation.
- Seam (Feathers): 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. Role, not substance.
- Leverage: capability callers gain per unit of interface learned.
- Locality: concentration of change, bug, and knowledge at one site for maintainers.
Principles
- 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.
- Interface = test surface. Tests cross the same seam callers cross. Wanting to test past the interface = wrong shape.
- One adapter = hypothetical seam. Two adapters = real seam. No port without two real implementations (production + test).
Process
1. Explore
First tool call MUST be Explore-agent dispatch, not direct reads. The agent's brief:
- Read
CONTEXT.md(orCONTEXT-MAP.md+ per-contextCONTEXT.md) and anydocs/adr/. If absent, proceed silently. - Walk the codebase organically; classify friction:
- Concept understanding requires bouncing across many small modules → shallow cluster.
- Interface complexity matches implementation complexity → shallow module.
- Pure functions extracted only for testability while real bugs hide in callers → no locality.
- Tightly coupled modules leaking across their seams.
- For each suspect, run the deletion test before reporting.
2. Present candidates
Numbered list. Each candidate: Files, Problem (concrete friction; cite deletion test), Solution (plain-English description; no interface yet), Benefits (locality, leverage, testability deltas).
ADR conflicts: surface only when friction warrants reopening; mark explicitly: "contradicts ADR-0007: worth reopening because…".
Ask: "Which candidate to explore?" Do not propose interfaces yet.
3. Grilling loop
Once user picks, drop into adversarial interview. Walk the design tree, resolve dependencies one decision at a time, recommend an answer per question. Side effects happen inline:
- New domain term emerging? Update
CONTEXT.mdimmediately (lazy create). - User rejects with a load-bearing reason that future explorers would need? Offer ADR.
- User wants alternative interfaces for the chosen candidate? Pivot to
references/INTERFACE-DESIGN.mdfor parallel sub-agent design twice (Ousterhout).
Deepening categories (testing strategy per dependency class)
Full treatment in references/DEEPENING.md. Summary:
| Class | Deepenable? | Test strategy |
|---|---|---|
| In-process (pure / in-memory) | Always | Merge modules; test through new interface directly. No adapter. |
| Local-substitutable (PGLite, in-memory FS) | Yes if stand-in exists | Stand-in runs in tests; seam stays internal. |
| Remote but owned (microservices) | Yes via Ports & Adapters | Port at seam; HTTP/gRPC adapter prod, in-memory adapter test. |
| True external (Stripe, Twilio) | Yes | Injected port; mock adapter for tests. |
Replace, don't layer: delete shallow-module tests once interface tests exist.
Language-neutral examples
Rust: shallow validate_address + format_address + geocode_address separately called by a Shipment aggregator. Deletion test: removing format_address concentrates string-handling at one call site → was a pass-through. Deepen into address::Resolver with resolve(raw) -> Result<Resolved, AddressError>; tests cross the new interface; in-memory Geocoder adapter for tests, HTTP adapter for production.
Python: module exposes parse_invoice, apply_tax, round_total as separate top-level functions; every caller chains all three. Deepen into billing.Invoice.finalize(raw) -> Invoice. Internal seams (tax tables, rounding rules) stay private; the test surface is Invoice.finalize.
Reference docs
references/LANGUAGE.md: full vocabulary, principles, rejected framings.references/DEEPENING.md: dependency taxonomy, seam discipline, replace-don't-layer testing.references/INTERFACE-DESIGN.md: parallel sub-agent "Design It Twice" workflow when the chosen candidate's interface needs alternatives.
Forbidden: proposing interfaces in step 2 (premature commitment), bundling unrelated refactors, re-litigating ADRs without a load-bearing reason.
What ships with it: 2 files
6.6 KB alongside SKILL.md
references/
- DEEPENING.md3.5 KB
- INTERFACE-DESIGN.md3.1 KB
Gives 1 of the 12 instructions most architecture codebase skills give in ~1.1k tokens
Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07
- Ask the user which candidate to explorehere, and in 45 of 811, across 15 files
- Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
- Read any relevant architecture decision records firstin 31 of 811, across 8 files
- Use exact glossary terms in every suggestionin 30 of 811, across 10 files
- Accept dependencies instead of creating themin 24 of 811, across 5 files
- Include before and after visualisations for each candidatein 24 of 811, across 5 files
- Read the domain glossary before exploringin 24 of 811, across 6 files
- Return results instead of producing side effectsin 23 of 811, across 4 files
- Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
- Introduce seams only where things varyin 22 of 811, across 3 files
- Reduce the number of methodsin 21 of 811, across 2 files
- Design deep modules with small interfacesin 21 of 811, across 3 files
Said here and by no other author read
- use the load-bearing vocabulary exactly
- run the deletion test on suspects
- propose plain-English solutions without interfaces
- grill the chosen candidate adversarially
- recommend one answer per design question
- replace shallow-module tests with interface tests
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.