用途：解释某段代码为何存在，把代码与其背后的 AI 编程会话关联起来。适合用户提问“为什么会有这段代码”“当初为什么这么写”时使用。
主要能力：调用 why_did_this_change 工具，用 target 参数指定查询目标。文件形式如 src/cache.ts；具体行如 src/cache.ts:142（通过 git blame 定位提交）；提交形式为 sha、tag 或 HEAD~2；主题形式为自由文本（只在该仓库搜索会话，不走 git）。工具为只读，从不写入仓库。
证据解读：结果包含解析出的提交（主题、作者时间、文件、trailers；自由文本形式为 null）与排序后的会话。置信度上，files+time 匹配（会话在其时间窗口内编辑了该提交涉及的文件）强于 time-only 匹配（同一仓库同一窗口但无文件重叠）。commit.merge: true 表示这是落地改动的合并提交，而非撰写该改动的提交，推理存在于会话中而非合并标题；非空的 unlandedAttempts（仅文件形式）表示有会话改动过该文件但从未落地提交，可能是被放弃的尝试。
使用方式：根据各会话的摘要与标题综合出简短答案，解释推理与任何被放弃的方案；不要编造摘要未支持的动机。引用所用会话时标注其工具、日期（startedAt）与标题，并区分 files+time 与 time-only 匹配。若问题涉及“是否已修复”，不要只依赖 git 历史，可在存在 GitHub 远端且可用 gh 时运行 gh search prs --state closed -- <terms>（或 gh pr list --search "<file>" --state closed），并连同已合并修复一并报告已关闭未合并的尝试；无 gh 或 GitHub 远端时静默跳过。用户需要更多细节时，可用会话的 filePath 调用 get_session_messages（以 excerpts[].msgIndex 作为 offset）读取完整交流。
限制：空会话本身即一种答案，应直接说没有会话可关联，而非猜测。time-only 匹配是弱信号，应表述为“大约同一时间”，不能当作因果。存在 trailers（如 Co-Authored-By）时应呈现以标注作者归属。回答先给原因再给引用，除非用户要求更多，一般保持几句话。