| name | github.create-issue |
| description | 先查验代码再创建 GitHub Issue。只要用户提出“先确认是不是问题再提 issue”“根据代码排查并建单”“把用户反馈转成 issue”这类请求，就必须启用本技能：先验证问题是否成立，证据不足时主动追问用户补充，再用 gh CLI 按模板创建 issue。 |
Create Issue (Code-Verified)
目标
把“用户口头问题”转成“有证据、可执行、可追踪”的 GitHub issue。
本技能不做“听到问题就直接建单”，而是按以下原则执行：
- 先查验：先验证问题是否真实存在，再决定是否创建 issue。
- 证据优先：结论必须有代码路径、行为描述或复现实验支持。
- 先问后建：信息不足时主动向用户追问，拿到反馈后再继续。
- 一因一单：不同根因拆成多个 issue，避免把不相关问题混在一起。
触发条件
出现以下任一语义时立即使用本技能：
- “帮我确认是不是 bug，并提 issue”
- “先排查代码，再创建 issue”
- “这个问题到底是不是问题，确认后建单”
- “根据我给的现象去代码里核查，然后提 GitHub issue”
- “查验过程需要和我确认细节再建单”
如果用户只要求纯 issue 运维（如关单、打标签、批量改 assignee），应切换到 gh.issue。
输入要求
至少收集到以下信息中的 3 项；不足时先提问：
- 问题现象（当前行为）
- 期望行为
- 触发入口/操作步骤
- 影响范围（用户、页面、接口、环境）
- 相关文件或模块线索（可选）
执行流程
Step 0: Preflight（gh 上下文）
创建 issue 前必须先确认：
gh --versiongh auth statusgh repo view --json nameWithOwner,viewerPermission
若失败，先输出修复建议再停止建单流程。
Step 1: 问题建模
先把用户描述重写为“可验证假设”，格式如下：
- 假设 H1：...
- 影响对象：...
- 判定标准：满足什么现象才算问题成立
Step 2: 代码查验
按最小必要范围定位证据：
- 用语义搜索/关键词搜索定位相关模块
- 读取关键实现并记录证据（文件、函数、关键条件）
- 必要时运行最小验证（已有测试、最小复现命令）
- 得出查验结果：
confirmed：问题成立rejected：不成立（属于预期行为或误解）needs-info：证据不足
Step 3: 反馈澄清回合（必须支持）
当结果为 needs-info 或存在关键歧义时，向用户发起定向提问。
提问要求：
- 一次最多 3 个问题
- 每个问题都要说明“为什么需要这个信息”
- 优先问能直接改变结论的信息（环境、复现步骤、输入样例、预期规则）
可用追问模板：
我还缺 2 条信息才能确认是否建单：
1) 你触发问题时的具体操作步骤（为什么问：用于确认复现路径）
2) 你期望的正确结果（为什么问：用于判断当前行为是否真的是 bug）
拿到用户反馈后，回到 Step 1/2 继续查验。
Step 4: 建单判定
仅在以下条件同时满足时创建 issue：
- 至少有一条高置信证据支持问题成立
- 问题描述可复现或可验证
- 影响范围与预期行为可表达清楚
否则输出“暂不建单 + 缺失信息列表 + 下一步建议”。
Step 5: 按模板生成 issue（参考 review.prd）
issue 正文必须使用以下模板（字段名保持一致）：
## 1) 总体结论
- `可方案化状态`: 可直接修复 / 有条件修复 / 暂不可修复
- `一句话结论`: ...
- `问题等级`: P0 / P1 / P2 / P3 / P4
- `置信度`: 高 / 中 / 低
## 2) 问题详情（证据表）
| ID | 严重度 | 问题类型 | 问题描述 | 用户证据 | 代码证据 | 影响范围 | 需确认问题 |
| ---- | ------ | ------------------------------ | -------- | -------- | -------- | -------- | ---------- |
| P1-1 | P1 | 规则歧义/流程缺口/实现缺陷/... | ... | ... | ... | ... | ... |
## 3) 复现步骤
1. ...
2. ...
3. ...
## 4) 预期行为
- ...
## 5) 最小补充信息集（MCI）
- `缺失信息`:
- `为什么必须补`:
- `建议由谁给出`:
## 6) 建议修复方向
- ...
## 7) 验收标准
- [ ] Given ... When ... Then ...
- [ ] Given ... When ... Then ...
这套结构来自 review.prd 的“结论 + 问题表 + MCI”思路，确保 issue 具备可执行性和可追踪性。
Step 6: 创建 GitHub issue
- 标题格式：
[create-issue][P?][category] <short summary>
- category 建议：
bug / logic / data / performance / security
- 默认标签建议：
bug、create-issue、P0~P4（三选一）
推荐命令：
gh issue create --repo owner/repo --title "[create-issue][P1][bug] short summary" --body-file /tmp/create-issue-body.md --label bug --label create-issue --label P1
若标签不存在，不阻塞创建；在最终回执里标注“标签缺失”。
最终输出格式
执行完成后，用以下结构向用户回执：
- Repo:
owner/repo
- 查验结论:
confirmed/rejected/needs-info
- 关键证据: 2~4 条（含代码路径或复现依据）
- 用户反馈采纳: 列出本轮用户补充了哪些关键信息
- Issue 结果:
- 已创建：
#123 title - url
- 未创建：说明原因与缺失信息
- 下一步建议: 1 条最可执行动作
质量门槛
- 不得在
needs-info 状态下强行建单。
- 不得用模糊描述替代证据。
- 不得把多个独立问题塞进同一个 issue。
- 结论与 issue 严重度必须一致。
- 任何“拿不准”的地方都先向用户提问并记录反馈。
