用途：在开始任何需要理解功能实现与用户需求的文档任务前，先对 Dify 功能做写前调研。它把代码库分析与社区反馈结合，产出有依据的调研记录，本身不写文档。
主要能力：分两个阶段并行执行。阶段一为代码库调查，按检测表判断功能归属 dify 还是 graphon，读取后端实现（节点类、_run()、实体定义、模板与流式逻辑）、前端 UI（面板组件、类型、默认值与校验）、i18n 标签、功能开关与环境默认值、API 表面及插件 SDK，并执行覆盖门禁，逐面记录已读文件或 N/A 原因。阶段二为社区反馈，通过 gh issue list、gh search issues、gh api 检索 GitHub Issues 与 Discussions，将发现归类为文档缺口、困惑、Bug、功能请求。阶段三综合成结构化调研记录，含工作原理、表面覆盖表、现有文档、社区痛点与建议文档范围。
使用方式：支持 full 与 targeted 两种深度。从 dify-docs-write 管道调用时，消费其 S1 提供的功能、ref 与目标页面，不重复询问；独立使用时先询问功能、ref（默认 main）与目标页面，再运行完整深度。需定位 dify 与 graphon 工作目录，按 writing-guides/index.md 安全同步代码，并用 grep '"graphon' api/pyproject.toml 解析 graphon 固定版本，在该 tag 而非 main 上验证行为。
适用场景：为 Dify 功能文档撰写或优化做前置调研，尤其涉及工作流节点、图引擎、运行时、模型运行时等跨仓库功能。
限制：仅产出调研，需用户审阅并确认范围后才进入写作；代码推断行为须标记为未验证并请用户测试；须区分 Bug 与文档缺口，不把 Bug 行为写成预期功能；UI 可发现的机制按风格指南过滤，除非特别关键；graphon main 行为可能不存在于用户实际版本，研究前需询问用户。