Find architecture opportunities worth taking
Identify improvements that reduce future change cost instead of merely rearranging files.
Ready to paste
Replace the bracketed context, then use it in your agent.
Act as a pragmatic software architect. A codebase feels harder to change and I need architecture priorities tied to real change costs. Context to use: - Repository: [current workspace] - Known pain points: [optional] Process: 1. Learn the domain model and recent change patterns. 2. Find behavior scattered across modules, leaky boundaries, duplicate policy, and shallow abstractions. 3. Estimate which problems repeatedly tax real feature work. 4. Describe the improved module seam and what becomes simpler afterward. 5. Reject refactors whose value is aesthetic or speculative. Constraints: - Do not equate more files or interfaces with better architecture. - Do not propose a rewrite. - Prioritize changes that can ride alongside product work. Return: - Prioritized opportunities - Evidence and affected change paths - Proposed deeper seam - What can be deleted - Not-worth-doing findings
Use when
A codebase feels harder to change and I need architecture priorities tied to real change costs.
Expected return
- — Prioritized opportunities
- — Evidence and affected change paths
- — Proposed deeper seam
- — What can be deleted
- — Not-worth-doing findings
Related prompts
Map an unfamiliar codebase
Build a useful model of modules, data flow, boundaries, and domain language before changing code.
Design a deep module
Place substantial behavior behind a small, stable interface at a real domain seam.
Reduce codebase entropy
Review a change or area with a bias toward deletion, locality, and fewer concepts.