| 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 |
兜底问号（只在以下情况问用户）
- priority 真拿不准 P0/P1/P2 — 如用户说"挺重要"，bug 但没说阻塞与否
- area 完全猜不出 — 描述太抽象（"那个东西坏了"）
- 是 bug 还是 feature 真分不清 — 如"X 行为不太对，是不是应该 Y"
非这三种 → 不要问，直接补全 + 创建（事后用户在 GitHub 上 edit 比中途问还快）。
自动 issue 路径（已授权，跳过用户确认）
路径 A — dev 在 SIT 中发现 P0 / P1（SIT 由 dev 自跑）：
- 直接
gh issue create（不需问用户、不需 product-lead 同意）
--label "type:bug,priority:P0,severity:P0,phase:sit"（或对应 P1）- 创建后通过 SendMessage 向 product-lead 报告 issue 号
- P2 问题不开 issue，只在
progress/<role>.md 的 **SIT 证据** 段记 fail/blocked
路径 B — qa-engineer 在 E2E / UAT 中发现 P0 / P1：
- 直接
gh issue create
--label "type:bug,priority:P0,severity:P0,phase:e2e"（或 phase:uat）- 创建后通过 SendMessage 向 product-lead 报告 issue 号
- 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 —— 必须先问用户
执行流程（最小输入模式）
- 接收「关键信息」→ 按上文"Agent 必须自动补全的字段"表推断 title / type / area / priority / severity + grep epic / refs，按 type 套 body 模板（见 references）。
- 命中"兜底问号"三类才简短问一句（且只问那一个不确定字段），否则跳过。
- 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 路径上下文
