Add architecture review skill and readability guidance

README.md

@@ -1,12 +1,13 @@
 # Coding Skills
 
-三个中文工程 skill，用精简的当前决策保持目标一致，将规划、实施与独立审查放在不同会话。
+四个中文工程 skill，用精简的当前决策保持目标一致，将规划、实施与独立审查放在不同会话。
 
 | Skill | 用途 | 产出 |
 | --- | --- | --- |
 | `align-plan` | 调查代码、每轮提问 1–3 个问题、核对假设并收敛范围 | 系统约束、当前决策与用户确认后的可执行计划 |
 | `execute-plan` | 按已确认计划实施、验证、核对范围和 review | 外部实施记录与本地 Git commit |
 | `review-changes` | 对比当前分支与最新远程 master，审查原始目标、行为偏差及旧功能回归 | 外部审查报告，不自动修复 |
+| `review-architecture` | 检查指定模块或整个项目的架构与模块设计 | 有证据的外部报告与优化建议，不自动重构 |
 
 ## 安装
 
@@ -18,11 +19,11 @@
 npx -y skills add ssh://git@gitea.fjy8018.top:8022/fjy8018/coding-skills.git --skill '*'
 ```
 
-需要已配置可访问该仓库的 SSH 密钥。三个 skill 也可单独安装，将 `'*'` 替换为 `align-plan`、`execute-plan` 或 `review-changes` 即可。安装时由 CLI 选择目标 agent。
+需要已配置可访问该仓库的 SSH 密钥。四个 skill 也可单独安装，将 `'*'` 替换为 `align-plan`、`execute-plan`、`review-changes` 或 `review-architecture` 即可。安装时由 CLI 选择目标 agent。
 
 ## 使用
 
-三个 skill 仅在用户明确调用时启用。Codex 中可使用 `$align-plan`、`$execute-plan`、`$review-changes` 或通过 skill 选择器调用；普通规划、执行或审查请求不自动启用。
+四个 skill 仅在用户明确调用时启用。Codex 中可使用 `$align-plan`、`$execute-plan`、`$review-changes`、`$review-architecture` 或通过 skill 选择器调用；普通规划、执行或审查请求不自动启用。
 
 在项目目录中开始规划，例如：
 
@@ -35,9 +36,11 @@ Agent 先调查再提问，纠正有证据的错误判断，每轮维护精简
 
 计划列出修改文件、目标、原因和验收要求，不预写详细实现代码。核心算法可附少量代码或伪代码帮助审查；具体实现由执行 agent 在已批准的行为和架构边界内自主决定。
 
-方案与实施遵循最小改动、单一职责和开闭原则，按需采用设计模式；保持功能模块边界，通用架构能力不绑定具体业务，避免为套模式增加抽象，以降低扩展和审查复杂度。
+方案与实施始终把 Codex 可读性放在第一位：业务入口容易定位，职责、接口契约和调用与数据流清晰。围绕业务职责模块化，同一业务规则有明确归属，跨模块调用方只依赖公开接口、不感知内部实现，保持高内聚、低耦合；通用架构能力不绑定具体业务。接受模块化初期一定程度的过度工程化，不因只有一个实现就否定接口，但新增结构须有明确职责和收益。最少行数、最少文件和最小 diff 不能代替可读性。
 
-最小改动不等于最少行数或继续堆叠旧逻辑。发现与目标相关的复用提取或模块解耦机会时，agent 会说明收益、成本和影响范围，向用户确认后再纳入计划。
+每个功能或优化点在确定方案、开始实施前，局部检查相关模块的 Codex 可读性、循环依赖、复杂度和架构健康度，复用仍有效的证据，不机械重复全仓扫描、不自动调用架构检查 skill。发现与目标相关的优化空间时，先说明证据、沿用现状继续开发的影响、优化方向、收益、成本及范围，再确认是否本次处理；已批准的优化不重复询问，无问题时直接推进。
+
+用户确认本次不优化后，将“本次任务 × 模块 × 检查维度”和确认依据记入当前讨论状态及计划，实施阶段同步计划、执行记录和已有讨论状态。此任务不再检查或追问该组合，其他模块和维度继续；跨会话及压缩恢复后继承，新任务默认重置，本任务只有用户明确调整才恢复。决定不写成 CONTEXT 中的永久约束，也不免除必要代码阅读、功能正确性验证或已批准验收。
 
 审阅确认后自行开启新会话，指定已批准的计划：
 
@@ -77,6 +80,26 @@ $review-changes 审查当前分支。
 
 报告保存为外部 `review-YYYYMMDD-HHmmss.md`，包含目标达成与偏差、已确认问题、关键验证缺口、基线及实际验证结果，对话给摘要和链接。可复用已有资产定位，位置缺失时询问，不回退代码库。允许获取远程引用和必要验证，不修改被审代码、计划或门禁，不自动修复、提交或推送。
 
+### 架构与模块检查
+
+在项目目录中指定模块，或不指定模块以检查整个项目：
+
+```text
+$review-architecture 检查订单模块。
+报告放到 /绝对路径/工程讨论。
+```
+
+```text
+$review-architecture 检查整个项目的架构，给出模块优化建议。
+报告放到 /绝对路径/工程讨论。
+```
+
+检查覆盖 Codex 可读性、循环依赖、复杂度、架构健康度和逻辑分叉。指定模块时沿相关调用及依赖核实边界问题；全项目检查说明实际覆盖和遗漏，不以少数样本宣称全项目健康。默认检查当前工作区，包括相关未提交和未跟踪源码，记录基线与工作区状态；不要求远程 master，非 Git 项目也可使用。
+
+报告给出真实依赖闭环、模块职责和接口问题、重复业务规则及行为漂移等证据，并区分合理跨模块协作、初期接口抽象和合法业务或兼容分支。按影响排序优化建议，说明收益、成本、影响范围、接口与兼容性影响及验证方向，区分已确认问题与待核实疑点，不用抽象数量或固定复杂度阈值直接判坏。
+
+报告保存为外部 `architecture-review-YYYYMMDD-HHmmss.md`，复用已有资产定位；缺失时询问并继续只读调查。此 skill 不修改被审代码，不自动生成实施计划或执行重构，交付报告即完成。独立检查不自动继承其他任务的跳过决定，用户可明确限定本次范围；需要优化时自行调用 `align-plan` 对齐方案。
+
 ## 资产约定
 
 规划与实施首次未指定资产目录时会询问；之后从项目 `.agent/MEMORY.md` 复用。这个文件只保存必要定位信息，通过 Git 本地 exclude 排除，不修改项目共享 `.gitignore`。已被跟踪时会先报告冲突，不自行取消跟踪。独立审查只读取已有定位，不维护 MEMORY 或 CONTEXT。
@@ -88,14 +111,15 @@ $review-changes 审查当前分支。
   CONTEXT.md                     当前业务与技术约束、模块
   日期-计划主题/
     current.md                   当前目标、确认决策、约束与未决问题
-    plan.md                   最新自包含计划，原地修订、审阅确认
+    plan.md                      最新自包含计划，原地修订、审阅确认
     execution-日期时间.md         实施与验证记录
-    review-日期时间.md            独立审查报告
+    review-日期时间.md            分支变更审查报告
+    architecture-review-日期时间.md 架构与模块检查报告
 ```
 
 每个计划目录只维护 plan.md，修订直接覆盖，只保留最新方案，不生成版本副本或历史方案。实质修订清除旧批准依据并标为待确认，用户重新审阅后再执行。对话只给摘要和链接，写入成功不代表批准。current.md 同样只维护当前讨论状态，不累计历史。目录失效或无法写入时会报告，不自行改存代码库。个人绝对路径不写入可分发的 skill。
 
-两个 skill 在确定资产根目录后都先读取 `CONTEXT.md`，再针对本次目标核实相关代码；新会话或上下文恢复时同样读取，无需扫描历史计划。根目录默认对应一个系统；若文档属于其他系统，先澄清。用户只指定计划目录时，保留已知系统根目录，未知则询问，不推断父目录。
+规划与实施两个 skill 在确定资产根目录后都先读取 `CONTEXT.md`，再针对本次目标核实相关代码；新会话或上下文恢复时同样读取，无需扫描历史计划。根目录默认对应一个系统；若文档属于其他系统，先澄清。用户只指定计划目录时，保留已知系统根目录，未知则询问，不推断父目录。
 
 `CONTEXT.md` 只描述当前有效的业务约束和技术约束，可注明适用模块及必要原因。无需实施的已确认规则直接更新；依赖改造的方案暂留在讨论和计划中，经实施、验证和 review 完成后再更新 CONTEXT。冲突先确认，替换时删除废弃规则，不保存中间决策、状态历史或关联历史计划路径。
 
@@ -111,7 +135,7 @@ $review-changes 审查当前分支。
 ---
 ```
 
-系统填写项目或系统名称，目标概括对应计划的目标，无法确定时留空。规划与实施资产的时间对应资产所依据的决策，使用用户当地日期。未确认草稿先记创建日期，正文标明待确认；确认后更新为确认日期。计划重新批准后使用新确认日期；实施记录沿用计划决策日期，执行时间单独记录。纯进度或排版更新不改决策日期。审查报告的时间使用用户当地审查日期，目标对应被审变更的原始目标。
+系统填写项目或系统名称，目标概括对应任务的目标，无法确定时留空。规划与实施资产的时间对应资产所依据的决策，使用用户当地日期。未确认草稿先记创建日期，正文标明待确认；确认后更新为确认日期。计划重新批准后使用新确认日期；实施记录沿用计划决策日期，执行时间单独记录。纯进度或排版更新不改决策日期。审查报告的时间使用用户当地审查日期；分支变更审查的目标对应原始需求，架构检查的目标对应所查模块或项目及优化目标。
 
 CONTEXT 的目标填写“保存系统当前业务与技术约束”，时间为最近一次确认系统决策的日期；普通排版更新不修改该日期。
 
@@ -125,26 +149,30 @@ Markdown 正文使用带语言标记的代码块包裹代码、命令和多行
 npx skills add . --list
 ```
 
-预期发现 `align-plan`、`execute-plan` 和 `review-changes`。若已安装 skill-creator，可用其 `scripts/quick_validate.py` 分别检查三个 skill 目录；它是开发期检查工具，不是安装或运行依赖。各目录的 `agents/openai.yaml` 均应保留显式调用策略。
+预期发现 `align-plan`、`execute-plan`、`review-changes` 和 `review-architecture`。若已安装 skill-creator，可用其 `scripts/quick_validate.py` 分别检查四个 skill 目录；它是开发期检查工具，不是安装或运行依赖。各目录的 `agents/openai.yaml` 均应保留显式调用策略。
 
 行为检查应使用真实 agent 在隔离项目中演练：目录首次询问与复用、错误假设纠正、长对话恢复、目标分阶段、批准前不实现、新会话交接、必要配套文件与范围扩展的区别、过期计划、测试覆盖与重复、已有用户修改及提交隔离。
 
 系统上下文还需检查：首次无 CONTEXT、下次直接读取、无实施依赖的确认规则直接记录、待实施方案只留计划、冲突澄清、执行失败不改当前约束、验证后替换废弃规则、局部实现细节不写入系统约束。
 
+逐项检查需检查：发现优化机会后先给证据再确认、已批准优化不重复询问、拒绝后只跳过本次指定模块与维度、其他组合继续、实施及上下文恢复继承决定、新任务恢复检查；跳过决定不进入 CONTEXT，也不跳过正确性验证和已批准验收。
+
 独立审查需检查：远程领先不误报删除、未提交内容不混入、获取失败不声称最新、目标缺失不推断完成、混排文档不泄漏实施内容；旧功能回归、删除逻辑、未接入实现和弱断言能进入审查，已有保护、合法兼容分支和无关历史问题不被误报。报告须分离缺陷与验证缺口，不引用实施结果作证明、不修改被审代码。
 
+架构检查需检查：指定模块及跨边界依赖闭环、未指定模块时全项目覆盖、工作区含未提交源码、非 Git 项目、真实循环与动态依赖证据不足、合理跨模块协作、单实现接口、重复规则与合法条件分支的区分。报告覆盖五个维度和实际限制；独立检查不沿用其他任务的跳过决定、不修改代码、不自动开始规划或实施，报告目录缺失或不可用时不回退被审项目。
+
 结构验证只能检查格式和可发现性；静态场景复核只能发现指令缺口。两者都不证明模型实际遵循工作流，实际行为需要另行记录演练证据。不要把文字规则当作宿主级权限隔离。
 
 ## 参考来源
 
-参考 [OpenAI 关于 GPT-6 Astra 的 skill 与提示设计建议](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra)：精确描述触发条件，按任务读取资料，以交付结果和决策边界约束工作，避免固定步骤造成过早停止。两个 skill 各自只有一个工作流，保持自包含，不为拆分而新增路由文件；显式调用、用户审阅及范围约束继续保留。
+参考 [OpenAI 关于 GPT-6 Astra 的 skill 与提示设计建议](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra)：精确描述触发条件，按任务读取资料，以交付结果和决策边界约束工作，避免固定步骤造成过早停止。各 skill 保持自包含，不为拆分而新增路由文件，不互相自动调用；显式调用、用户审阅及范围约束继续保留。
 
 独立编写本仓库指令，借鉴以下机制，不复制其完整工作流，也不要求安装这些项目：
 
-- [Ponytail](https://github.com/DietrichGebert/ponytail)：理解问题后，优先复用并选择满足目标的最小实现。
+- [Ponytail](https://github.com/DietrichGebert/ponytail)：理解问题后优先复用、控制范围；本仓库以 Codex 可读性和模块边界为先，接受有明确收益的初期模块化成本。
 - [Superpowers](https://github.com/obra/superpowers)：参考 brainstorming 的确认边界、writing-plans 的文件与验证说明、executing-plans 的计划复核。
 - [Matt Pocock Skills](https://github.com/mattpocock/skills)：参考 grill-me / grilling 的先调查事实、再讨论决策。这里限制每轮 1–3 问，以目标和验收收敛，不要求穷尽所有分支。
 
 另外参考 [domain-modeling](https://github.com/mattpocock/skills/blob/main/skills/engineering/domain-modeling/SKILL.md) 在讨论中持续沉淀的机制。上游 CONTEXT 限于术语表、设计决策另存 ADR；本项目按需要将当前业务与技术约束直接保存在外部 CONTEXT，不引入 ADR 框架。
 
-上游工作流会变化；本仓库的实际规则以三个 `SKILL.md` 为准。
+上游工作流会变化；本仓库的实际规则以四个 `SKILL.md` 为准。

skills/align-plan/SKILL.md

@@ -41,17 +41,24 @@ Markdown 正文按内容排版：代码、命令及多行配置用带语言标
 - 调查限于当前目标所需的代码、调用链和测试；只有涉及架构、数据或上线时才补读相应资料。外部查证须能解决具体未决问题，保留来源和必要版本，不为走流程搜索。
 - 每轮共 1–3 个影响目标、验收或取舍的问题，不能用子问题变相扩充。可查事实不问用户，依赖未决答案的问题后置；有提问工具则使用，否则直接问。
 - 简述证据与推荐理由，不用装饰性 emoji。纠正错误事实，区分假设与偏好；用户提出想法不等于确认方案。
-- 优先复用现有能力，选择满足目标的最小方案。出现独立子目标或明显扩大的改造时，说明扩大点、建议分阶段，由用户选择；未确认前保持原范围。
-- 设计遵循最小改动、单一职责和开闭原则，按实际变化点采用合适设计模式；隔离功能模块，通用架构能力不耦合具体业务规则。以降低扩展和审查复杂度为准，不为套模式新增无必要抽象或扩大重构。
-- 最小改动不等于最少行数或继续堆叠旧逻辑。发现与本次目标相关、能减少重复或耦合的提取机会时，对比沿用与提取方案的收益、成本及影响文件，纳入当轮 1–3 问向用户确认，再决定是否纳入计划。
+- 在满足下述可读性与模块边界的前提下，优先复用现有能力，控制改动范围。出现独立子目标或明显扩大的改造时，说明扩大点、建议分阶段，由用户选择；未确认前保持原范围。
 - 目标、边界、关键取舍和验收明确后停止提问。
 
+## 设计原则与逐项检查
+
+- **Codex 可读性永远摆在第一位**：让业务入口容易定位，职责和接口契约清晰，调用与数据流容易追踪；不以最少行数、最少文件或最小 diff 代替可读性，也不为缩小改动继续堆叠旧逻辑。
+- **功能模块化设计**：围绕业务职责划分模块，同一业务规则有明确归属，跨模块调用方只依赖公开接口，不感知内部实现，保持高内聚、低耦合。遵循单一职责和开闭原则，通用架构能力不绑定具体业务；区分合理协作与业务规则散落，不把整个业务链路强塞进一个模块。
+- 接受模块化初期一定程度的过度工程化，包括为清晰边界增加接口、文件和结构；不因暂时只有一个实现就否定接口。新增结构应能解释其职责及可读性、隔离或演进收益，不为套模式增加无关抽象。
+- 每个功能或优化点在确定方案前，局部检查相关模块及调用、依赖关系的 **Codex 可读性、循环依赖、复杂度、架构健康度**。健康度按上述模块职责与接口边界判断，循环依赖须有实际闭环依据，复杂度关注理解和修改成本；复用仍有效的证据，不机械重复全仓扫描，也不自动调用其他 skill。
+- 发现与本次目标相关的优化空间时，先给出代码证据、沿用现状继续开发的影响、优化方向、收益、成本及范围，纳入当轮 1–3 问确认是否本次处理。已批准的优化不重复确认；未确认的优化不纳入实施范围，无问题时直接推进。
+- 用户确认本次不优化后，在 `current.md` 和 `plan.md` 记录本次任务、适用模块、跳过的检查维度及用户确认依据。此任务不再检查或追问该“模块 × 维度”，其他组合继续；范围不明确时澄清，不自行扩大。新会话或压缩恢复须继承，新任务默认重置，本任务仅用户明确调整才恢复。跳过决定不写入 `CONTEXT.md`，也不免除必要代码阅读、功能正确性验证和已批准验收。
+
 ## 写入、审阅与交接
 
 只维护 `<计划目录>/plan.md`，先写入并标为“待确认”；修订覆盖同一文件，只描述最新方案，不保留版本副本、旧方案或变更历史。正文自包含，可合并章节，但须有：
 
 1. **定位**：项目及必要仓库标识、资产根目录与 CONTEXT 绝对路径、Git 基线（无提交则注明）、相关工作区变化、确认状态/依据。
-2. **目标与决策**：原始目标、当前/目标行为、保留行为、不做事项；决策理由、业务/接口/架构变化或不变；相关系统约束快照及状态、已确认假设。
+2. **目标与决策**：原始目标、当前/目标行为、保留行为、不做事项；决策理由、业务/接口/架构变化或不变；相关系统约束快照及状态、已确认假设；本次已批准的优化及按模块、维度跳过检查的决定与确认依据，供实施继承。
 3. **修改范围**：新增/修改/删除的文件、各自目标和原因、必要依赖顺序及对应验收。允许必要测试/配置配套文件并记录，其他范围变化重新确认。
 4. **验证**：从原始目标推导正常、边界、异常及保留行为场景，明确预期结果和对应验收；列测试、运行目录/命令与必要环境。不能仅按变更代码列用例，预期行为须独立于实现，能发现偏离目标的结果。
 5. **兼容与上线**：评估受影响的接口、数据、配置及新旧版本兼容性；明确是否需要迁移、特殊上线步骤或先后顺序，必要时说明回退限制。无特殊要求则注明，未知项列为待核实。

skills/execute-plan/SKILL.md

@@ -12,7 +12,7 @@ description: 仅用户指定 execute-plan 时启用；实施已批准计划，
 ## 读取与核对
 
 1. 完整读取用户指定计划；路径不明则询问。从计划定位或 `.agent/MEMORY.md` 确定根目录并读 `CONTEXT.md`，再按任务核实代码、测试与项目约束；架构、数据、部署资料仅在涉及对应改动时读取，不扫描历史计划，避免无关的全仓库扫描。定位冲突或系统不符先澄清，不猜根目录；无 CONTEXT 时依靠计划与代码。
-2. 核对计划批准依据、目标、范围与验收。基线变化先调查影响，无关更新不阻塞；关键缺口、未批准或实质冲突先澄清。已批准的规则迁移按计划执行，不因仍有旧规则重复确认。
+2. 核对计划批准依据、目标、范围与验收，继承本次已批准的优化和按模块、维度跳过检查的决定。基线变化先调查影响，无关更新不阻塞；关键缺口、未批准或实质冲突先澄清。已批准的规则迁移按计划执行，不因仍有旧规则重复确认。
 3. 记录仓库身份、分支、HEAD（或无提交）及暂存/未暂存/未跟踪状态，足以区分用户已有修改。保护用户内容；重叠且不能隔离时先解决，不回退或混合提交。
 
 宿主禁止实施时遵从限制；新会话是使用约定，不能假称清空了上下文。
@@ -42,12 +42,15 @@ Markdown 正文中代码、命令和多行配置用带语言标记的围栏代
 ## 实施边界
 
 - 每项改动对应批准任务或验收；优先复用现有能力，自主决定具体代码及内部组织，不要求计划提供详细代码或逐字照抄算法示例。
-- 在最小改动范围内遵循单一职责、开闭原则，按需应用设计模式；避免功能模块耦合及通用架构能力依赖业务规则，降低扩展与审查复杂度，不为模式引入无必要抽象。
-- 不为缩小 diff 堆叠旧逻辑。发现本次目标相关且计划未覆盖的复用提取或模块解耦机会时，说明代码依据、收益、成本和影响范围，向用户确认；确认纳入后按范围变更流程更新 plan.md 再实施，不擅自重构或重复确认已批准方案。
+- **Codex 可读性永远摆在第一位**：业务入口容易定位，职责与接口契约清晰，调用和数据流容易追踪；不以最少行数、最少文件或最小 diff 代替可读性，不为缩小改动堆叠旧逻辑。
+- 围绕业务职责模块化，同一业务规则有明确归属，跨模块调用方只依赖公开接口，不感知内部实现，保持高内聚、低耦合；遵循单一职责、开闭原则，通用架构能力不绑定具体业务。区分合理协作与规则散落，不将整个业务链路塞进一个模块。接受模块化初期一定程度的过度工程化，不因只有一个实现就否定接口；新增结构须有清晰职责和可读性、隔离或演进收益，仍受批准范围约束。
+- 每个功能或优化点开始实施前，对相关模块及调用、依赖关系局部检查 **Codex 可读性、循环依赖、复杂度、架构健康度**。健康度按上述职责与接口边界判断，循环依赖须有实际闭环依据，复杂度关注理解和修改成本；复用仍有效的规划证据，先排除本次已跳过的组合，不机械重复全仓扫描，也不自动调用其他 skill。
+- 发现与本次目标相关且计划未覆盖的优化空间时，先说明代码证据、沿用现状继续开发的影响、优化方向、收益、成本及范围，再确认是否本次处理。确认纳入后按范围变更流程更新 `plan.md` 再实施；已批准的优化不重复确认，未确认的不擅自实施，无问题时直接推进。
+- 用户确认本次不优化时，将本次任务、适用模块、跳过的检查维度和确认依据记入计划、执行记录及已有的 `current.md`；仅记录拒绝决定不扩大实施范围，也不要求重新批准未变的方案。此任务不再检查或追问该“模块 × 维度”，其他组合继续；范围不明时澄清，不扩大解释。恢复会话时继承，新任务默认重置，本任务仅用户明确调整才恢复。跳过决定不写入 `CONTEXT.md`，也不免除必要代码阅读、功能正确性验证和已批准验收；完成时的 review 同样遵守此边界。
 - 核实引用和兼容用途后，移除本次范围内已无用途的死代码、被替代的遗留实现及失效分支，保持代码简洁；不能仅因代码陈旧就删除，范围外清理仍先确认。
 - 若发现实现与已确认决策有重大出入（如核心假设不成立、业务语义或架构边界必须改变），立即停止执行，保留现场并记录证据、已完成内容和待对齐问题；建议用户回到 align-plan 重新对齐范围与边界。新计划重新确认前不继续实现，不用就地改计划掩盖偏离或宣称完成。
 - 可补必要测试/配置文件并说明对应验收；其他文件扩展、业务/接口/架构变化或依赖升级须先确认，不能包装为配套改动。无关发现只记录，不顺手修复或重构。
-- 一般范围调整直接更新同一 plan.md，仅保留最新方案；清除旧批准依据并标待确认，对话只给摘要、原因及链接。用户重新批准后继续；重大出入按上述停止流程返回 align-plan，不生成版本副本或历史方案。完成前重读文件，若内容已变而未重新批准，先澄清。
+- 一般范围调整直接更新同一 plan.md，仅保留最新方案；清除旧批准依据并标待确认，对话只给摘要、原因及链接。用户重新批准后继续；重大出入按上述停止流程返回 align-plan，不生成版本副本或历史方案。完成前重读文件，若实施方案有实质变更而未重新批准，先澄清。
 
 ## 验证、Review 与提交
 

skills/review-architecture/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: review-architecture
+description: 仅用户指定 review-architecture 时启用；检查指定模块或整个项目的架构，输出有证据的优化建议，不修改代码。
+---
+
+# 检查架构与模块设计
+
+完成条件：覆盖约定范围的五个检查维度，核实候选问题，保存包含证据、优化建议及检查限制的报告。不能在首次浏览或发现第一个问题后结束，也不为凑数找问题或在无新证据时反复检查。
+
+仅检查并给出优化建议，不修改被审代码、配置、计划或质量门禁，不自动生成实施计划，不修复、提交或推送。允许只读调查、必要验证及写入外部报告；需改文件的验证在隔离副本中进行，不影响用户工作区，不执行有实际外部副作用的验证。可独立使用，不要求先运行其他 skill，不自动调用规划或实施流程。
+
+## 范围与事实依据
+
+- 用户指定模块时，先根据代码定位实际边界，检查模块内部并沿相关调用、依赖关系核实边界问题；需要追踪跨出模块再返回的依赖闭环时继续追踪，但不扩展为无关模块审计。存在多个合理候选模块时澄清。
+- 未指定模块则检查整个项目，从业务模块、入口和依赖关系组织调查，覆盖项目自有代码及有关配置、测试；排除第三方依赖副本、构建产物等非维护源码。报告说明实际覆盖范围，不能以少数样本宣称全项目健康。
+- 默认检查当前工作区，包括与范围相关的暂存、未暂存及未跟踪源码。记录项目位置、检查时间、分支、HEAD（或无提交）及工作区状态，不以 HEAD 快照代替工作区，不要求获取远程或比较 master。非 Git 项目记录可用定位即可。检查期间相关文件变化时复核受影响证据，并说明结论对应的状态。
+- 按需读取适用项目规范、模块契约、测试和现有 `CONTEXT.md`；可从 `.agent/MEMORY.md` 读取外部资产定位，不维护 MEMORY 或 CONTEXT，不扫描历史计划。独立检查不自动继承其他任务的跳过决定；用户明确限定本次检查时记录排除项。
+- 以实际入口、调用方、实现和依赖解析为依据，优先复用现有分析工具；工具不可用时可用静态证据继续，并标明不能验证的部分。
+
+## 检查标准
+
+**Codex 可读性永远摆在第一位。** 以理解职责、追踪行为及安全修改的成本判断，不以最少行数、最少文件或最小 diff 衡量。接受为清晰模块边界付出的初期过度工程化，不因抽象数量或只有一个实现就否定接口；新增或保留结构须能解释其职责及可读性、隔离或演进收益。
+
+| 维度 | 检查重点 |
+| --- | --- |
+| Codex 可读性 | 业务入口、命名、模块职责及接口契约是否清晰；调用与数据流是否容易追踪，是否依赖过多跨文件跳转、隐式注册或隐藏状态才能理解行为。 |
+| 循环依赖 | 核实模块及包之间的实际依赖闭环，给出路径和每条边的代码依据；区分运行时、类型或构建依赖及其影响。动态注册、反射等无法确认时说明限制，不凭目录或名称判定。 |
+| 复杂度 | 嵌套、状态组合、间接调用、职责混杂及修改扩散是否增加理解和验证成本；指标只作为线索，不用固定阈值直接判坏。 |
+| 架构健康度 | 业务职责是否模块化，同一业务规则是否有清晰归属；跨模块调用方是否仅感知公开接口而非内部实现，是否高内聚、低耦合。区分合理编排、公共能力复用与规则散落，不要求把整个业务链路塞进一个模块；通用架构能力不绑定具体业务。 |
+| 逻辑分叉 | 同一业务规则是否有重复实现、行为漂移或新旧路径并存，条件和状态组合是否难以追踪；核实业务、兼容或迁移依据，不把每个条件分支或有意差异视为缺陷。 |
+
+报告问题前核对实际可达路径、调用方保护、公开契约、有意设计及合法例外。循环依赖须展示闭环；规则重复或漂移须比较具体路径及其业务依据。合并同根因问题，区分已复现、静态确认与待核实疑点，不将假设写成事实。静态证据充分时无需强制复现，必要验证应围绕具体疑点。
+
+优化建议说明目标职责、模块归属或接口边界如何改善，并给出收益、成本、影响范围、接口或兼容性影响及验证方向；不预写详细实现，不建议无证据的全面重构。不因发现问题就暂停其余检查索要修复许可，完成报告后由用户选择是否进入 `align-plan`。
+
+## 保存报告与交付
+
+复用用户指定的外部位置或已知资产定位；已有本次计划目录则放在其中，否则用已知资产根目录。不从计划父目录猜根目录，不扫描执行资产。位置缺失时询问，同时继续只读调查；位置不可用时报告保存阻碍，不回退被审项目，不宣称已保存，也不隐去已确认问题。
+
+保存独立的 `architecture-review-YYYYMMDD-HHmmss.md`，使用用户当地检查时间，避免覆盖已有报告。顶部使用以下 YAML，未知字段留空，特殊值加引号：
+
+```yaml
+---
+系统: 系统名称
+时间: YYYY-MM-DD
+目标: 本次架构检查的模块或项目及优化目标
+---
+```
+
+正文保持紧凑，包含：
+
+1. **范围与结论**：项目、目标模块或全项目范围、检查时间、Git 基线与工作区状态；五个维度各自的结论、证据和未覆盖部分，明确用户排除项。
+2. **已确认问题与优化建议**：按影响排序，标明检查维度、证据状态、文件与最小相关行范围、具体依赖或逻辑路径、后果；给出优化方向、收益、成本、影响范围、接口及兼容性影响和验证建议。
+3. **待核实项与验证限制**：未证实的疑点、所缺证据、建议验证方式，以及本次实际命令、结果和未运行的检查。不粘贴完整日志，不虚构精确成本或健康评分。
+
+代码、命令及多行配置用带语言标记的围栏代码块，路径与标识符用行内代码，原文引用注明来源；顶部 YAML 不套代码块。无发现时表述为“在已检查范围和证据内未发现需要报告的问题”，不等于全项目无技术债。
+
+确认报告可读后，对话给重要发现、优化优先级、检查限制和文件绝对路径链接。交付报告即完成，不自动开始规划或重构。

skills/review-architecture/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false