用途
Improve Codebase Architecture 是一个智能体技能，用于发现代码库中的架构摩擦，并提出“深化机会”（deepening opportunities）：把浅模块重构为深模块，目标是提升可测试性和 AI 可导航性。
该技能由项目的领域模型驱动，并建立在共享的设计词汇之上。
设计词汇与前置依赖
运行 /codebase-design 技能可获得架构词汇（module、interface、depth、seam、adapter、leverage、locality）及其原则（删除测试、“接口即测试面”、“一个适配器 = 假设接缝，两个 = 真实接缝”）。所有建议必须严格使用这些术语，不要漂移成 “component”“service”“API” 或 “boundary”。
GLOSSARY.md 中的领域语言为好的接缝命名；docs/adr/ 中的 ADR 记录了本命令不应重新争论的决策。
使用方式
第一步：探索
先划定范围再扫描，遵循 YAGNI。深化模块的价值在于让未来对它的修改更容易，因此应额外重视最近发生变化的代码区域。在查看之前先决定看哪里：
- 如果用户指定了方向（某个模块、子系统或痛点），直接采用，跳过下面的推断。
- 否则，回溯一段提交历史（git log --oneline）找出代码库的热点（反复出现的文件和区域），让这些路径优先吸引注意力。如果变更分散、没有明显热点，则扩大范围。
- 先阅读项目的领域词汇表（GLOSSARY.md，或更早的 CONTEXT.md）以及所触及区域的 ADR。
然后在只读子智能体中遍历代码库（若环境支持）：在安装了本插件的 Claude Code 中，使用 Agent 工具、subagent_type=leek-skills:deepening-scout（已预载 codebase-design 词汇并记住本项目已深化过的内容）；普通 Claude Code 用 subagent_type=Explore；其他环境用其提供的只读扫描方式。这样扫描的文件转储不会进入当前上下文，只有发现结果返回。没有子智能体时则内联遍历。不要遵循僵化启发式，要有机地探索并记录摩擦点：
- 理解一个概念是否需要在许多小模块之间来回跳转？
- 哪些模块是浅的：接口几乎和实现一样复杂？
- 哪些地方仅为可测试性提取了纯函数，但真正的 bug 藏在调用方式中（缺乏局部性）？
- 哪些紧耦合模块跨越接缝泄漏？
- 代码库哪些部分未测试，或难以通过当前接口测试？
对任何疑似浅模块应用删除测试：删除它会集中复杂度，还是只是移动复杂度？“是，集中”就是想要的信号。
第二步：以 HTML 报告呈现候选方案
在仓库之外写一个自包含 HTML 文件：若环境指定了会话暂存目录则用它，否则用操作系统临时目录。从 $TMPDIR 解析临时目录，回退到 /tmp（Windows 上为 %TEMP%），写入 <dir>/architecture-review-<timestamp>.html，使每次运行生成新文件。然后展示它：若环境能发布页面（在 Claude Code 中，加载 artifact-design 技能后使用 Artifact 工具），将该文件发布为私有页面并给用户链接；否则为用户打开（Linux 用 xdg-open <path>，macOS 用 open <path>，Windows 用 start <path>）并告知绝对路径。
报告通过 CDN 使用 Tailwind 做布局和样式，通过 CDN 使用 Mermaid 绘制图表（当图/流程/时序能可靠传达结构时）。将 Mermaid 与手工 CSS/SVG 视觉混合：关系呈图状（调用图、依赖、时序）时用 Mermaid；想要更具编辑感（质量图、剖面图、折叠动画）时用手工 div/SVG。每个候选方案都有前后对比可视化。要注重视觉表达。
每个候选方案渲染一张卡片，包含：
- Files：涉及哪些文件/模块
- Problem：当前架构为何造成摩擦
- Solution：将发生什么变化的平实英文描述
- Benefits：以局部性和杠杆解释，以及测试将如何改善
- Before / After diagram：并排、手绘，展示浅与深
- Recommendation strength：Strong、Worth exploring、Speculative 之一，渲染为徽章
报告以 Top recommendation 部分结尾：你会先处理哪个候选方案及原因。
领域使用 GLOSSARY.md 词汇，架构使用 /codebase-design 词汇。如果 GLOSSARY.md 定义了 “Order”，就说 “the Order intake module”，而不是 “the FooBarHandler”，也不是 “the Order service”。
ADR 冲突：如果候选方案与现有 ADR 矛盾，仅当摩擦足够真实、值得重新审视该 ADR 时才呈现。在卡片中清楚标记（例如警告提示：“contradicts ADR-0007, but worth reopening because…”）。不要列出 ADR 禁止的每一个理论重构。
完整 HTML 脚手架、图表模式和样式指南见 HTML-REPORT.md。
此时不要提出接口。报告就绪后，询问用户想探索哪个候选方案（可用时用 AskUserQuestion：首选建议排第一并标记为 recommended，然后是最强的次选，最多 4 个选项，每个选项的预览是该候选方案形态的 ASCII 前后草图，“Other” 可达其余；否则在聊天中问：“Which of these would you like to explore?”）。
第三步：拷问循环
用户选定候选方案后，运行 /grilling 技能与其一起走决策树：约束、依赖、深化模块的形态、接缝背后是什么、哪些测试能存活。
副作用在决策成形时内联发生：运行 /domain-modeling 技能以保持领域模型最新：
- 用 GLOSSARY.md 中不存在的概念命名深化模块？把术语加入 GLOSSARY.md。文件不存在则惰性创建。
- 对话中厘清了模糊术语？当场更新 GLOSSARY.md。
- 用户以承重理由拒绝候选方案？提议一个 ADR，措辞为：“Want me to record this as an ADR so future architecture reviews don't re-suggest it?” 仅当未来探索者确实需要该理由以避免重复建议时才提议；跳过短暂理由（“not worth it right now”）和不言自明的理由。
- 想为深化模块探索替代接口？运行 /codebase-design 技能并使用其 design-it-twice 并行子智能体模式。
适用场景
- 需要识别代码库中值得重构的架构摩擦点。
- 希望以可视化报告形式向团队呈现重构候选方案。
- 希望围绕某个重构方向进行结构化推演并同步更新领域模型与 ADR。
限制
- 依赖 /codebase-design、/grilling、/domain-modeling 等配套技能。
- 子智能体能力取决于运行环境；无子智能体时需内联遍历。
- 报告发布方式取决于环境是否支持发布页面。
- 资料未提供具体的收费、价格或平台支持信息。