القائمة
Use when 用户需要理解现有源码结构、定位功能实现、梳理调用链/数据流、评估重构点时。触发场景：源码阅读、代码导读、这段代码在做什么、功能在哪里实现、调用链分析、数据流分析、架构走读、阅读报告、系统摸底、重构前分析。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/ProgrammerAnthony/Expert-Coding-Harness --skill source-reading-analystيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| 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 图表选型与生成规范