cmd-gh-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create GitHub Issue from Conversation

从对话创建GitHub Issue

Create a well-structured GitHub issue using

gh

CLI, populated with context from the current conversation.

使用

gh

CLI创建结构规范的GitHub issue，内容会自动填充当前对话的上下文。

Instructions

使用说明

Determine the repo -- confirm you're inside a git repo with a GitHub remote:
bash
```
gh repo view --json nameWithOwner -q '.nameWithOwner'
```
If this fails, ask the user which repo to file against.
Synthesize the conversation into a GitHub issue body following the structure below.

Create the issue using

gh

bash

gh issue create --title "<concise title>" --body "$(cat <<'ISSUE_EOF'
<issue body here>
ISSUE_EOF
)"

Report back with the issue URL.

确定目标仓库 -- 确认你当前处于绑定了GitHub远程仓库的git仓库中：
bash
```
gh repo view --json nameWithOwner -q '.nameWithOwner'
```
如果执行失败，询问用户需要提交issue的目标仓库。
整合对话内容，按照下方结构整理成GitHub issue正文。

使用
gh
创建issue：

bash

gh issue create --title "<concise title>" --body "$(cat <<'ISSUE_EOF'
<issue body here>
ISSUE_EOF
)"

返回结果，附上新创建的issue链接。

Issue Body Structure

Issue正文结构

Build the issue body in this exact order:

严格按照以下顺序构建issue正文：

Section 1: What & Why

第一部分：需求内容与背景

Open with a short (2-4 bullet) summary answering:

What needs to happen?
Why does it matter? (user pain, system constraint, business goal)

This section should stand alone -- a reader who stops here should understand the ask.

开头用2-4条简短要点回答以下问题：

需要完成什么内容？
为什么要做这件事？（用户痛点、系统限制、业务目标）

该部分可独立阅读，仅查看这部分的用户也能完全理解需求。

Section 2: Context & Discussion

第二部分：上下文与讨论详情

This is the bulk of the issue. Capture everything relevant from our conversation:

Background -- what led to this discussion
Current behavior -- how things work today (or don't)
Desired behavior -- what success looks like
Constraints & decisions -- trade-offs we discussed, options we rejected and why
Technical details -- relevant code paths, configs, schemas, API shapes, error messages
Related work -- links to PRs, issues, docs, or external references mentioned

Formatting rules for this section:

Use
```
## Headings
```
and
```
### Subheadings
```
to organize by topic
Use bullet points over paragraphs
Use markdown tables for comparisons, option matrices, or structured data
Embed images/screenshots if any were shared (use
```
![alt](url)
```
syntax)
Wrap code snippets, commands, file paths, and config in fenced code blocks with language tags
Use
```
<details><summary>...</summary>...</details>
```
to collapse verbose content (logs, full configs, large code blocks) so the issue stays scannable
Do NOT strip context -- preserve the substance of our discussion, but reorganize it logically

这是issue的主体部分，记录对话中所有相关内容：

背景：本次讨论的触发原因
当前表现：现有功能的运行情况（或存在的问题）
期望表现：最终要达成的效果
限制与决策：我们讨论过的取舍、否决的方案及原因
技术细节：相关的代码路径、配置、schema、API结构、错误信息
相关工作：提到的PR、issue、文档或外部参考链接

本部分格式规则：

使用
```
## 大标题
```
和
```
### 子标题
```
按主题组织内容
优先使用要点列表而非大段段落
对比内容、选项矩阵或结构化数据使用markdown表格展示
如果有分享的图片/截图请嵌入（使用
```
![alt](url)
```
语法）
代码片段、命令、文件路径、配置内容请用带语言标记的围栏代码块包裹
冗长内容（日志、完整配置、大段代码块）使用
```
<details><summary>...</summary>...</details>
```
折叠，保证issue易读
不要删减上下文：保留我们讨论的核心内容，但可按逻辑重新组织

Section 3: Implementation Plan

第三部分：实现方案

End with the plan we've aligned on (even if rough). Frame it for a future agent or developer picking this up cold:

Number the steps
Call out key files to create or modify
Note any open questions or decisions still TBD (prefix with
```
[ ]
```
)
If there are dependencies between steps, make the order explicit

If we haven't aligned on a plan yet, write

## Implementation Plan\n\n_TBD -- no plan agreed on yet._

最后附上我们达成共识的方案（哪怕是初步方案），方便后续接手的Agent或开发者快速理解：

步骤按编号排序
标注需要创建或修改的核心文件
记录所有待确认的问题或决策（前缀加
```
[ ]
```
）
如果步骤之间有依赖，明确标注执行顺序

如果我们还没有达成共识的方案，写入

## 实现方案\n\n_TBD -- 暂未达成共识方案._

Labels & Assignment (optional)

标签与分配（可选）

If the conversation implies a category (bug, feature, enhancement, tech-debt), add
```
--label
```
flags
Do NOT assign unless the user explicitly asks

如果对话中明确了issue类别（bug、feature、enhancement、tech-debt），添加
```
--label
```
参数
除非用户明确要求，否则不要自动分配经办人

Style Rules

风格规范

Title: imperative mood, under 70 chars (e.g., "Add retry logic to webhook delivery")
No fluff: skip filler phrases like "It would be great if..." -- be direct
Bias to structure: headers > paragraphs, bullets > prose, tables > lists-of-pairs
Preserve signal: don't summarize away details that a future implementer would need
Mark uncertainty: if something was discussed but not decided, say so explicitly with "TBD" or an open checkbox
```
[ ]
```

标题：使用祈使语气，字数不超过70字符（例如："Add retry logic to webhook delivery"）
无冗余内容：不要使用"如果能...就太好了"这类填充语，直接表述需求
优先结构化：标题>段落，要点>散文式描述，表格>键值对列表
保留有效信息：不要把后续实现需要的细节概括省略
标注不确定性：如果讨论过但还未确定的内容，明确标注"TBD"或者待办复选框
```
[ ]
```