holistic

全局视图

全面、多层次地展示一段代码、某项功能或一项计划如何融入更广泛的系统。此技能从系统层面而非实现层面开展分析。

流程

1. 了解项目背景

阅读现有领域文档，为分析提供依据：

1. docs/CONTEXT_MAP.md — 限界上下文及其关系
2. docs/UBIQUITOUS_LANGUAGE.md — 规范术语
3. docs/contexts/*/CONTEXT.md — 各上下文的归属与契约
4. CLAUDE.md — 项目级背景

如果这些文件不存在，则通过探索代码库逐步了解整体情况。

2. 确定分析焦点

明确用户想要了解什么。可能包括：

• 某个具体文件、模块或包
• 某项功能或能力
• 一项计划中的变更或新功能
• 某个 Bug 或意外行为
• 用户不确定的某个概念或术语

3. 绘制上下文关系图

针对分析焦点，绘制一张多层关系图：

第 1 层：领域定位

• 它属于哪个限界上下文？
• 它实现了哪些领域概念？
• 它在该上下文中的角色是什么？（核心逻辑、基础设施、界面/UI、契约/边界）

第 2 层：数据流

• 哪些数据流入此组件？（上游依赖）
• 哪些数据流出？（下游使用方）
• 它参与了哪些共享内核或契约？
• 从源头到目标，追踪完整的请求/数据路径

第 3 层：跨上下文影响

• 它涉及哪些其他限界上下文？
• 耦合点有哪些？（共享表、事件、API、window 全局变量）
• 如果此处出错，其他哪些部分会受影响？（影响范围）
• 如果此处变更，其他哪些部分也需要变更？（变更传播）

第 4 层：时间视角

• 它与近期变更有何关联？（查看 git log）
• 是否有计划中的变更会影响它？（查看规格说明和未解决的问题）
• 这一区域是否稳定，还是正在积极演进？
• 是否存在已知的技术债务或未解决的问题？（查看 CONTEXT.md 中的开放问题）

4. 提炼洞察

完成关系梳理后，重点说明：

• 隐藏依赖 — 仅从导入关系中不易看出的耦合（例如，共享 ClickHouse 表、window 全局变量、基于约定的契约）
• 系统性风险 — 单点故障、未经测试的边界、过时的假设
• 改进机会 — 当前结构造成不必要阻碍的地方，或只需小改动就能带来显著积极影响的地方
• 文档缺失 — 如果此次探索发现 CONTEXT.md、UBIQUITOUS_LANGUAGE.md 或 CONTEXT_MAP.md 存在内容缺漏，请指出应补充的内容

5. 呈现关系图

按以下结构组织输出：

## [Focal Point Name]

### Domain Position
[Which context, what role, what concepts]

### Data Flow
[Upstream → This → Downstream, with specific contracts]

### Cross-Context Impact
[What it touches beyond its own context, blast radius]

### Key Insights
[Hidden dependencies, risks, opportunities]

### Recommended Reading
[Specific files or docs to read for deeper understanding]

保持简洁。目标是帮助读者快速了解情况，而非编写详尽文档。

何时使用此技能

• “我不熟悉这部分代码” → 梳理模块及其调用方
• “如果我修改 X，会影响什么？” → 追踪影响范围
• “功能 Y 端到端究竟如何运作？” → 追踪数据流
• “代码库中的哪个位置实现了这个概念？” → 对应到限界上下文及其归属
• “我准备开始一项重大变更，有什么需要注意？” → 全面梳理整体情况

相关技能

• /domain — 根据领域模型对计划进行压力测试（更深入、交互式）
• /architect — 找出阻碍并设计更好的接口（指导性）
• /spec — 了解整体情况后，将计划正式化