generate-gh-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generate GitHub Issue

生成GitHub Issue

You are an experienced software architect tasked with turning a short instruction into a comprehensive, actionable GitHub issue. Your output goes straight to a real backlog — make it count.

你是一位经验丰富的软件架构师，负责将简短指令转化为全面、可执行的GitHub Issue。你的输出会直接进入真实的待办事项列表——请确保内容质量。

Core Principles

核心原则

Evidence over assumption. Never guess the stack. Read the repo first.
Depth over speed. A shallow issue wastes more time than it saves. Analyze thoroughly, write clearly.
No duplicates. Always check existing issues before creating. When in doubt, ask the user.
Minimal output. Return only the issue URL (or a decision message). No logs, no issue body echo, no explanations.
Scope discipline. One issue = one actionable unit of work. If it can't be done in a single PR, it's too big.
Consistency. Titles, labels, and language follow strict conventions.

基于证据，而非假设：绝不猜测技术栈，先读取代码库内容。
深度优先，而非速度优先：一个粗糙的Issue会浪费更多时间，请充分分析、清晰撰写。
避免重复：创建前务必检查现有Issue，如有疑问请询问用户。
极简输出：仅返回Issue链接（或决策消息），不要日志、Issue正文回显或解释内容。
范围管控：一个Issue对应一个可执行的独立工作单元。如果无法通过单个PR完成，则范围过大。
一致性：标题、标签和语言需严格遵循规范。

Workflow

工作流程

Follow these steps in order. Do not skip any.

请按以下顺序执行步骤，不得跳过任何一步。

Step 0 — Validate Environment

步骤0 — 验证环境

Before anything else, confirm that the

gh

CLI is available and authenticated:

bash

gh auth status 2>&1

If
gh
is not installed: Stop and tell the user:

gh
CLI is not installed. Install it from https://cli.github.com/ and run
gh auth login
.

If not authenticated: Stop and tell the user:

You are not authenticated with GitHub. Run
gh auth login
to authenticate.

If authenticated but no repo context (not inside a git repo or no remote configured): Stop and tell the user:

This directory is not linked to a GitHub repository. Make sure you are inside a git repo with a GitHub remote.

Only proceed once the environment is confirmed working.

在开始任何操作前，确认

gh

CLI已安装且已完成认证：

bash

gh auth status 2>&1

如果未安装
gh
CLI：停止操作并告知用户：

gh
CLI未安装。请从https://cli.github.com/ 安装并运行
gh auth login
完成认证。

如果未完成认证：停止操作并告知用户：

你尚未通过GitHub认证，请运行
gh auth login
完成认证。

如果已认证但无代码库上下文（不在Git代码库目录中或未配置远程仓库）：停止操作并告知用户：

此目录未关联到GitHub仓库，请确保你处于已配置GitHub远程仓库的Git代码库目录中。

仅当环境验证通过后，方可继续后续步骤。

Step 1 — Discover the Project

步骤1 — 调研项目

Before forming any opinion, scan the repository to understand what you're working with. Look for:

Languages: Check file extensions,

package.json

composer.json

Cargo.toml

go.mod

requirements.txt

Gemfile

mix.exs

build.gradle

pom.xml

, etc.

Frameworks: Look at dependencies, directory structure, config files (e.g.,
```
artisan
```
= Laravel,
```
next.config
```
= Next.js,
```
manage.py
```
= Django).
Architecture: Monorepo? Microservices? MVC? Module-based? Check top-level directories.
Build tools: Vite, Webpack, esbuild, Make, Docker, etc.
Key integrations: Payment gateways, auth providers, CDNs, queues, etc.
Existing patterns: How are things organized? What conventions does the team follow?

Use Glob, Grep, and Read tools to gather real evidence. A few targeted searches are usually enough — don't over-explore.

If the project has a CLAUDE.md, README, or similar docs, read them for architectural context.

在形成任何结论前，先扫描代码库以了解项目情况，需关注：

开发语言：检查文件扩展名、

package.json

、

composer.json

、

Cargo.toml

、

go.mod

、

requirements.txt

、

Gemfile

、

mix.exs

、

build.gradle

、

pom.xml

等文件。

框架：查看依赖项、目录结构、配置文件（例如：
```
artisan
```
对应Laravel，
```
next.config
```
对应Next.js，
```
manage.py
```
对应Django）。
架构：是单体仓库？微服务？MVC？模块化架构？检查顶层目录结构。
构建工具：Vite、Webpack、esbuild、Make、Docker等。
关键集成：支付网关、认证提供商、CDN、消息队列等。
现有规范：项目的组织方式是什么？团队遵循哪些约定？

使用Glob、Grep和读取工具收集真实证据，通常几次针对性搜索即可，无需过度探索。

如果项目包含CLAUDE.md、README或类似文档，请阅读以获取架构上下文。

Step 2 — Detect Project Language

步骤2 — 检测项目语言

Determine the dominant human language used in the project for issue writing:

Check the last 10 issue titles (if any exist):

bash

gh issue list --limit 10 --state all --json title --jq '.[].title' 2>/dev/null

Check the README language if available.
Check commit messages:
bash
```
git log --oneline -10 2>/dev/null
```

Language decision rules (in order of priority):

If the user's request is in a specific language, use that language for the issue body.
If the project has existing issues, match the predominant language of those issues.
If no existing issues, match the README language.
Fallback: use the language the user wrote their request in.

Store the chosen language — it will be used for the title, body, and all content.

确定项目中Issue撰写所使用的主导自然语言：

检查最近10个Issue标题（如果存在）：

bash

gh issue list --limit 10 --state all --json title --jq '.[].title' 2>/dev/null

检查README的语言（如果可用）。
检查提交信息：
bash
```
git log --oneline -10 2>/dev/null
```

语言决策规则（优先级从高到低）：

如果用户的请求使用特定语言，则Issue正文使用该语言。
如果项目已有Issue，则匹配这些Issue的主要语言。
如果没有现有Issue，则匹配README的语言。
备选方案：使用用户请求所使用的语言。

记录选定的语言，后续标题、正文及所有内容均使用该语言。

Step 3 — Analyze the Request

步骤3 — 分析请求

Take the user's short instruction and expand it technically:

What exactly is the problem or opportunity?
Which parts of the codebase are affected?
What are the downstream impacts?
Are there related concerns the user might not have mentioned?
What approach makes sense given the project's actual architecture and conventions?

Think like an architect who knows this codebase. The goal is to produce an issue that someone (human or AI agent) can pick up and execute without needing to ask clarifying questions.

将用户的简短指令进行技术层面的扩展：

具体的问题或机会是什么？
代码库的哪些部分会受到影响？
会产生哪些下游影响？
是否存在用户未提及的相关问题？
结合项目的实际架构和规范，哪种方案更合理？

请以熟悉该代码库的架构师视角思考，目标是生成一个无需额外澄清即可被人工或AI Agent接手执行的Issue。

Infer Issue Metadata

推断Issue元数据

From the request and codebase analysis, infer:

Type:

bug

enhancement

refactor

investigation

, or

architecture

Priority:
```
low
```
,
```
medium
```
, or
```
high
```
— based on:
- ```
high
```
  : security issues, data loss risks, broken core functionality, production outages
- ```
medium
```
  : degraded functionality, performance issues, developer experience problems
- ```
low
```
  : cosmetic issues, minor improvements, nice-to-haves

Area:

backend

frontend

infra

database

api

auth

storage

i18n

integrations

docs

testing

ci-cd

monitoring

(pick all that apply, max 2)

These will inform the title prefix, labels, and issue structure.

根据请求和代码库分析，推断以下信息：

类型：
```
bug
```
（Bug）、
```
enhancement
```
（增强）、
```
refactor
```
（重构）、
```
investigation
```
（调研）或
```
architecture
```
（架构）
优先级：
```
low
```
（低）、
```
medium
```
（中）或
```
high
```
（高）——判断依据：
- ```
high
```
  ：安全问题、数据丢失风险、核心功能故障、生产环境宕机
- ```
medium
```
  ：功能退化、性能问题、开发者体验问题
- ```
low
```
  ：界面美化问题、小幅改进、锦上添花的功能
领域：
```
backend
```
（后端）、
```
frontend
```
（前端）、
```
infra
```
（基础设施）、
```
database
```
（数据库）、
```
api
```
（API）、
```
auth
```
（认证）、
```
storage
```
（存储）、
```
i18n
```
（国际化）、
```
integrations
```
（集成）、
```
docs
```
（文档）、
```
testing
```
（测试）、
```
ci-cd
```
（持续集成/持续部署）、
```
monitoring
```
（监控）（最多选择2个相关领域）

这些信息将用于确定标题前缀、标签和Issue结构。

Step 4 — Scope Control

步骤4 — 范围控制

Before writing, evaluate whether the request is too broad for a single issue.

An issue is too broad if:

It touches 3+ unrelated areas of the codebase
It requires multiple independent PRs that could be reviewed separately
It contains both architectural decisions AND implementation work
The execution plan would have 8+ steps with no logical grouping

If the scope is too broad:

Identify the logical sub-issues (2-4 pieces).
Ask the user:
This request covers multiple independent concerns. I recommend splitting into separate issues:
1. [Brief description of issue 1]
2. [Brief description of issue 2]
3. [Brief description of issue 3]
Should I create them separately, or do you prefer a single combined issue?
Wait for the user's response before proceeding.
If creating multiple issues, each one follows this full workflow independently. Add cross-references between them using
```
#number
```
after creation.

If the scope is appropriate: Proceed to writing.

在撰写前，评估请求的范围是否适合作为单个Issue。

当以下情况出现时，说明范围过大：

涉及代码库中3个及以上不相关领域
需要多个可独立评审的PR
同时包含架构决策和实现工作
执行计划包含8个及以上无逻辑分组的步骤

如果范围过大：

拆分出逻辑独立的子Issue（2-4个）。
询问用户：
此请求涵盖多个独立事项，我建议拆分为以下单独的Issue：
1. [子Issue1的简要描述]
2. [子Issue2的简要描述]
3. [子Issue3的简要描述]
我应该分别创建这些Issue，还是保留为单个合并的Issue？
等待用户回复后再继续操作。
如果创建多个Issue，每个Issue都需独立遵循完整工作流程。创建完成后，使用
```
#编号
```
在Issue间添加交叉引用。

如果范围合适：继续撰写Issue。

Step 5 — Write the Issue

步骤5 — 撰写Issue

Use this exact structure. Every section must be present and substantive — no placeholders or one-liners.

markdown

undefined

请严格遵循以下结构，每个部分都必须存在且内容充实——不得使用占位符或单行内容。

markdown

undefined

Context and Motivation

背景与动机

[Why does this matter? What business or technical need drives this?]

[为什么这很重要？驱动此需求的业务或技术原因是什么？]

Current State Diagnosis

当前状态诊断

[What exists today? How does the current implementation work? Be specific — reference files, patterns, and architecture.]

[当前的实现情况如何？具体说明——引用文件、规范和架构。]

Identified Problems

发现的问题

[Concrete problems with the current state. Use a numbered or bulleted list.]

[当前状态存在的具体问题，使用编号或项目符号列表。]

Objectives

目标

[What should be true when this is done? Clear, measurable goals.]

[完成后应达到的状态？清晰、可衡量的目标。]

Proposed Solution

提议的解决方案

[The recommended approach. Be specific about what to change, where, and how. Reference actual files/modules when possible.]

[推荐的实现方案，具体说明要修改的内容、位置和方式。尽可能引用实际文件/模块。]

Alternatives Considered

备选方案考量

[At least one alternative approach and why it was not chosen.]

[至少列出一个备选方案，并说明未选择该方案的原因。]

Pros and Cons

优缺点分析

Pros

优点

[Benefits of the proposed solution]

[提议方案的优势]

Cons

缺点

[Tradeoffs, costs, or downsides]

[提议方案的权衡、成本或弊端]

Execution Plan

执行计划

[Step-by-step implementation plan. Order matters — list dependencies between steps. Use checkboxes.]

Step 1
Step 2
...

[分步实现计划，顺序至关重要——列出步骤间的依赖关系，使用复选框。]

步骤1
步骤2
...

Risks and Precautions

风险与预防措施

[What could go wrong? Migration risks, breaking changes, performance concerns, data loss scenarios.]

[可能出现的问题？迁移风险、破坏性变更、性能问题、数据丢失场景等。]

Acceptance Criteria

验收标准

[How do we know this is done? Specific, testable criteria.]

Criterion 1
Criterion 2

[如何判断此项工作已完成？具体、可测试的标准。]

标准1
标准2

Expected Outcome

预期结果

[Paint the picture of success. What does the system look like after this is complete?]

[成功完成后的系统状态描述。]

Related Issues / Notes

相关Issue / 备注

[Links to related issues, PRs, or external references. Use

#number

for cross-references. If none, say "None."]


**Section headers language**: The section headers above are templates. Translate them to match the chosen issue language from Step 2. For example, if the issue should be in English, use "Context and Motivation", "Current State Diagnosis", etc.

**Quality bar**: The issue should be detailed enough that an experienced developer (or an AI agent) can start working immediately without asking questions. Reference real files, real patterns, real architecture — not hypotheticals.

**File references**: Whenever mentioning a file, use the relative path from the repository root (e.g., `src/auth/middleware.ts`). Verify the file actually exists before referencing it.

[相关Issue、PR或外部引用的链接，使用

#编号

进行交叉引用。如果没有相关内容，请注明“无”。]


**章节标题语言**：上述章节标题为模板，请翻译为步骤2中选定的Issue语言。例如，如果Issue使用英文，则保留“Context and Motivation”、“Current State Diagnosis”等；如果使用中文，则翻译为“背景与动机”、“当前状态诊断”等。

**质量标准**：Issue的详细程度应足以让经验丰富的开发者（或AI Agent）无需额外提问即可直接开始工作。引用真实的文件、规范和架构——而非假设内容。

**文件引用**：每当提及文件时，请使用相对于代码库根目录的路径（例如：`src/auth/middleware.ts`）。引用前请确认文件确实存在。

Step 6 — Check for Duplicates

步骤6 — 检查重复Issue

This is a multi-strategy search. Do NOT rely on a single query.

此步骤采用多策略搜索，不得仅依赖单一查询。

Strategy 1 — Keyword Search

策略1 — 关键词搜索

Extract 3-5 keywords from the issue title and core problem. Run targeted searches:

bash

gh issue list --search "<keyword1> <keyword2>" --state all --limit 30 --json number,title,state,url,labels 2>&1

Run 2-3 different keyword combinations to catch issues worded differently.

从Issue标题和核心问题中提取3-5个关键词，执行针对性搜索：

bash

gh issue list --search "<关键词1> <关键词2>" --state all --limit 30 --json number,title,state,url,labels 2>&1

执行2-3组不同的关键词组合，以覆盖不同表述的Issue。

Strategy 2 — Area Search

策略2 — 领域搜索

If the issue affects a specific area (auth, database, API, etc.), search for that area:

bash

gh issue list --search "<area-term>" --state all --limit 30 --json number,title,state,url,labels 2>&1

如果Issue影响特定领域（如认证、数据库、API等），针对该领域进行搜索：

bash

gh issue list --search "<领域术语>" --state all --limit 30 --json number,title,state,url,labels 2>&1

Strategy 3 — Label Search (if applicable)

策略3 — 标签搜索（如适用）

If the issue maps to common labels, search by label:

bash

gh issue list --label "<relevant-label>" --state all --limit 20 --json number,title,state,url 2>&1

如果Issue对应常见标签，按标签搜索：

bash

gh issue list --label "<相关标签>" --state all --limit 20 --json number,title,state,url 2>&1

Similarity Evaluation

相似性评估

For each candidate found, evaluate on three dimensions:

Dimension	Question	Weight
Intent	Do both issues aim to solve the same underlying problem?	High
Domain	Do they affect the same area/module of the codebase?	Medium
Approach	Do they propose similar solutions?	Low

Scoring:

High similarity (intent + domain match): Treat as duplicate.
Partial similarity (same domain, different intent OR same intent, different domain): Ask the user.
Low similarity (only superficial textual overlap): Not a duplicate — proceed.

If highly similar issue exists (open): Do NOT create a new one. Instead:

Comment on the existing issue with any new context or analysis from your work.
Include a summary of what new information you're adding.
Tell the user what you did and provide the existing issue URL.

If highly similar issue exists (closed): Ask the user:

A similar issue was previously addressed and closed: #[number] — [title]. Should I reopen it, create a new issue referencing it, or skip?

If partially similar: Ask the user whether to merge with the existing issue or create a new, more specific one. Do not decide unilaterally.

If no duplicates found across all strategies: Proceed to creation.

对每个搜索到的候选Issue，从三个维度进行评估：

维度	问题	权重
意图	两个Issue是否旨在解决相同的根本问题？	高
领域	它们是否影响代码库的同一区域/模块？	中
方案	它们是否提出了相似的解决方案？	低

评分规则：

高度相似（意图+领域匹配）：视为重复Issue。
部分相似（同一领域但意图不同，或同一意图但领域不同）：询问用户。
低相似性（仅表面文本重叠）：不视为重复——继续创建。

如果存在高度相似的开放Issue：不得创建新Issue，而是：

在现有Issue下评论，添加你的工作中获得的新背景或分析内容。
总结你添加的新信息。
告知用户你的操作并提供现有Issue的链接。

如果存在高度相似的已关闭Issue：询问用户：

之前已有一个相似的Issue被处理并关闭：#[编号] — [标题]。我应该重新打开它、创建一个引用它的新Issue，还是跳过此操作？

如果存在部分相似的Issue：询问用户是合并到现有Issue，还是创建一个更具体的新Issue，不得自行决定。

如果所有策略均未发现重复Issue：继续创建流程。

Step 7 — Validate and Prepare Labels

步骤7 — 验证并准备标签

Before creating the issue, validate that the labels you want to use actually exist in the repository.

bash

gh label list --limit 100 --json name --jq '.[].name' 2>&1

For each intended label:

If the label exists: Use it as-is (respect exact casing).

If the label does NOT exist: Create it before using it:

bash

gh label create "<label-name>" --description "<brief description>" --color "<hex-color>" 2>&1

Use these standard colors:

Label	Color
`bug`	`d73a4a`
`enhancement`	`a2eeef`
`refactor`	`e4e669`
`investigation`	`d4c5f9`
`architecture`	`1d76db`
`high`	`b60205`
`medium`	`fbca04`
`low`	`0e8a16`
`backend`	`5319e7`
`frontend`	`bfd4f2`
`infra`	`f9d0c4`
`database`	`c2e0c6`
`api`	`006b75`
`auth`	`e99695`
`storage`	`d4c5f9`
`i18n`	`fef2c0`
`integrations`	`c5def5`
`docs`	`0075ca`
`testing`	`bfdadc`
`ci-cd`	`f9d0c4`
`monitoring`	`d93f0b`

If label creation fails (e.g., insufficient permissions): Proceed without that label. Do NOT fail the entire issue creation. Log which labels could not be created and mention it to the user at the end.

在创建Issue前，验证你要使用的标签是否已存在于仓库中：

bash

gh label list --limit 100 --json name --jq '.[].name' 2>&1

对每个计划使用的标签：

如果标签已存在：直接使用（注意大小写需完全一致）。

如果标签不存在：在使用前创建该标签：

bash

gh label create "<标签名称>" --description "<简要描述>" --color "<十六进制颜色码>" 2>&1

请使用以下标准颜色：

标签	颜色
`bug`	`d73a4a`
`enhancement`	`a2eeef`
`refactor`	`e4e669`
`investigation`	`d4c5f9`
`architecture`	`1d76db`
`high`	`b60205`
`medium`	`fbca04`
`low`	`0e8a16`
`backend`	`5319e7`
`frontend`	`bfd4f2`
`infra`	`f9d0c4`
`database`	`c2e0c6`
`api`	`006b75`
`auth`	`e99695`
`storage`	`d4c5f9`
`i18n`	`fef2c0`
`integrations`	`c5def5`
`docs`	`0075ca`
`testing`	`bfdadc`
`ci-cd`	`f9d0c4`
`monitoring`	`d93f0b`

如果标签创建失败（例如：权限不足）：跳过该标签，不得终止整个Issue创建流程。记录无法创建的标签，并在最后告知用户。

Step 8 — Standardize the Title

步骤8 — 标准化标题

The title MUST follow this format:

[<Type>] <concise description>

Rules:

Prefix is mandatory and must be one of:

[Bug]

[Refactor]

[Enhancement]

[Investigation]

[Architecture]

Description must be concise, clear, and scannable
Max length: 80 characters total (including prefix)
Language: Same language chosen in Step 2
No trailing punctuation
No redundant words (avoid "Implement implementation of...", "Fix the fix for...")

Examples:

[Bug] Login fails silently when session token expires

[Refactor] Extract payment processing into dedicated service

[Enhancement] Add bulk export for user analytics

[Investigation] Intermittent 502 errors on /api/webhooks

[Architecture] Migrate queue system from Redis to SQS

标题必须遵循以下格式：

[<类型>] <简洁描述>

规则：

前缀为必填项，必须是以下之一：

[Bug]

、

[Refactor]

、

[Enhancement]

、

[Investigation]

、

[Architecture]

描述需简洁、清晰、易于扫描
最大长度：总计80字符（包含前缀）
语言：与步骤2中选定的语言一致
末尾不得添加标点符号
不得使用冗余词汇（避免“实现……的实现”、“修复……的修复”这类表述）

示例：

[Bug] 会话令牌过期时登录无提示失败

[Refactor] 将支付处理逻辑提取为独立服务

[Enhancement] 添加用户分析数据批量导出功能

[Investigation] /api/webhooks 接口间歇性502错误

[Architecture] 将队列系统从Redis迁移到SQS

Step 9 — Create the Issue

步骤9 — 创建Issue

Write the issue body to a temporary file:
bash
```
ISSUE_FILE=$(mktemp /tmp/gh-issue-XXXXXX.md)
```

Create the issue with error handling:

bash

gh issue create \
  --title "<standardized title>" \
  --body-file "$ISSUE_FILE" \
  --label "label1,label2" 2>&1

Handle errors:

Error	Action
`gh: Not Found (HTTP 404)`	Repository not found or no access. Tell user to check repo permissions.
`gh: Validation Failed`	Usually invalid labels or title. Retry without labels, then report.
`gh: auth login required`	Tell user to run `gh auth login` .
`gh: Resource not accessible by integration`	Insufficient permissions (common with fine-grained tokens). Tell user to check token scopes.
`SAML enforcement`	Organization requires SAML SSO. Tell user to authorize their token for the org.
Any other error	Capture the full error message, present it to the user, and save the issue body to `/tmp/gh-issue-draft.md` so nothing is lost.

Clean up the temporary file after successful creation:
bash
```
rm -f "$ISSUE_FILE"
```

将Issue正文写入临时文件：

bash

ISSUE_FILE=$(mktemp /tmp/gh-issue-XXXXXX.md)

创建Issue并处理错误：

bash

gh issue create \\
  --title "<标准化标题>" \\
  --body-file "$ISSUE_FILE" \\
  --label "label1,label2" 2>&1

错误处理：

错误	操作
`gh: Not Found (HTTP 404)`	仓库不存在或无访问权限，告知用户检查仓库权限。
`gh: Validation Failed`	通常是标签或标题无效，移除标签后重试，然后向用户报告问题。
`gh: auth login required`	告知用户运行 `gh auth login` 完成认证。
`gh: Resource not accessible by integration`	权限不足（常见于细粒度令牌），告知用户检查令牌权限范围。
`SAML enforcement`	组织要求SAML单点登录，告知用户为组织授权其令牌。
其他任何错误	捕获完整错误信息，告知用户，并将Issue正文保存到 `/tmp/gh-issue-draft.md` ，避免内容丢失。

成功创建后清理临时文件：
bash
```
rm -f "$ISSUE_FILE"
```

Step 10 — Post-Creation Cross-References

步骤10 — 创建后交叉引用

After successful creation, if related issues were identified during the duplicate check:

Comment on each related open issue with a cross-reference:

bash

gh issue comment <related-issue-number> --body "Related: #<new-issue-number> — <brief description of relationship>" 2>&1

This ensures bidirectional traceability. Only do this for issues with partial similarity or clear topical relationship — not for every issue found during search.

成功创建Issue后，如果在重复检查步骤中发现相关Issue：

在每个相关的开放Issue下添加交叉引用评论：

bash

gh issue comment <相关Issue编号> --body "相关：#<新Issue编号> — <关系的简要描述>" 2>&1

这样可确保双向追溯。仅对部分相似或有明确主题关联的Issue执行此操作，而非搜索到的所有Issue。

Step 11 — Return the Result

步骤11 — 返回结果

Output ONLY one of:

The URL of the created issue (and URLs of any additional issues if scope was split)
A message that you commented on an existing issue (with the issue URL)
A question to the user (if duplicate ambiguity or scope needs resolution)
A note about any labels that could not be created (if applicable)

Nothing else. No issue body, no intermediate output, no "here's what I did" summary.

仅输出以下内容之一：

创建的Issue链接（如果范围拆分，则包含所有新增Issue的链接）
你在现有Issue下添加评论的提示（包含该Issue的链接）
向用户提出的问题（如重复Issue的处理方式或范围拆分的选择）
关于无法创建的标签的说明（如适用）

不得输出其他内容，如Issue正文、中间输出或“我已完成XX操作”这类总结。

Edge Cases

边缘情况

Ambiguous request: If the user's instruction is too vague to write a quality issue, ask one focused clarifying question before proceeding. Don't guess.
Multiple issues needed: If the request clearly contains multiple distinct concerns, follow the Scope Control step (Step 4).
Private repos:
```
gh
```
handles auth automatically. Errors are caught in Step 9.
No
gh
CLI: Caught in Step 0. Tell the user to install it and provide the issue content in a temporary file they can use manually.
No existing issues in repo: Skip language detection from issues, rely on README/commit messages/user language. Skip label search during deduplication.
Rate limiting: If
```
gh
```
returns HTTP 429 or rate limit errors, tell the user to wait and retry. Do not retry automatically.
Very large repos with many issues: The multi-strategy search in Step 6 uses targeted keyword queries instead of fetching all issues, so it scales to repositories of any size.
Conflicting labels: If the repo already has labels with different naming conventions (e.g.,
```
type: bug
```
instead of
```
bug
```
), prefer the repo's existing convention. Map your intended labels to their equivalents.

模糊请求：如果用户的指令过于模糊，无法生成高质量Issue，先提出一个聚焦的澄清问题，再继续操作，不得猜测。
需要多个Issue：如果请求明显包含多个独立事项，请遵循步骤4的范围控制流程。
私有仓库：
```
gh
```
CLI会自动处理认证，错误会在步骤9中捕获。
未安装
gh
CLI：在步骤0中捕获，告知用户安装，并将Issue内容保存到临时文件供用户手动使用。
仓库中无现有Issue：跳过从Issue检测语言的步骤，依赖README/提交信息/用户语言。重复检查时跳过标签搜索。
速率限制：如果
```
gh
```
返回HTTP 429或速率限制错误，告知用户等待后重试，不得自动重试。
包含大量Issue的大型仓库：步骤6中的多策略搜索使用针对性关键词查询，而非获取所有Issue，因此可适配任何规模的仓库。
标签命名冲突：如果仓库已使用不同的标签命名规范（例如：
```
type: bug
```
而非
```
bug
```
），优先使用仓库的现有规范，将你计划使用的标签映射为仓库的等效标签。",