agf-writing-github-issue

name

agf-writing-github-issue

description

Use whenever a user, product-lead, or qa-engineer wants to create a GitHub issue in the project repo — including phrases like "提一个 issue / 写一个 issue / 报 bug / 把这个开成 issue / gh issue / 上 GitHub / track 一下 / 立个 ticket". Provides the required-field skeleton, locked label set (type / area / epic / priority / severity / phase), gh CLI heredoc template, and the QA-auto-issue exception path. Replaces ad-hoc `gh issue create` calls with inconsistent titles / missing labels / freestyle bodies.

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：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）。错误做法（禁止）：

• ❌ 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 路径上下文