Night Market 技能 — 从 claude-night-market/pensive 移植而来。如需获得包含智能体（agents）、钩子（hooks）和命令的完整体验，请安装 Claude Code 插件。

目录

• 快速开始
• 适用场景
• 渐进式加载
• 必需的 TodoWrite 条目
• 工作流
• 步骤 1：建立上下文（arch-review:context-established）
• 步骤 2：ADR 审计（arch-review:adr-audit）
• 步骤 3：交互映射（arch-review:interaction-mapping）
• 步骤 4：原则检查（arch-review:principle-checks）
• 步骤 5：风险与行动项（arch-review:risks-actions）
• 测试

测试

运行 pytest plugins/pensive/tests/skills/test_architecture_review.py 以验证评审逻辑。

• 架构原则检查清单
• 耦合度（Coupling）
• 内聚性（Cohesion）
• 分层结构（Layering）
• 可演进性（Evolution）

架构评审工作流

基于 ADR 及设计原则开展的架构评估。

快速开始

/architecture-review

适用场景

• 审批重构实现方案。
• 大规模重构评审。
• 系统设计变更。
• 新模块或新服务引入。
• 依赖关系重构。

不适用场景

• 架构范式选型 — 请使用 archetypes 技能
• API 表面（surface）评审 — 请使用 api-review
• 架构范式选型 — 请使用 archetypes 技能
• API 表面（surface）评审 — 请使用 api-review

渐进式加载

根据评审范围按需加载模块：

• modules/adr-audit.md（约 400 tokens）：ADR 验证与文档审查。
• modules/coupling-analysis.md（约 450 tokens）：依赖分析与边界违规检测。
• modules/principle-checks.md（约 500 tokens）：代码质量、安全性和性能检查。
• modules/fpf-methodology.md（约 800 tokens）：FPF（Functional, Practical, Foundation）多视角评审方法论。

执行完整评审时加载全部模块；执行聚焦评审时仅加载相关模块。

必需的 TodoWrite 条目

1. arch-review:context-established：仓库、分支、评审动因。
2. arch-review:adr-audit：ADR 验证及新增 ADR 需求。
3. arch-review:interaction-mapping：模块耦合度分析。
4. arch-review:invariant-check：不变量冲突检测及三选一分析。
5. arch-review:principle-checks：LoD（迪米特法则）、安全性、性能。
6. arch-review:risks-actions：建议结论与后续行动项。

工作流

步骤 1：建立上下文（arch-review:context-established）

确认当前仓库与分支：

pwd
git status -sb

需记录以下内容：

• 触发本次评审的功能需求、缺陷或史诗任务（epic）。
• 受影响的子系统。
• README 或文档中描述的架构意图。
• 设计权衡假设。

步骤 2：ADR 审计（arch-review:adr-audit）

加载模块：modules/adr-audit.md

• 定位项目中的所有 ADR。
• 验证各 ADR 是否包含必需章节。
• 检查 ADR 状态流转是否合规。
• 确认是否符合不可变性（immutability）要求。
• 标记需新增的 ADR。

步骤 3：交互映射（arch-review:interaction-mapping）

加载模块：modules/coupling-analysis.md

• 绘制变更前/后的模块交互图。
• 验证组合边界是否合理。
• 检查数据所有权是否清晰明确。
• 验证依赖流向是否符合预期方向。
• 识别耦合违规点。

步骤 3.5：不变量冲突检测（arch-review:invariant-check）

在开展原则检查前，须首先识别变更是否与现有设计不变量发生冲突。这是架构评审中判断难度最高的一环——模型在此类决策上的出错率高于其他任何环节。

识别现有不变量：

1. 扫描所有状态为“accepted”的 ADR，提取其中仍生效的设计决策
2. 检查模块边界（例如：导入是否跨过此前未跨越的层级？）
3. 检查数据流向（例如：数据是否开始沿新方向流动？）
4. 检查 API 合约（例如：公开接口的形状是否发生变化？）
5. 检查结构模式（例如：是否在已有模式旁引入了新模式？）

# 在变更文件中检测边界跨越行为
git diff --name-only | while read f; do
  head -20 "$f" 2>/dev/null | rg "^(import|from|use |require)" || true
done

当检测到冲突时：

请勿直接推荐解决方案。应列出以下三种选项，并将决策权上交至人工判断：

输出格式：

### 不变量冲突

[I1] **[不变量名称]** — [其所代表的设计决策]
- **冲突点**: [具体哪项变更与此冲突]
- **可选方案**: 保留 / 叠加 / 修订
- **建议操作**: ESCALATE TO HUMAN
- **误判风险**: [若判断错误将导致何种恶化]

为何重要：错误的不变量决策具有强复利效应。几次误判后，代码库将彻底不可维护。这是一个典型的判断力问题，而非上下文理解问题——智能体的任务是揭示问题，而非自行解决。

步骤 4：原则检查（arch-review:principle-checks）

加载模块：modules/principle-checks.md

• 迪米特法则（Law of Demeter）。
• 反冗余（anti-slop）模式。
• 安全性（输入校验、最小权限原则）。
• 性能（N+1 查询、缓存策略）。

步骤 5：风险与行动项（arch-review:risks-actions）

使用 imbue:diff-analysis/modules/risk-assessment-framework 进行总结：

• 当前架构 vs 提议架构。
• 业务影响评估。
• 技术债务影响分析。

列出各项后续行动项，明确负责人与截止日期。

给出最终评审建议：

• 批准：架构设计合理。
• 有条件批准：存在少量需修复的问题。
• 驳回：存在根本性问题，需重新设计。

架构原则检查清单

耦合度（Coupling）

• 依赖关系遵循明确定义的边界。
• 无循环依赖。
• 扩展点使用恰当。
• 抽象未发生泄漏（abstractions don't leak）。

内聚性（Cohesion）

• 相关功能被合理归组。
• 每个模块职责单一。
• 模块用途清晰明确。

分层结构（Layering）

• 各层级职责划分清晰。
• 依赖关系单向向下流动。
• 无跨层直连（layer bypassing）。

不变量（Invariants）

• 已识别出既有设计不变量。
• 已显式揭示变更与不变量之间的冲突。
• 已提供三选一分析（保留 / 叠加 / 修订）。
• 不变量相关变更已提交人工判断。
• 差异（diff）中未出现静默的不变量修改。

可演进性（Evolution）

• 变更具备可逆性。
• 迁移路径清晰明确。
• ADR 已对关键决策进行记录。