メニュー
调研技能，用于对代码仓库、书籍、概念等进行系统化调研，产出知识图谱文档（MD给AI看，HTML可视化给人看）。支持多轮迭代填充，用户引导式信息来源确认，动态调整细致程度。触发场景：用户说调研、研究、知识图谱、分析XX、学习XX、帮我了解XX。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
为 AI Agent 创建元规则和领域知识，帮助用户在不熟悉领域建立 Agent 的思考方式和行为准则。专注于抽象的行事风格而非具体技术约束。适用场景：(1) 创建新 Agent 缺少行为准则，(2) 更新现有 Agent 的元规则或知识，(3) 用户不熟悉目标领域需要搜索最佳实践，(4) 希望 Agent 跨项目保持一致工作风格。
记录 AI 犯错或可改进点，生成可复用的学习资产。支持两种模式：(1) 当前会话 - 会话结束时触发，引导用户回顾本次会话中的纠正和可改进点；(2) 指定会话 - 通过 session_id 或 JSONL 文件路径分析历史会话。存储位置：D:\desktop\quackDocs\my_notes\ai_mistake\（index.md 索引 + records.md 实体）。触发词：记录错误、记录问题、AI 错误记录、会话总结、记录教训、record mistakes。
记录 AI 犯错或可改进点，生成可复用的学习资产。支持两种模式：(1) 当前会话 - 会话结束时触发，引导用户回顾本次会话中的纠正和可改进点；(2) 指定会话 - 通过 session_id 或 JSONL 文件路径分析历史会话。存储位置：D:\desktop\quackDocs\my_notes\ai_bug_history\（index.md 索引 + records.md 实体）。触发词：记录错误、记录问题、AI 错误记录、会话总结、记录教训、record mistakes。
指导 Manager 设计和创建 Loop 循环。当 Manager 需要创建自动化循环（如 Executor-Reviewer、Writer-Editor 模式）时使用。 提供完整的设计流程：需求澄清 → 节点设计 → 用户确认 → Subagent 验证 → 创建循环。 确保循环提示词质量，避免因上下文设计不当导致循环失败。 触发词：创建循环、loop、循环设计、迭代执行、自动审查。
记录架构决策（ADR）。触发条件：(1) 艰难选择——在方案间纠结、选了A但B也有优势、知道有副作用 (2) 重构/重大修改后——改了3+次才定方案、每次改有新考虑 (3) 奇怪代码——被问"为什么这样写"、审查被质疑、自己回看也觉得奇怪 (4) 用户做出重大决策或出现决策疑问
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
| name | knowledge-research |
| description | 调研技能，用于对代码仓库、书籍、概念等进行系统化调研，产出知识图谱文档（MD给AI看，HTML可视化给人看）。支持多轮迭代填充，用户引导式信息来源确认，动态调整细致程度。触发场景：用户说调研、研究、知识图谱、分析XX、学习XX、帮我了解XX。 |
系统化调研技能，产出双文档：
核心流程：用户引导 → 产出知识框架 → 概念解释审查 → 多轮迭代填充
用户触发调研请求
↓
第一步：确认研究对象和信息来源
↓
第二步：确认输出目录、调研详细程度和初步兴趣点
↓
第三步：评估调研复杂度，选择执行模式
├─ 单Agent模式（简单调研）
└─ 多Agent模式（复杂调研）
├─ 并行调研模式（大型仓库）
├─ 专业化模式（多维度分析）
└─ 上下文保护模式（内容量大）
↓
第四步：执行调研，产出知识框架（主体）
├─ 4.1 概念识别与解释
├─ 4.2 结构分析
└─ 4.4 概念解释审查（多轮迭代）
↓
第五步：生成文档
├─ 5.1 生成MD文档
├─ 5.2 生成HTML可视化
└─ 5.3 寓言解释增强（可选）
↓
第六步：多轮迭代循环
├─ 展示当前图谱
├─ 询问"想深入哪个部分？"
├─ 用户提问 → 判断落入哪一层 → 填充
└─ 更新MD和HTML，直到用户满意
询问用户：
类型选项：
根据类型确认信息来源：
| 类型 | 信息来源确认 |
|---|---|
| 本地代码仓库 | 确认路径，不需要网络搜索 |
| GitHub仓库 | 确认URL，可能需要clone |
| 书籍/文档 | 确认是否需要网络搜索补充信息 |
| 概念/技术 | 确认是否需要网络搜索获取最新信息 |
关键：如果用户已提供完整信息（如本地路径），跳过此步。
询问用户：
注意：如果用户在触发时已指定输出目录，跳过此步。
询问用户想要什么等级的调研报告：
| 等级 | 描述 | 内容深度 | 适用场景 |
|---|---|---|---|
| 简略 | 快速概览 | 核心概念、主要结构、关键要点 | 快速了解、初步探索 |
| 适中 | 标准调研 | 详细结构、核心要素、基本关系 | 日常学习、项目了解 |
| 详细 | 深度分析 | 全面分析、多维关系、深入思考 | 深度研究、教学材料 |
询问示例：
注意：详细程度会影响后续调研的深度和广度。
询问用户：
注意：兴趣点会影响第一轮调研的侧重点。
根据调研对象的特征，判断使用单Agent还是多Agent模式。
| 条件 | 推荐模式 | 原因 |
|---|---|---|
| 大型仓库，有多个独立模块 | 并行调研模式 | 模块间独立，可并行提高效率 |
| 需要多维度深度分析（架构+流程+实现） | 专业化模式 | 不同维度需要不同专业视角 |
| 调研对象内容量 > 1000 tokens | 上下文保护模式 | 避免主Agent上下文污染 |
| 小型调研对象，内容量少 | 单Agent模式 | 多agent协调开销大于收益 |
| 顺序依赖强，后续依赖前面结果 | 单Agent模式 | 并行会降低质量 |
| 简单概念调研 | 单Agent模式 | 过度设计 |
适用场景：大型代码仓库，有多个相对独立的模块
执行流程：
主Agent：分析仓库结构，识别独立模块
↓
分派多个SubAgent并行调研：
├── SubAgent1：调研backend模块
├── SubAgent2：调研frontend模块
├── SubAgent3：调研tools/utils模块
└── SubAgent4：调研配置和部署
↓
主Agent：汇总各SubAgent结果
↓
生成统一的知识框架
SubAgent职责：
协调要点：
适用场景：需要从多个维度深入分析（如架构、工作流、消息机制）
执行流程：
主Agent：识别调研维度
↓
分派专业SubAgent：
├── SubAgent1（架构专家）：分析系统架构和设计模式
├── SubAgent2（流程专家）：分析工作流和消息流
├── SubAgent3（代码专家）：分析核心代码实现
└── SubAgent4（搜索专家）：网络搜索补充信息
↓
主Agent：整合各维度结果，形成完整图谱
SubAgent职责：
协调要点：
适用场景：调研对象内容量大（> 1000 tokens），需要保护主Agent上下文
执行流程：
主Agent：判断调研对象大小
↓
如果内容量大：
分派SubAgent处理具体内容
SubAgent返回摘要（50-100 tokens）
↓
主Agent：基于摘要生成知识框架
SubAgent职责：
协调要点：
适用场景：简单调研，内容量小，不需要多维度分析
执行流程：
主Agent：直接读取和分析调研对象
↓
产出知识框架
适用条件：
根据研究对象类型和选择的执行模式，分析并产出知识框架（主体）。
关键原则：先解释"是什么"，再解释"怎么用"和"关系"。
在分析结构之前，先识别并解释所有核心概念：
必须解释的概念：
解释格式：
### [类名/概念名]
**定义**：[是什么 - 类型、性质]
**职责**：[做什么 - 核心功能]
**关键字段**：
- `field1: Type` - [含义说明]
- `field2: Type` - [含义说明]
读取项目结构，分析：
产出：
## 知识框架（主体）
### 1. 定位
- 属于什么领域/范畴
- 解决什么问题
- 核心价值是什么
### 2. 核心概念解释
{先解释所有核心概念 - 类、接口、关键变量的定义和含义}
### 3. 结构
| 模块/目录 | 职责 | 关键文件 |
|-----------|------|----------|
| module1 | 职责描述 | file1.py, file2.py |
### 4. 核心要素
{每个模块的核心要素，引用已解释的概念}
在分析结构之前，先识别并解释：
必须解释的内容：
解释格式：
### [关键词/概念]
**定义**：[清晰的定义]
**重要性**：[为什么重要]
**示例**：[具体例子帮助理解]
读取目录或内容，分析：
产出：
## 知识框架（主体）
### 1. 定位
- 属于什么领域/范畴
- 解决什么问题
- 核心价值是什么
### 2. 核心概念解释
{先解释所有关键词、关键句、核心概念}
### 3. 结构
| 章节 | 主题 | 核心概念 |
|------|------|----------|
| 第1章 | 主题描述 | 概念1, 概念2 |
### 4. 核心要素
{每个章节的核心要素，引用已解释的概念}
通过搜索或已有知识，分析：
产出：
## 知识框架（主体）
### 1. 定位
- 属于什么领域/范畴
- 解决什么问题
- 核心价值是什么
### 2. 核心概念解释
{清晰定义每个概念，包括技术术语的解释}
### 3. 结构
| 概念 | 定义 | 关键特征 |
|------|------|----------|
| 概念1 | 定义描述 | 特征1, 特征2 |
### 4. 核心要素
{每个概念的核心要素}
关键步骤：在生成知识框架后，必须进行概念解释审查。
使用 concept-explanation-review.md 中的审查 prompt，派遣 SubAgent 审查知识框架。
SubAgent 任务：
生成初版知识框架
↓
派遣审查 SubAgent
↓
审查通过？
├─ 是 → 进入 Step 5
└─ 否 → 根据审查报告补充概念解释
↓
重新生成知识框架
↓
再次派遣审查 SubAgent
↓
重复直到通过（最多 3 轮）
审查通过标准：
如果 3 轮后仍未通过：
按照 knowledge-graph-structure.md 的模板生成MD文档。
文件命名：{主题}-知识图谱.md
使用 template.html 模板，按照 html-style-guide.md 的样式指南生成HTML。
文件命名：{主题}-知识图谱.html
关键：HTML必须包含Mermaid图表，可视化展示结构和关系。
目的：通过寓言故事让复杂的技术概念更易理解。
在生成 MD 和 HTML 文档后，派遣寓言创作 SubAgent 审查知识图谱，识别适合用寓言解释的核心机制或概念。
使用 fable-creation-guide.md 中的寓言创作 prompt，派遣 SubAgent 创作寓言。
SubAgent 任务：
SubAgent 创作完寓言后，将寓言插入到知识图谱文档的适当位置：
插入位置：
插入方式：
数量控制：
向用户展示当前知识图谱的概要：
询问用户：
根据用户问题，判断落入哪一层：
| 问题类型 | 落入层次 | 示例问题 |
|---|---|---|
| "XX是什么？" | 知识框架 | "DeerFlow是什么？" |
| "XX的结构是什么？" | 知识框架 | "DeerFlow的架构是什么？" |
| "XX和YY有什么关系？" | 关系层 | "DeerFlow和LangGraph有什么关系？" |
| "XX怎么用？" | 思考层（应用视角） | "DeerFlow怎么用？" |
| "为什么这样设计？" | 思考层（设计视角） | "为什么DeerFlow这样设计？" |
| "深入讲讲XX" | 主题锚点 | "深入讲讲DeerFlow的消息机制" |
根据归类结果，填充到相应层次：
当用户明确表示满意时结束：