github-create-issue

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 项；不足时先提问：

1. 问题现象（当前行为）
2. 期望行为
3. 触发入口/操作步骤
4. 影响范围（用户、页面、接口、环境）
5. 相关文件或模块线索（可选）

执行流程

Step 0: Preflight（gh 上下文）

创建 issue 前必须先确认：

1. gh --version
2. gh auth status
3. gh repo view --json nameWithOwner,viewerPermission

若失败，先输出修复建议再停止建单流程。

Step 1: 问题建模

先把用户描述重写为“可验证假设”，格式如下：

• 假设 H1：...
• 影响对象：...
• 判定标准：满足什么现象才算问题成立

Step 2: 代码查验

按最小必要范围定位证据：

1. 用语义搜索/关键词搜索定位相关模块
2. 读取关键实现并记录证据（文件、函数、关键条件）
3. 必要时运行最小验证（已有测试、最小复现命令）
4. 得出查验结果：
   • 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 严重度必须一致。
• 任何“拿不准”的地方都先向用户提问并记录反馈。