Codebase improve

Skill neumie/almanac/skills/other/codebase-improve

Personal agent toolkit — curated skills for LLM coding agents

Install

npx -y skills add neumie/almanac --skill codebase-improve

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when finding architectural friction in a codebase. Surfaces shallow modules, proposes refactors for testability/AI-navigability, grills the design. Uses CONTEXT.md + ADRs.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

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.

Follow the codebase-design skill for design vocabulary and principles. Follow the domain-model skill when maintaining CONTEXT.md or ADRs.

Process

1. Explore

Scope the scan before exploring. Deepening pays off when future changes land in that area, so avoid speculative whole-repo review:

If the user names a module, subsystem, or pain point, focus there.
Otherwise inspect a useful stretch of git log --oneline for recurring files and areas. Start with those hot spots; widen only when history is scattered.

These commands run automatically when the skill loads — output replaces each line below:

CONTEXT.md: !cat CONTEXT.md 2>/dev/null || true
ADR list: !ls docs/adr/ 2>/dev/null || true

If CONTEXT.md content is present above, use that vocabulary throughout. If ADR list showed files, read the relevant ones before exploring.

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?

Apply the deletion test to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.

2. Present candidates as an HTML report

Write a self-contained HTML file to the OS temp directory so nothing lands in the repo. Resolve the temp dir from $TMPDIR, falling back to /tmp (or %TEMP% on Windows), and write to <tmpdir>/architecture-review-<timestamp>.html so each run gets a fresh file. Open it for the user — xdg-open <path> on Linux, open <path> on macOS, start <path> on Windows — and tell them the absolute path.

The report uses Tailwind via CDN for layout and Mermaid via CDN for diagrams where a graph, flow, or sequence reliably communicates the structure. Mix Mermaid with hand-crafted CSS/SVG visuals: use Mermaid when relationships are graph-shaped, and hand-built divs/SVG for mass diagrams, cross-sections, and collapse diagrams. Each candidate gets a before/after visualization.

See ~/.claude/skills/almanac/codebase-improve/HTML-REPORT.md for the full HTML scaffold, diagram patterns, and styling guidance.

For each candidate, render a card with:

Files — which files/modules are involved
Problem — why the current architecture is causing friction
Solution — plain English description of what would change
Benefits — explained in terms of locality and leverage, and also in how tests would improve
Before / After diagram — side-by-side, custom-drawn, illustrating the shallowness and the deepening
Recommendation strength — one of Strong, Worth exploring, Speculative, rendered as a badge

End the report with a Top recommendation section: which candidate you'd tackle first and why.

Use CONTEXT.md vocabulary for the domain, and codebase-design vocabulary for architecture.

ADR conflicts: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly (e.g. "contradicts ADR-0007 — but worth reopening because…").

Do NOT propose interfaces yet. After the file is written, ask the user: "Which of these would you like to explore?"

3. Grilling loop

Once the user picks a candidate, drop into a grilling conversation. Walk the decision tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.

Side effects happen inline as decisions crystallize:

Naming a deepened module after a concept not in CONTEXT.md? Add the term to CONTEXT.md. Create the file lazily if it doesn't exist.
Sharpening a fuzzy term during the conversation? Update CONTEXT.md right there.
User rejects the candidate with a load-bearing reason? Offer an ADR so future reviews don't re-suggest it. Only offer when the reason would actually be needed by a future explorer.
Want to explore alternative interfaces for the deepened module? Follow ~/.claude/skills/almanac/codebase-design/references/design-it-twice.md.