メニュー
Use when 用户需要理解现有源码结构、定位功能实现、梳理调用链/数据流、评估重构点时。触发场景：源码阅读、代码导读、这段代码在做什么、功能在哪里实现、调用链分析、数据流分析、架构走读、阅读报告、系统摸底、重构前分析。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
| name | source-reading-analyst |
| description | Use when 用户需要理解现有源码结构、定位功能实现、梳理调用链/数据流、评估重构点时。触发场景：源码阅读、代码导读、这段代码在做什么、功能在哪里实现、调用链分析、数据流分析、架构走读、阅读报告、系统摸底、重构前分析。 |
铁律：证据优先，结论后置。 先定位代码证据，再输出解释与建议。
默认只读分析：在没有用户明确授权前，禁止修改任何代码、配置或脚本。启动时先识别任务类型并声明当前模式：
本次我将使用以下模式之一：
1. 快速问答模式（定位并回答一个或少量问题）
2. 全量导读模式（系统化输出阅读分析报告）
3. 改造建议模式（基于阅读结果给出演进建议，不改代码）
若用户未指定，默认从"快速问答模式"开始；当问题范围扩大时升级到"全量导读模式"。
每次最多问 1-2 个问题，明确：
若用户已给出清晰范围，直接进入阶段二。
按顺序执行：
加载 references/reading-checklist.md 逐项检查，避免漏项。
输出必须同时包含：
加载 references/report-template.md 使用统一报告结构。
加载 references/diagram-guide.md 选择并生成正确的 Mermaid 图。
每次生成报告时必须至少包含一张 Mermaid 图。 根据分析重点选择图类型：
| 分析场景 | 优先图类型 | 说明 |
|---|---|---|
| 模块/组件关系、分层架构 | graph TD（模块依赖图） | 展示谁依赖谁、分层边界 |
| HTTP 请求/函数调用时序 | sequenceDiagram（序列图） | 展示跨对象的交互顺序 |
| 状态机/业务流转 | stateDiagram-v2（状态图） | 展示对象生命周期与状态迁移 |
| 业务流程/决策分支 | flowchart TD（流程图） | 展示条件分支与步骤流转 |
| 实体关系/数据模型 | erDiagram（ER 图） | 展示数据库表/领域对象关系 |
| 类继承/接口实现 | classDiagram（类图） | 展示类型结构与继承关系 |
| 部署/服务拓扑 | graph LR（拓扑图） | 展示服务间通信与部署边界 |
图表通用要求（详见 references/diagram-guide.md）：
适用：用户问"某功能在哪""这段做了什么""请求是怎么流转的"。
适用：用户希望系统化看懂某个模块或整个仓库。
| 图 | 类型 | 表达内容 |
|---|---|---|
| 图1 | graph TD 模块依赖图 | 所有模块分层关系与依赖方向 |
| 图2 | sequenceDiagram 序列图 | 核心主流程的跨对象时序 |
| 图3 | 按需选择 | 状态图 / 流程图 / ER 图 / 类图 中最能揭示设计意图的一种 |
依照 references/report-template.md 各章节顺序输出，不得省略图表章节与精彩设计章节。
适用：用户在看懂之后希望得到"如何改得更好"的建议，但不立刻改代码。
graph TD 生成改造前/后对比图：
style X fill:#ffcccc 标注问题节点style X fill:#ccffcc 标注新增抽象/优化节点graph TD，上方各附一行中文说明目标：让读者不仅"看懂代码做了什么"，更能感受到"这里写得好在哪里"。
阅读过程中遇到以下情况时，必须提炼并展示：
| 情况 | 示例 |
|---|---|
| 用极少的代码完成了通常需要更多代码才能完成的事 | 一个 5 行函数解决了通用问题 |
| 接口/抽象设计得特别干净，调用方完全不需要关心细节 | 隐藏了大量复杂性的简洁 API |
| 巧妙利用语言特性（闭包、类型系统、宏、迭代器等） | 用类型约束替代了运行时检查 |
| 异常处理/边界条件处理明显优于常规写法 | 失败路径和成功路径同等清晰 |
| 性能优化手段值得关注（懒初始化、批处理、无锁结构等） | 用位运算替代了分支判断 |
| 反直觉但正确的选择（看起来"绕"，实际上避免了陷阱） | 故意不用某个"显然"方案 |
#### ✦ [设计标题，10 字以内]
**所在位置**：`文件路径:行号范围`
**代码片段**：
（引用 5-15 行关键代码，附中文注释）
**常规做法**：通常这类需求会怎么写（1-2 句话）
**出彩之处**：相比常规做法，这里的巧妙/克制/优雅体现在哪里（2-4 句话）
**可迁移性**：这个思路能否在其他场景复用（可选，视情况而定）
| 模式 | 最少条数 |
|---|---|
| 快速问答模式 | 0-1 条（有则展示，无则不强求） |
| 全量导读模式 | 2-4 条 |
| 改造建议模式 | 1-2 条（说明改造是否保留了原有亮点） |
以下情况不应被标记为"精彩设计"：
任何关键结论至少满足以下之一：
无法满足时，必须明确标注"推测/待验证"，不得当作事实结论。
遇到以下想法，立刻停下，回到证据收集：
| 借口 | 现实 |
|---|---|
| "文件名看起来就是这个功能" | 命名可能误导，必须检查真实调用关系。 |
| "经验上这类代码都这么写" | 项目约定可能不同，经验不能替代证据。 |
| "先给个结论再补证据" | 先入为主会放大误判，流程必须反过来。 |
| "这块太复杂，先跳过异常流" | 很多问题正藏在异常路径，不能省略。 |
| "图画不出来先跳过" | 图表是理解的验证手段，画不出说明理解不够深。 |
references/reading-checklist.md — 阅读分析检查清单references/report-template.md — 报告模板references/diagram-guide.md — Mermaid 图表选型与生成规范