القائمة
扫描代码库以寻找"加深（deepening）"机会，把它们呈现为一份可视化的 HTML 报告，然后就你挑选的那一项进行刨根问底的追问。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
从两个维度审查自某个固定基点（提交、分支、标签或 merge-base）以来的改动 —— 规范（代码是否遵循本仓库有文档记录的编码规范？）与 需求（代码是否符合最初发起的 issue/PRD 的要求？）。以并行子代理运行两项审查并并排汇报。当用户想要审查某个分支、PR、进行中的改动，或要求“审查自 X 以来的改动”时使用。
基于一份规格或一组工单来实现一部分工作。
设计深模块的共享术语体系。当用户想要设计或改进某个模块的接口、寻找加深（deepening）的机会、决定接缝（seam）放在哪里、让代码更易测试或更利于 AI 导航时，或当其他技能需要用到深模块术语时使用。
构建并打磨项目的领域模型。当用户想要确定领域术语或统一语言（ubiquitous language）、记录架构决策，或当其他技能需要维护领域模型时使用。
通过一场刨根问底的访谈来打磨一份计划或设计。
通过一场刨根问底的访谈来打磨一份计划或设计，并在过程中同时产出文档（ADR 和词汇表）。
| name | improve-codebase-architecture |
| description | 扫描代码库以寻找"加深（deepening）"机会，把它们呈现为一份可视化的 HTML 报告，然后就你挑选的那一项进行刨根问底的追问。 |
| disable-model-invocation | true |
暴露架构上的摩擦，并提出 加深机会（deepening opportunities）——把浅模块变为深模块的重构。目标是可测试性与对 AI 友好的可导航性。
这条命令 受 项目领域模型 启发，并构建在一套共享的设计词汇之上：
/codebase-design 技能，获取架构词汇（module 模块、interface 接口、depth 深度、seam 接缝、adapter 适配器、leverage 杠杆、locality 局部性）及其原则（删除测试、"接口即测试面"、"一个适配器 = 假想的接缝，两个 = 真实的接缝"）。在每一条建议中都精确地使用这些术语——不要漂移成 "component"、"service"、"API" 或 "boundary"。CONTEXT.md 中的领域语言为好的接缝命名；docs/adr/ 中的 ADR 记录了这条命令不应重新翻案的决策。在扫描之前先划定范围——YAGNI。 加深一个模块的回报，来自让它未来更易于改动，所以要对代码库中近期变动过的部分格外看重。在动手看之前先决定 看哪里：
git log --oneline），找出代码库的热点——那些反复出现的文件和区域——让这些路径优先吸引你的注意。如果改动分散、没有明显热点，就把网撒得更宽一些。先阅读项目的领域词汇表（CONTEXT.md）以及你所触及区域内的所有 ADR。
然后用 Agent 工具（subagent_type=Search）来遍历代码库。不要遵循僵化的启发式规则——有机地探索，并记下你感到摩擦的地方：
对任何你怀疑是浅的东西，施加 删除测试：删掉它会让复杂度 集中，还是仅仅把它 挪走？一个"会集中"的"是"，正是你想要的信号。
将一个自包含的 HTML 文件写入操作系统的临时目录，这样就不会有东西落进仓库。从 $TMPDIR 解析临时目录，回退到 /tmp（Windows 上为 %TEMP%），并写入 <tmpdir>/architecture-review-<timestamp>.html，使每次运行都得到一个全新文件。为用户打开它——在 macOS 上用 open <path>——并告诉他们绝对路径。
报告使用 通过 CDN 引入的 Tailwind 进行布局和样式设计，并在图/流程/时序能可靠传达结构的地方使用 通过 CDN 引入的 Mermaid 绘制图表。把 Mermaid 与手工打造的 CSS/SVG 视觉元素混用——当关系呈图状（调用图、依赖、时序）时用 Mermaid，当你想要更有编排感的东西（体量图、剖面图、坍缩动画）时用手工构建的 div/SVG。每个候选项都配一张 前/后对比可视化图。要富有视觉表现力。
对每个候选项，渲染一张卡片，包含：
Strong、Worth exploring、Speculative 之一，以徽章形式呈现在报告末尾放一个 Top recommendation（首推）小节：你会最先着手哪个候选项，以及为什么。
领域方面使用 CONTEXT.md 的词汇，架构方面使用 /codebase-design 的词汇。 如果 CONTEXT.md 定义了 "Order"，就谈 "the Order intake module（订单接收模块）"——而不是 "the FooBarHandler"，也不是 "the Order service"。
ADR 冲突：如果某个候选项与现有 ADR 相抵触，只在摩擦真实到足以值得重新审视该 ADR 时才把它抛出来。在卡片中清晰标注（例如一个警示提示框："与 ADR-0007 相抵触——但值得重开，因为……"）。不要把某个 ADR 所禁止的每一个理论上的重构都列出来。
完整的 HTML 脚手架、图表模式和样式指南见 HTML-REPORT.md。
现在还 不要 提出接口方案。文件写好后，问用户："这里面你想探索哪一个？"
一旦用户挑定一个候选项，运行 /grilling 技能，与他们一起走一遍决策树——约束、依赖、加深后模块的形态、接缝之后是什么、哪些测试能存活。
副作用在决策逐渐清晰时就地发生——运行 /domain-modeling 技能，让领域模型随进展保持最新：
CONTEXT.md 中的概念为加深后的模块命名？ 把该术语加进 CONTEXT.md。如果文件不存在就延迟创建。CONTEXT.md。/codebase-design 技能，并使用它的"设计两次（design-it-twice）"并行子代理模式。