| name | 507-issue |
| description | 创建和维护 GitHub issue 的生命周期。可先在对话中草拟，或以 investigation（调查态）开远程 issue；通过 explore、research、prototype 与 grill 补充事实和决策后，在同一 issue 原位升级为 ready（执行态），作为可被 AI 或协作者领取的执行合同。每个远程状态都按仓库规范设置并核验标签与负责人，除非权限不足。Use when user mentions 写 issue, 开 issue, 草拟 issue, 调查工单, 执行工单, 更新 issue, 转成执行工单, 上传 issue, bug 转 issue, gap 转 issue, GitHub issue, ticket. |
GitHub Issue（issue）
把一个需要追踪的问题放进同一条可演进的 issue 生命周期：
draft（对话草稿） → investigation（调查态） → ready（执行态） → 执行 / 验收
issue 可以在事实尚未完全清楚时先建立载体，但只有进入 ready 后才是可直接领取的执行合同。调查结果通过评论保留证据轨迹，当前正文持续更新为最新状态，不复制出平行工单。
三种状态
draft：对话草稿
- 尚未远程创建；
- 用于和用户讲清当前问题、已知、未知、建议状态与元数据；
- 可继续调用
507-explore 或 507-grill 后重写；
- 不伪造 issue 编号、URL、标签或负责人。
investigation：调查态
- 适合现象已值得追踪，但原因、方向、范围或验收仍需证据的问题；
- 正文必须写清现象、影响、当前证据、未知、调查问题、下一证据动作和升级条件；
- 可以被认领调查，但不能被包装成“照此实现”的执行合同；
- 调查证据、测试结果、原型 verdict 和用户决策追加为评论，同时回写正文中的当前结论。
ready：执行态
- 事实前提和用户决策已经充分；
- 正文包含目标行为、范围、不做、依赖、验收与验证；
- 可被 AI 或协作者直接领取执行，不依赖原聊天；
- 从调查态升级时保留同一 issue 编号和历史评论，并同步状态标签或项目字段。
核心纪律
- 状态必须显式：草稿和每个远程 issue 都声明当前状态，不让“待调查”正文伪装成可执行工单。
- 调查与执行共用一个载体：默认原位升级，不因结论变化另开一条重复 issue；只有调查发现多个可独立验证的结果时才按垂直切片拆分。
- 正文是当前真相，评论是证据历史：测试输出、调查过程和讨论证据进评论；最新问题定义、结论、范围与验收回写正文。
- 只把用户决策交给用户：项目事实由
507-explore，外部事实由 507-research，低成本可观察假设由 507-prototype，产品意图与风险取舍由 507-grill。
- ready 即执行合同：必须自足、耐久、按行为写、可独立验收；不把文件路径、行号和内部实现步骤当合同。
- 垂直切片：执行态 issue 是一条窄但完整的端到端结果，不按 schema/API/UI/测试水平拆。
- 远程元数据始终必填：无论调查态还是执行态，每个远程 issue 都按仓库现有规范设置并核验合适的 labels（标签）与 assignees（负责人 / 拥有者）。只有当前账号缺少权限时才允许未落地，并必须报告真实错误和待补内容。
调查态模板
## 状态
`investigation` — 当前用于收集事实，尚不可直接领取实施。
## 现象与影响
- 实际发生了什么：...
- 为什么值得追踪：...
- 复现路径 / 来源：...
## 当前证据
- 已确认：...
- 证据锚点：...
## 未知与调查问题
1. ...
## 下一证据动作
- <读取、测试、research 或 prototype；写目的，不写猜测结论>
## 升级为执行态的条件
- [ ] 原因或约束已确认
- [ ] 用户拥有的取舍已由 grill 确认
- [ ] 范围与验收可写成唯一解释
## 远程元数据
- labels: <仓库已有的最小合适集合>
- assignees: <按仓库 ownership；无约定时当前登录用户>
- metadata_status: complete / permission_blocked
执行态模板
## 状态
`ready` — 可直接领取执行。
## 背景与目标
- problem: ...
- goal: ...
## 当前状态与已确认决策
- ...
## 范围
### includes
- ...
### excludes
- ...
## 关系与依赖
- depends_on: ...
- blocks / related: ...
## 验收与验证
- [ ] <可独立判定的行为标准>
- verification: <公开接缝、用户路径或项目既有检查>
## 远程元数据
- labels: <仓库已有的最小合适集合>
- assignees: <按仓库 ownership；无约定时当前登录用户>
- metadata_status: complete / permission_blocked
生命周期工作流
- 读取仓库
AGENTS.md、贡献规范、issue 模板、现有标签、ownership 与少量同类 issue。
- 判断当前应停在
draft、创建 investigation，还是直接创建 ready；在对话中说明判断依据。
- 草拟正文并做状态对应的自检；用户已授权远程创建且工具/权限可用时上传。
- 创建或更新远程 issue 时设置标签和负责人；创建后读取远程状态核验。
- 调查态按下一证据动作推进：把详细证据写评论，把当前结论和未知回写正文。
- 满足升级条件后，把同一 issue 改写为执行态模板，更新状态标签/字段并再次核验元数据。
- 执行完成后由项目既有流程验收和关闭；本 skill 不代替实现。
远程元数据
- 用仓库实际规则和
gh label list 选择已有标签，不套用固定词表，不未经授权创建新标签。
- 按 ownership 或分派约定选择负责人；没有约定时用
gh api user 确认当前登录用户，用户明确指定时以指定为准。
- 创建后用
gh issue view <number> --json labels,assignees 核验；状态变化后再次核验状态标签或项目字段。
- 找不到合适标签时，在创建前报告标签体系缺口；只有仓库规则或用户授权时才创建标签。
- 权限失败时保留已经创建的 issue，报告 URL、真实权限错误、待补标签和负责人，并标记
permission_blocked；不得声称已收口。
自检
- 状态与正文成熟度一致；调查态没有假装可执行，执行态没有遗留
TODO、TBD 或“方向待定”。
- 不读原聊天也能理解现象/目标、当前状态、范围、未知或验收。
- 调查问题能由具体证据动作回答；执行态每条验收都可独立判定。
- 标题、正文、评论结论、标签、负责人和状态字段没有互相冲突。
- 多个独立结果已按垂直切片拆分，依赖使用真实编号。
完成与接力
- 完成信号：草稿已明确下一状态，或远程 issue 已创建/更新且状态、正文、标签、负责人完成核验；权限阻塞时有完整待补清单。
- 产物：对话草稿或同一条持续演进的 GitHub issue，以及调查评论形成的证据历史。
- 候选出口：调查态进入
507-explore、507-research、507-prototype 或 507-grill 后回写；执行态进入相应实施入口；完成后进入 507-review 和项目验收；只要求记录时可停在已标明状态的 issue。
- 回退条件：ready 阶段发现事实或用户决策仍未定时，降回 investigation 并说明原因，不继续伪装成执行合同。
红线
- 不为调查和执行默认创建两条重复 issue；
- 不把未验证猜测写成 ready 的方向或验收；
- 不把 issue 写成逐文件实施步骤；
- 不跳过标签、负责人和远程核验；
- 不因缺权限自行修改仓库权限或伪造完成。
