Architecture Deepening Review
Find refactors that increase leverage and locality. A deeper module hides meaningful behavior behind a smaller, clearer interface.
Vocabulary
- Module: code with an interface and implementation.
- Interface: everything callers must know, including types, invariants, errors, ordering, config, and side effects.
- Seam: place where behavior can vary without editing callers.
- Adapter: concrete implementation behind a seam.
- Depth: useful behavior hidden behind a small interface.
- Locality: related behavior and knowledge concentrated in one place.
Review Workflow
- Read the nearest README, architecture docs, domain glossary, ADRs, and tests when present.
- Map the user-facing or domain workflow before judging structure.
- Look for friction:
- understanding one concept requires bouncing across many files;
- modules pass through data with little leverage;
- tests exist only around extracted fragments, not real behavior;
- domain rules are duplicated across callers;
- adapters exist in theory but only one implementation exists;
- hidden coupling crosses package or component boundaries;
- naming does not match domain language.
- Apply the deletion test: if removing a module only moves complexity into callers, it may be shallow. If removing it spreads domain complexity everywhere, it is probably earning its keep.
- Rank candidates by payoff, risk, and confidence.
Candidate Format
For each candidate:
- files/modules;
- current friction;
- proposed deeper module or seam;
- expected locality and leverage gain;
- testability improvement;
- risks and migration path;
- recommendation strength: strong, worth exploring, or speculative.
Do not implement broad refactors without user confirmation. For implementation, carve one vertical slice and preserve behavior with tests.
Optional HTML Report
When the user asks for a shareable architecture review, executive-readable report, or visual artifact, do not inline a long prose dump. Route the findings into html-diagram-artifact or html-brief-artifact after the candidate list is stable. The HTML artifact should stay evidence-backed: files/modules, friction, proposed seam, benefit, risk, and first slice.
Final Report
End with the top recommendation, the smallest first step, and what evidence would change the recommendation.
1---2name: architecture-deepening-review3description: Review a codebase for architecture deepening opportunities: shallow modules, weak seams, scattered domain logic, low testability, high coupling, and AI-navigability friction. Use when the user asks for architecture improvement, refactoring opportunities, modularity, test seams, or maintainability review.4license: MIT5---67# Architecture Deepening Review89Find refactors that increase leverage and locality. A deeper module hides meaningful behavior behind a smaller, clearer interface.1011## Vocabulary1213- Module: code with an interface and implementation.14- Interface: everything callers must know, including types, invariants, errors, ordering, config, and side effects.15- Seam: place where behavior can vary without editing callers.16- Adapter: concrete implementation behind a seam.17- Depth: useful behavior hidden behind a small interface.18- Locality: related behavior and knowledge concentrated in one place.1920## Review Workflow21221. Read the nearest README, architecture docs, domain glossary, ADRs, and tests when present.232. Map the user-facing or domain workflow before judging structure.243. Look for friction:25 - understanding one concept requires bouncing across many files;26 - modules pass through data with little leverage;27 - tests exist only around extracted fragments, not real behavior;28 - domain rules are duplicated across callers;29 - adapters exist in theory but only one implementation exists;30 - hidden coupling crosses package or component boundaries;31 - naming does not match domain language.324. Apply the deletion test: if removing a module only moves complexity into callers, it may be shallow. If removing it spreads domain complexity everywhere, it is probably earning its keep.335. Rank candidates by payoff, risk, and confidence.3435## Candidate Format3637For each candidate:3839- files/modules;40- current friction;41- proposed deeper module or seam;42- expected locality and leverage gain;43- testability improvement;44- risks and migration path;45- recommendation strength: strong, worth exploring, or speculative.4647Do not implement broad refactors without user confirmation. For implementation, carve one vertical slice and preserve behavior with tests.4849## Optional HTML Report5051When the user asks for a shareable architecture review, executive-readable report, or visual artifact, do not inline a long prose dump. Route the findings into `html-diagram-artifact` or `html-brief-artifact` after the candidate list is stable. The HTML artifact should stay evidence-backed: files/modules, friction, proposed seam, benefit, risk, and first slice.5253## Final Report5455End with the top recommendation, the smallest first step, and what evidence would change the recommendation.
markoblogo