Explore a codebase like an AI would, surface architectural friction, discover opportunities for improving testability, and propose module-deepening refactors as GitHub issue RFCs.
A deep module (John Ousterhout, "A Philosophy of Software Design") has a small interface hiding a large implementation. Deep modules are more testable, more AI-navigable, and let you test at the boundary instead of inside.
Use the Agent tool with subagent_type=Explore to navigate the codebase naturally. Do NOT follow rigid heuristics — explore organically and note where you experience friction:
Where does understanding one concept require bouncing between many small files?
Where are modules so shallow that the interface is 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?
Where do tightly-coupled modules create integration risk in the seams between them?
Which parts of the codebase are untested, or hard to test?
Present a numbered list of deepening opportunities. For each candidate, show:
Cluster: Which modules/concepts are involved
Why they're coupled: Shared types, call patterns, co-ownership of a concept
Dependency category: See REFERENCE.md for the four categories
Test impact: What existing tests would be replaced by boundary tests
Do NOT propose interfaces yet. Ask the user: "Which of these would you like to explore?"
列出带编号的模块加深机会清单。对于每个候选点，需要展示：
集群：涉及哪些模块/概念
耦合原因：共享类型、调用模式、概念的共同归属
依赖类别：参考REFERENCE.md中的四类
测试影响：哪些现有测试会被边界测试取代
暂时不要提出接口方案。向用户询问：“你想深入探索其中哪一个？”
3. User picks a candidate
3. 用户选择候选点
4. Frame the problem space
4. 界定问题范围
Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
The constraints any new interface would need to satisfy
The dependencies it would need to rely on
A rough illustrative code sketch to make the constraints concrete — this is not a proposal, just a way to ground the constraints
Show this to the user, then immediately proceed to Step 5. The user reads and thinks about the problem while the sub-agents work in parallel.
在生成子代理之前，为选定的候选点撰写一份面向用户的问题范围说明：
任何新接口需要满足的约束条件
它需要依赖的项
一个粗略的示例代码草图来明确约束——这不是最终方案，只是让约束更具象化
将此说明展示给用户，然后立即进入步骤5。用户在阅读和思考问题的同时，子代理可以并行工作。
5. Design multiple interfaces
5. 设计多个接口
Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a radically different interface for the deepened module.
Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category, what's being hidden). This brief is independent of the user-facing explanation in Step 4. Give each agent a different design constraint:
Agent 1: "Minimize the interface — aim for 1-3 entry points max"
Agent 2: "Maximize flexibility — support many use cases and extension"
Agent 3: "Optimize for the most common caller — make the default case trivial"
Agent 4 (if applicable): "Design around the ports & adapters pattern for cross-boundary dependencies"
Each sub-agent outputs:
Interface signature (types, methods, params)
Usage example showing how callers use it
What complexity it hides internally
Dependency strategy (how deps are handled — see REFERENCE.md)
Trade-offs
Present designs sequentially, then compare them in prose.
After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated — the user wants a strong read, not just a menu.