agf-writing-github-issue

Writing a GitHub Issue

Use this skill when any of the following:

• 用户说 "写 issue / 提一个 issue / 报 bug / 上 GitHub / track 一下 / 立个 ticket"
• product-lead 把 PRD 里的 AC 拆成可分派的 issue
• dev 在 SIT 自跑中发现 P0 / P1 缺陷（特殊路径，见下）
• qa-engineer 在 E2E / UAT 中发现 P0 / P1 问题（特殊路径，见下）
• 主 Claude / 任意 agent 准备调用 gh issue create

拼 body / 写命令前必读 [references/templates-and-examples.md](./references/templates-and-examples.md)：Body 模板（feature + bug 增补段）、gh CLI HEREDOC 正确写法、3 个完整例子（feature / bug / dev SIT 自动路径，含 RolexOps 实例需替换为本项目实际值）。

最小输入模式（用户授权 / 2026-05-13）

默认行为：用户只给"关键信息"，agent 智能补全其他字段，直接 gh issue create，不走草稿 gate。

用户必须给的最少信息

| 信息 | 说明 | |---|---| | 要解决什么 / 想做什么 | 一两句话描述问题或功能想法，bug / feature / chore 可推断 |

就这一条——其他字段都由 agent 推断 + 补全。

Agent 必须自动补全的字段

| 字段 | 推断规则 | |---|---| | Title | 按用户描述拟动宾结构 + type prefix feat(...) / fix(...) / chore(...) / docs(...)，≤70 char | | Why / 背景 | 从用户原话扩写 1-2 段；若有相关 PRD / ADR / 历史 issue，主动 grep docs/prd/ docs/adr/ 并 cite | | AC | 按 feature/bug 套模板生成 2-4 条可验证条件；bug 必含 "修复后用什么验证" | | type label | 按关键词判 feat（新功能）/ bug（修缺陷）/ chore（重构/构建/文档）/ adr（架构决策） | | area label | grep 用户描述关键词：frontend/React/UI/组件 → area:frontend；API/endpoint/后端/数据库/migration → area:backend；LLM/prompt/豆包/Qwen/embedding → area:ai；docker/compose/caddy/redis → area:infra | | priority | bug 默认 P1（核心流程影响）；feature 默认 P2（用户说"急/紧急/blocking"→ P1）；data loss / 安全 / 线上挂 → P0 | | severity（bug 专用） | 与 priority 同步：P0/P1 | | epic 关联 | grep 当前 branch 名（release/v1.6.0 etc.）+ 最近 commit + docs/prd/，能锁定 Epic N 才加；不确定不加，宁缺勿乱 | | phase | 默认不加；除非用户在 SIT/E2E/UAT 上下文中报问题 | | 复现步骤（bug 专用） | 用户没给则合理推测填，末尾标 <!-- TODO 用户补充实际复现 step --> | | 环境（bug 专用） | grep docker compose ps 拿当前 image / commit hash，前端 bug 默认填 "Chrome 最新版（用户未指定）" | | 关联 (Refs) | 主动 grep 关联 PRD / ADR / 现有 issue（gh issue list -L 10 关键词）；找到的填，找不到填 N/A |

兜底问号（只在以下情况问用户）

1. priority 真拿不准 P0/P1/P2 — 如用户说"挺重要"，bug 但没说阻塞与否
2. area 完全猜不出 — 描述太抽象（"那个东西坏了"）
3. 是 bug 还是 feature 真分不清 — 如"X 行为不太对，是不是应该 Y"

非这三种 → 不要问，直接补全 + 创建（事后用户在 GitHub 上 edit 比中途问还快）。

自动 issue 路径（已授权，跳过用户确认）

路径 A — dev 在 SIT 中发现 P0 / P1（SIT 由 dev 自跑）：

1. 直接 gh issue create（不需问用户、不需 product-lead 同意）
2. --label "type:bug,priority:P0,severity:P0,phase:sit"（或对应 P1）
3. 创建后通过 SendMessage 向 product-lead 报告 issue 号
4. P2 问题不开 issue，只在 progress/<role>.md 的 **SIT 证据** 段记 fail/blocked

路径 B — qa-engineer 在 E2E / UAT 中发现 P0 / P1：

1. 直接 gh issue create
2. --label "type:bug,priority:P0,severity:P0,phase:e2e"（或 phase:uat）
3. 创建后通过 SendMessage 向 product-lead 报告 issue 号
4. P2 问题不开 issue，只记录在 E2E / UAT 报告里

来源：用户 2026-05-13 授权；SIT 归 dev，QA 仅覆盖 E2E / UAT。

优先级判定

| 级别 | 适用场景 | |---|---| | P0 | 线上阻塞 / 数据损坏 / 安全漏洞 / UAT-block regression | | P1 | 核心流程影响 / UX regression / 性能 SLA 超标但非阻塞 | | P2 | 次要 / 体验优化 / nice-to-have |

判不准时 → 偏保守降一级（P0→P1），勿默认拔高。

本仓锁定 label 集合（不要自创）

gh label list 已固化的 label，只能从下面选（新需求要新 label → 先停下问用户，不要直接 gh label create）：

type:feat | type:bug | type:chore | type:adr
area:frontend | area:backend | area:ai | area:infra
epic:1 | epic:2 | epic:3 | epic:4 | epic:5 | epic:6
epic:7 | epic:8 | epic:9 | epic:10 | epic:11 | epic:12
phase:design | phase:dev | phase:review | phase:sit | phase:e2e | phase:uat
priority:P0 | priority:P1 | priority:P2
severity:P0 | severity:P1
status:blocked | status:needs-info | status:wontfix
release:vX.Y   # release 关联标签，按项目实际 milestone 替换（模板无固定值）

gh CLI 写法红线

正确写法 = HEREDOC --body "$(cat <<'EOF' ... EOF)"（完整模板见 [references/templates-and-examples.md](./references/templates-and-examples.md)）。错误做法（禁止）：

• ❌ gh issue create --body "..." 含换行 / 反引号 / 中文引号 —— shell 转义噩梦
• ❌ --label "P0" —— 不带 priority: 前缀
• ❌ gh label create 自创新 label —— 必须先问用户

执行流程（最小输入模式）

1. 接收「关键信息」→ 按上文"Agent 必须自动补全的字段"表推断 title / type / area / priority / severity + grep epic / refs，按 type 套 body 模板（见 references）。
2. 命中"兜底问号"三类才简短问一句（且只问那一个不确定字段），否则跳过。
3. HEREDOC 拼 body + 锁定 label → gh issue create（直接执行）→ 报告 URL + label 清单 →（QA 路径）SendMessage product-lead 报 issue #。

验证 gate（issue 创建后）

每次 gh issue create 成功后，最后一条 user-facing 消息必须包含：

• ✅ Issue URL（gh 命令的 stdout 第一行）
• ✅ 已贴的 label 清单
• ✅（若 QA 路径）已发给 product-lead 的 SendMessage 确认

让用户能立刻点链接 + 确认分类对不对。

Anti-patterns

| 反模式 | 为什么不行 | |---|---| | Title 用句号结尾 / 含特殊字符 | gh search / 看板列表不易扫读 | | AC 写 "正常工作" / "符合预期" | 不可验证 → code-reviewer / qa-engineer 没法逐条核 | | Body 大段无结构 | 后续被分派的 dev 找不到关键信息 | | 不标 priority | 看板按 priority 排序 / 触发不了 P0 通知机制 | | 既不标 type 也不标 area | 责任田不清 → 没人接 | | Mock / fake 描述 | 禁 mock 描述，issue 必须真实场景 |

Related skills

• agf-writing-prd — issue 通常源于 PRD AC，反向链回 PRD 路径
• agf-writing-adr — 涉及架构变更时先开 ADR，再开 issue 引用
• agf-running-sit-tests（dev-owned SIT）/ agf-writing-qa-report（E2E/UAT 报告，SIT 不在范围内） — QA 与 dev SIT 路径上下文