507 Issue

GitHub Issue（issue）

把一个需要追踪的问题放进同一条可演进的 issue 生命周期：

draft（对话草稿） → investigation（调查态） → ready（执行态） → 执行 / 验收

issue 可以在事实尚未完全清楚时先建立载体，但只有进入 ready 后才是可直接领取的执行合同。调查结果通过评论保留证据轨迹，当前正文持续更新为最新状态，不复制出平行工单。

三种状态

draft：对话草稿

• 尚未远程创建；
• 用于和用户讲清当前问题、已知、未知、建议状态与元数据；
• 可继续调用 507-explore 或 507-grill 后重写；
• 不伪造 issue 编号、URL、标签或负责人。

investigation：调查态

• 适合现象已值得追踪，但原因、方向、范围或验收仍需证据的问题；
• 正文必须写清现象、影响、当前证据、未知、调查问题、下一证据动作和升级条件；
• 可以被认领调查，但不能被包装成“照此实现”的执行合同；
• 调查证据、测试结果、原型 verdict 和用户决策追加为评论，同时回写正文中的当前结论。

ready：执行态

• 事实前提和用户决策已经充分；
• 正文包含目标行为、范围、不做、依赖、验收与验证；
• 可被 AI 或协作者直接领取执行，不依赖原聊天；
• 从调查态升级时保留同一 issue 编号和历史评论，并同步状态标签或项目字段。

核心纪律

1. 状态必须显式：草稿和每个远程 issue 都声明当前状态，不让“待调查”正文伪装成可执行工单。
2. 调查与执行共用一个载体：默认原位升级，不因结论变化另开一条重复 issue；只有调查发现多个可独立验证的结果时才按垂直切片拆分。
3. 正文是当前真相，评论是证据历史：测试输出、调查过程和讨论证据进评论；最新问题定义、结论、范围与验收回写正文。
4. 只把用户决策交给用户：项目事实由 507-explore，外部事实由 507-research，低成本可观察假设由 507-prototype，产品意图与风险取舍由 507-grill。
5. ready 即执行合同：必须自足、耐久、按行为写、可独立验收；不把文件路径、行号和内部实现步骤当合同。
6. 垂直切片：执行态 issue 是一条窄但完整的端到端结果，不按 schema/API/UI/测试水平拆。
7. 远程元数据始终必填：无论调查态还是执行态，每个远程 issue 都按仓库现有规范设置并核验合适的 labels（标签）与 assignees（负责人 / 拥有者）。只有当前账号缺少权限时才允许未落地，并必须报告真实错误和待补内容。

调查态模板

## 状态
`investigation` — 当前用于收集事实，尚不可直接领取实施。

## 现象与影响
- 实际发生了什么：...
- 为什么值得追踪：...
- 复现路径 / 来源：...

## 当前证据
- 已确认：...
- 证据锚点：...

## 未知与调查问题
1. ...

## 下一证据动作
- 

## 升级为执行态的条件
- [ ] 原因或约束已确认
- [ ] 用户拥有的取舍已由 grill 确认
- [ ] 范围与验收可写成唯一解释

## 远程元数据
- labels: 
- assignees: 
- metadata_status: complete / permission_blocked

执行态模板

## 状态
`ready` — 可直接领取执行。

## 背景与目标
- problem: ...
- goal: ...

## 当前状态与已确认决策
- ...

## 范围
### includes
- ...
### excludes
- ...

## 关系与依赖
- depends_on: ...
- blocks / related: ...

## 验收与验证
- [ ] 
- verification: 

## 远程元数据
- labels: 
- assignees: 
- metadata_status: complete / permission_blocked

生命周期工作流

1. 读取仓库 AGENTS.md、贡献规范、issue 模板、现有标签、ownership 与少量同类 issue。
2. 判断当前应停在 draft、创建 investigation，还是直接创建 ready；在对话中说明判断依据。
3. 草拟正文并做状态对应的自检；用户已授权远程创建且工具/权限可用时上传。
4. 创建或更新远程 issue 时设置标签和负责人；创建后读取远程状态核验。
5. 调查态按下一证据动作推进：把详细证据写评论，把当前结论和未知回写正文。
6. 满足升级条件后，把同一 issue 改写为执行态模板，更新状态标签/字段并再次核验元数据。
7. 执行完成后由项目既有流程验收和关闭；本 skill 不代替实现。

远程元数据

• 用仓库实际规则和 gh label list 选择已有标签，不套用固定词表，不未经授权创建新标签。
• 按 ownership 或分派约定选择负责人；没有约定时用 gh api user 确认当前登录用户，用户明确指定时以指定为准。
• 创建后用 gh issue view --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 写成逐文件实施步骤；
• 不跳过标签、负责人和远程核验；
• 不因缺权限自行修改仓库权限或伪造完成。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ssdiwu
• Source: ssdiwu/507-skills
• License: MIT

Install and usage instructions live in the source repository linked above.