zoom-out

zoom-out 是一条极简但精准的元指令：当你对某段代码不熟时，抽一层抽象——给我一份「相关模块 + 调用方」的地图，用项目的领域词典写。

设计思路

作者认为读不熟的代码最有效的入口不是「逐行读这一文件」，而是先把它放回所在的层级图：上游谁调它、下游它调谁、它在领域语言里扮演什么角色。这样你后续读细节时能预判每段代码服务的用户故事是什么。

核心要求

• 抽一层：不是逐行解释这个文件、也不是把所有调用栈展开，而是把「这块」放回它所在的抽象层
• map of modules and callers：列相关模块（按职责）+ 调用方（谁会触发这块代码）
• 用领域词典：动词 / 名词必须用项目里 UBIQUITOUS_LANGUAGE.md 或同等术语来源——不要用泛化的"the service" / "the controller"，而是 "Order Fulfillment Pipeline"、"Invoice Generator" 这样具体的名字

工作流（隐含）

① 在你想问的代码 / 文件 / 区域上调用 zoom-out；② agent 读领域词典或推断领域术语；③ 给出一张 map：{ this module: 干什么 } / { 上游 caller: 在什么 user story 里触发 } / { 下游 callee: 它依赖什么 }；④ 你据此决定要不要继续深入读细节、读哪一支。

适合的场景

• 接手不熟的仓库 / 模块时第一次开火
• 别人把一个 issue 抛给你时，先 zoom-out 看 blast radius
• 写 PRD / refactor RFC 之前先把「上下游」摸清楚

何时不要用

• 已经熟悉这块：再 zoom-out 是浪费
• 想要逐行深读：本技能反方向——它故意不下钻

配套

ubiquitous-language（领域词典是 zoom-out 的语言基础）、grill-with-docs（基于 docs 把领域术语锚定）、request-refactor-plan / to-prd（zoom-out 的天然下游：先抽象再写计划）、systematic-debugging（debug 前的同款"先抽象后下钻"思路）。