gh-issue-writer

根据简要描述、错误信息或初步想法，自动生成清晰、可操作的 GitHub Issue。支持 Bug 报告、功能请求（Feature Request）、改进项（Enhancement）和任务（Task）等类型。

第 1 步 — 理解输入

主动询问（或从上下文中推断）以下信息：

1. Issue 类型是什么？ Bug｜Feature Request｜Enhancement｜Task｜Question
2. 目标仓库（repo）是哪个？（若当前目录为 Git 仓库，则通过 git remote get-url origin 自动检测；否则需向用户确认）
3. 发生了什么 / 希望实现什么？（原始描述、错误信息或想法本身）
4. 可选字段：Labels、Assignee、Milestone、环境详情等

若用户已提供足够上下文，可跳过提问，直接生成草稿并提交确认。

第 2 步 — 撰写 Issue 草稿

选用下方对应模板，并完整填写所有字段；仅当某节内容确无相关信息时方可省略。

Bug 报告

## 描述


## 复现步骤
1.
2.
3.

## 预期行为


## 实际行为


## 运行环境
- OS：
- 浏览器 / 运行时 / 版本：
- 相关配置或依赖：

## 日志 / 截图


## 补充信息

功能请求（Feature Request）

## 问题 / 动机


## 提议方案


## 已考虑的替代方案


## 接受标准（Acceptance Criteria）
- [ ]
- [ ]

## 补充信息

改进项（Enhancement：对现有行为的优化）

## 当前行为


## 期望行为


## 此改进的意义


## 建议实现方式

任务 / 杂务（Task / Chore）

## 待办事项


## 原因 / 上下文


## 完成定义（Definition of Done）
- [ ]
- [ ]

第 3 步 — 拟定有力的标题

按 Issue 类型采用不同标题格式：

标题规范：

• 长度不超过 72 个字符
• 避免模糊用语（如 “fix thing”、“update stuff”）
• 需具体：包含“什么 + 在哪里”，而不仅是“什么”

第 4 步 — 推荐标签（Labels）与元数据

依据 Issue 类型与内容推荐标签：

同时建议：

• Assignee：该代码模块的负责人是谁？
• Milestone：目标发布版本或冲刺周期（sprint）是哪一个？

第 5 步 — 提交审核

展示完整草稿：

**标题：**