71 lines
5.3 KiB
Markdown
71 lines
5.3 KiB
Markdown
---
|
|
name: improve-codebase-architecture
|
|
description: Review a codebase for module-deepening opportunities and explain the most useful candidates. Use for an architecture survey or a specified area of architectural friction.
|
|
---
|
|
|
|
# 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.
|
|
|
|
This command is _informed_ by the project's domain model and built on a shared design vocabulary:
|
|
|
|
- Use `/codebase-design` to reason about module depth, caller contracts, locality, and justified test seams. Preserve project names such as component, service, or API; explain concepts without imposing a competing vocabulary or adapter count.
|
|
- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
|
|
|
|
## Process
|
|
|
|
### 1. Explore
|
|
|
|
**Scope before you scan — YAGNI.** Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide *where* to look before you look:
|
|
|
|
- If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.
|
|
- Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.
|
|
|
|
Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
|
|
|
|
Explore directly or delegate bounded independent areas through the available tools when useful. Note concrete 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 the useful candidates
|
|
|
|
Honor the requested format and output path. A concise Markdown report is enough for a few findings. For a requested visual HTML report, use a fresh temporary path by default and provide its location; open it only when requested.
|
|
|
|
Use a diagram only when relationships or a before/after change are clearer visually. Prefer static HTML/CSS/SVG or existing renderers; do not add CDN scripts or dependencies for a simple report.
|
|
|
|
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 how tests would improve
|
|
- **Before / After diagram** — only when it materially clarifies the change
|
|
- **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 accurate project names for the implementation. Design terms should clarify the proposed change, not rename existing concepts without need.
|
|
|
|
**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 in the card (e.g. a warning callout: _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
|
|
|
|
For HTML output, read [HTML-REPORT.md](HTML-REPORT.md) for a small offline scaffold and relevant diagram options.
|
|
|
|
Return the requested survey with a recommendation. If the user wants an interactive design session, offer to explore a candidate; otherwise stop at the report.
|
|
|
|
### 3. Grilling loop
|
|
|
|
When the user requests an interview about a candidate, use `/grilling` for unresolved constraints and decisions. Reuse existing answers and honor a request for a direct design recommendation instead.
|
|
|
|
When domain-document updates are within scope, use `/domain-modeling` as decisions crystallize; a read-only architecture report should only recommend these updates:
|
|
|
|
- **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, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones.
|
|
- **Want to explore alternative interfaces for the deepened module?** Run the `/codebase-design` skill and use its design-it-twice parallel sub-agent pattern.
|