depth-check

depth-check

将“深入到当前工作所需的程度”落到实处：给定一项任务，判断实际需要达到什么程度，再减去用户已经掌握的部分。输出的是一份简短、诚实的准备清单，而不是对整个代码库的长篇讲解。

任务的每个部分都不需要深入理解。修改逻辑需要建立工作模型；调用接口需要了解其契约；相邻代码则只需知道它的存在。评估这一点是此技能的核心：要求过深和要求不足同样都是失败。

步骤

1. 明确任务

实际要改什么？如果用户的描述含糊，先结合代码具体化（“修复同步 bug” → 具体是哪条同步路径，大致涉及哪些模块）。

2. 梳理影响范围

根据任务规模，找出：

• 修改会直接涉及的文件／模块
• 它们的调用方——谁会调用它们，谁依赖它们的行为
• 相关不变量：周边代码所依赖的假设、协议／顺序约束，以及注释或断言警示的问题
• 覆盖该区域的测试（测试是否存在及其形式能说明哪些行为至关重要）

3. 评估各部分所需的理解深度

针对影响范围内的每个部分，确定工作所需的程度：

• 工作模型 — 你将修改其逻辑：必须能够预测边界情况下的行为
• 契约 — 你将调用它或依赖它：必须了解其接口、保证和失败模式
• 了解 — 它位于附近：必须知道它的存在，以及何时会与任务相关

4. 减去用户已经掌握的内容

按可靠性排序的信号：

• 如果用户在使用此技能包的会话循环，就查看其档案和日志——可以信任这些信息，但要标出可能已被近期提交过时的条目。
• 用户在相关区域的提交历史：git log --author=<user email from git config> --oneline -- <path>。用户编写或近期修改过的代码，很可能已经了解；从未碰过的代码则很可能不了解。
• 如果以上都无法得出结论，直接询问——一个简短的确认问题（“你以前处理过重试层吗？”）胜过错误假设。

5. 输出准备清单

列出两份简短清单：

• 你已掌握 — 用户已掌握的程度足以满足要求的区域。这些不需要做任何功课。
• 先了解 — 每项都应是编码前需要回答的具体问题，而不是要学习的主题：“这里如何保证写入有序？”胜过“了解写入路径”。指出最快的解答方式——要阅读的具体文件、要运行的测试，或用 why 深入了解相关决策的历史。

如果清单完全为空，用一行说明即可，不要多此一举——任务属于已知领域，无需繁文缛节。

对于使用会话循环的用户：准备后仍未解答的问题值得记入日志，以便下次访问时再次浮现。其他用户无需此步骤。

约束

• 准备清单必须能在几分钟到一小时内完成，而不是一套阅读计划。如果超过约 5 项，任务可能太大——应明确指出。
• 双向都要诚实评估：任务只是调用某段代码时，不要要求建立其工作模型；修改逻辑时，也不要用契约层面的了解敷衍过去。
• 只读：此技能负责调查并汇报；不会更改目标项目中的任何内容。