| name | issue-research |
| description | 在实现计划前执行显式调研:阅读 Issue 上下文与代码库现状,整理受影响模块、 约束、风险和待确认点,输出到 .issue-flow/research-notes.md。 |
| disable-model-invocation | false |
| allowed-tools | ["Read","Write","Glob","Grep","Bash(cat *)","Bash(gh issue view *)"] |
Issue Research
在 issue-pick 与 issue-plan 之间执行显式调研,避免在不了解代码现状时直接产出计划。
执行步骤
1. 前置检查
- 检查当前目录是否存在
.issue-flow/issue.json
- 若不存在,向父目录逐级查找(最多到 git 仓库根目录)
- 若仍未找到,停止并提示:"未找到 .issue-flow/issue.json,请先通过
/issue-flow #<编号> 初始化上下文"
2. 读取上下文
- 读取
.issue-flow/issue.json
- 运行
gh issue view <N> --comments,提取:
3. 调研代码库现状
围绕 Issue 描述中的模块、术语和路径,使用 Glob、Grep、Read 检查:
- 现有实现入口在哪里
- 哪些文件最可能受影响
- 已有模式或先例是什么
- 是否存在明显风险、缺口或不一致
如果仓库中已经有与该需求相关的文档、设计稿或计划,也应纳入调研结果。
4. 产出 research notes
使用 Write 将结果写入 .issue-flow/research-notes.md:
# Research Notes
## Issue Summary
- 目标:
- 验收标准:
- 约束:
## Current Codebase Findings
- 相关模块:
- 关键文件:
- 现有模式:
## Risks
- 风险 1:
## Open Questions
- 问题 1:
## Planning Guidance
- 后续计划应优先关注:
5. 输出
输出:
- 关键发现摘要
- 主要受影响文件
- 风险与待确认点
- 提示:"已生成
.issue-flow/research-notes.md,可通过 /issue-flow 继续进入计划阶段"
规则
issue-research 只负责理解现状,不直接实现代码
- 不编造代码库中不存在的结构或约束
- research notes 必须来源于 Issue 内容和实际代码阅读结果
- 若发现 Issue 与代码现状冲突,应明确写入风险或待确认点,而不是自行假设