github-issue-creator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub Issue Creator

GitHub Issue 创建器

Create and update GitHub issues from screenshots, emails, messages, and other unstructured input sources.

从截图、邮件、消息及其他非结构化输入源创建和更新GitHub Issue。

Repo Sync Before Edits (mandatory)

编辑前的仓库同步（必填步骤）

This skill creates issues on a remote GitHub repo, so always verify connectivity first:

bash

gh auth status
gh repo view --json name,owner,url

gh

is not authenticated or the current directory is not a GitHub repo, stop and tell the user what's missing before continuing.

该技能会在远程GitHub仓库创建Issue，因此请始终先验证连接性：

bash

gh auth status
gh repo view --json name,owner,url

如果

gh

未认证或当前目录不是GitHub仓库，请暂停操作并告知用户缺失的内容，之后再继续。

Workflow

工作流程

Follow these three phases strictly. Do not skip the approval step — the user must confirm before any issue is created or updated.

严格遵循以下三个阶段。请勿跳过批准步骤——必须获得用户确认后才能创建或更新任何Issue。

Phase 1: Extract Information

阶段1：提取信息

Read the user's input carefully. Input can be:

Screenshots / images: Read the image file to extract text, error messages, UI state, stack traces, and any visible context. Pay attention to browser URLs, error codes, timestamps, and user-visible symptoms.
Pasted text: Bug report emails, Slack messages, support tickets, error logs, user complaints.
Verbal descriptions: The user describing a bug or feature request conversationally.
Multiple sources: The user may provide several screenshots plus some context text. Combine all of them.

For each distinct issue you identify, extract:

Title: A clear, concise summary (imperative or descriptive — e.g., "Login button unresponsive on mobile Safari")
Description: What's happening, including any error messages, stack traces, or reproduction context from the source material
Steps to reproduce: If inferable from the input
Expected vs actual behavior: If inferable
Environment details: OS, browser, app version — anything visible in the input
Severity/priority signal: If the source indicates urgency ("critical", "blocking", "P0", etc.)
Labels: Suggest appropriate labels based on content (e.g.,
```
bug
```
,
```
enhancement
```
,
```
critical
```
,
```
ui
```
,
```
backend
```
)

It's fine if not all fields are available — extract what you can. Don't fabricate details that aren't in the input.

仔细读取用户输入。输入类型可包括：

截图/图片：读取图片文件以提取文本、错误信息、UI状态、堆栈跟踪及任何可见上下文。注意浏览器URL、错误代码、时间戳和用户可见的症状。
粘贴文本：bug报告邮件、Slack消息、支持工单、错误日志、用户反馈。
口头描述：用户以对话形式描述bug或功能需求。
多源输入：用户可能提供多张截图及一些上下文文本，请将所有信息整合。

针对识别出的每个独立Issue，提取以下内容：

标题：清晰简洁的摘要（命令式或描述式，例如："移动端Safari登录按钮无响应"）
描述：当前问题情况，包括输入源中的错误信息、堆栈跟踪或复现上下文
复现步骤：如果可从输入中推断得出
预期与实际行为：如果可从输入中推断得出
环境细节：操作系统、浏览器、应用版本——输入中可见的所有相关信息
严重性/优先级标识：如果输入源显示紧急程度（如"critical"、"blocking"、"P0"等）
标签：根据内容建议合适的标签（例如：
```
bug
```
、
```
enhancement
```
、
```
critical
```
、
```
ui
```
、
```
backend
```
）

如果并非所有字段都可用也没关系——提取能获取到的信息即可。请勿编造输入中不存在的细节。

Phase 1.5: Sanitize Sensitive Information

阶段1.5：敏感信息脱敏

GitHub issues are typically public (or at least visible to the whole team). Bug reports from emails, screenshots, and support tickets often contain personal or confidential data that should never end up in a GitHub issue. Before composing any issue content, scan everything you extracted and redact the following:

Personal Identifiable Information (PII):

Names of end users or reporters — replace with generic references like "a user", "the reporter". Keep names only if the person is a team member the user explicitly wants tagged.
Email addresses — redact entirely (e.g.,
```
j***@example.com
```
or just remove)
Phone numbers — remove
Physical addresses — remove
User IDs / account names of end users — replace with
```
[user_id]
```
or
```
[redacted]
```

Credentials and secrets:

API keys, tokens, passwords — if visible in screenshots or logs, replace with
```
[REDACTED_API_KEY]
```
,
```
[REDACTED_TOKEN]
```
, etc. Flag these to the user as a heads-up ("I noticed an API key in the screenshot — I've removed it from the issue.")
Session IDs, cookies, auth headers — redact
Database connection strings — redact

Infrastructure details (redact unless clearly needed for the bug):

Internal IP addresses — replace with
```
[internal_ip]
```
Internal hostnames / URLs that expose infrastructure — replace with
```
[internal_host]
```
Database names, table names — keep only if directly relevant to the bug

Other sensitive content:

Customer data visible in screenshots (financial info, health info, private messages) — describe the data type without reproducing the actual values (e.g., "the user's transaction history was visible" instead of listing actual transactions)
Proprietary business logic visible in error details — summarize rather than quote verbatim if it reveals trade secrets

How to handle it in practice:

After extracting information in Phase 1, do a sweep for all of the above before composing the issue body.
When you redact something, note it briefly in the proposal so the user can see what was removed and override if needed (e.g., "Note: removed reporter's email address and an exposed API key from the issue body").
If the input is heavily loaded with sensitive data and redacting it would make the bug report meaningless, flag this to the user: "This report contains a lot of sensitive details. Want me to create a more generic description, or would you prefer a private/internal issue?"
When in doubt, redact. It's easy for the user to add information back; it's hard to un-leak something posted publicly.

GitHub Issue通常是公开的（至少对整个团队可见）。来自邮件、截图和支持工单的bug报告往往包含个人或机密数据，这些绝不能出现在GitHub Issue中。在撰写任何Issue内容前，请扫描所有提取的信息并脱敏以下内容：

个人可识别信息（PII）：

终端用户或报告者姓名——替换为通用指代，如"某用户"、"报告者"。仅当用户明确要求标记团队成员时才保留姓名。
邮箱地址——完全脱敏（例如：
```
j***@example.com
```
或直接移除）
电话号码——移除
物理地址——移除
终端用户的ID/账户名——替换为
```
[user_id]
```
或
```
[redacted]
```

凭证与机密信息：

API密钥、令牌、密码——如果在截图或日志中可见，替换为
```
[REDACTED_API_KEY]
```
、
```
[REDACTED_TOKEN]
```
等。同时提醒用户（"我注意到截图中有API密钥——已从Issue中移除"）
会话ID、Cookie、认证头——脱敏
数据库连接字符串——脱敏

基础设施细节（除非与bug直接相关否则脱敏）：

内部IP地址——替换为
```
[internal_ip]
```
暴露基础设施的内部主机名/URL——替换为
```
[internal_host]
```
数据库名、表名——仅当与bug直接相关时保留

其他敏感内容：

截图中可见的客户数据（财务信息、健康信息、私人消息）——描述数据类型而非重现实际值（例如："用户的交易历史可见"而非列出具体交易）
错误详情中显示的专有业务逻辑——如果泄露商业机密，请概括而非直接引用原文

实际处理方式：

在阶段1提取信息后，在撰写Issue正文前全面检查上述内容。
脱敏内容时，在提案中简要说明，以便用户了解移除的内容并可按需覆盖（例如："注意：已从Issue正文中移除报告者邮箱地址和暴露的API密钥"）。
如果输入包含大量敏感数据，脱敏后会导致bug报告失去意义，请告知用户："该报告包含大量敏感细节。是否需要我创建更通用的描述，还是更倾向于创建私有/内部Issue？"
如有疑问，优先脱敏。用户添加信息很容易，但公开泄露的信息很难撤回。

Phase 2: Detect Templates and Propose Issues

阶段2：检测模板并生成Issue提案

Template Detection

模板检测

Check the repo for issue templates:

bash

undefined

检查仓库是否存在Issue模板：

bash

undefined

Check for issue templates in common locations

检查常见位置的Issue模板

ls .github/ISSUE_TEMPLATE/ 2>/dev/null cat .github/ISSUE_TEMPLATE/.md 2>/dev/null cat .github/ISSUE_TEMPLATE/.yml 2>/dev/null

Also check for a simple issue template

同时检查简单的Issue模板

cat .github/ISSUE_TEMPLATE.md 2>/dev/null


If templates exist, read them and use their structure for the proposed issues. Match each issue to the most appropriate template (e.g., bug report template for bugs, feature request template for enhancements).

If no templates exist, use this default structure:

```markdown

cat .github/ISSUE_TEMPLATE.md 2>/dev/null


如果存在模板，请读取并使用其结构生成提案Issue。将每个Issue与最合适的模板匹配（例如：bug使用bug报告模板，功能需求使用功能请求模板）。

如果没有模板，请使用以下默认结构：

```markdown

Description

描述

[Clear description of the issue]

[清晰的问题描述]

Steps to Reproduce

复现步骤

[Step 1]
[Step 2]
[Step 3]

[步骤1]
[步骤2]
[步骤3]

Expected Behavior

预期行为

[What should happen]

[应该发生的情况]

Actual Behavior

实际行为

[What actually happens]

[实际发生的情况]

Environment

环境

OS: [if known]
Browser/Version: [if known]
App Version: [if known]

操作系统：[如果已知]
浏览器/版本：[如果已知]
应用版本：[如果已知]

Additional Context

额外上下文

[Screenshots, logs, related issues]

undefined

[截图、日志、相关Issue]

undefined

Check for Existing Issues

检查现有Issue

Before proposing new issues, search for potentially related open issues:

bash

gh issue list --state open --limit 30

If any existing issues look related to the extracted information, propose updating them instead of creating duplicates. Use keyword matching on titles and bodies — err on the side of flagging potential duplicates for the user to decide.

在生成新Issue提案前，搜索可能相关的已打开Issue：

bash

gh issue list --state open --limit 30

如果发现任何与提取信息相关的现有Issue，建议更新该Issue而非创建重复项。通过标题和正文的关键词匹配进行判断——优先标记潜在重复项供用户决定。

Present the Proposal

展示提案

Show the user a clear, numbered list of proposed actions. For each:

undefined

向用户展示清晰的编号式提案操作列表。每个提案格式如下：

undefined

Issue [N]: [Create new | Update #existing-number]

Issue [编号]：[创建新Issue | 更新#已有编号]

Title: [issue title] Labels:

bug

ui

(etc.) Template: [template name if using repo template, or "default"]

Body preview:

[Show the full issue body as it will appear on GitHub]


If proposing updates to existing issues, show what will be added (as a comment or body edit) and link to the existing issue.

End with a clear prompt:

> **Does this look right?** You can:
> - Say **"go"** or **"approve"** to create/update all issues as shown
> - Say **"skip 2"** to exclude a specific issue
> - Ask me to modify any issue before creating it
> - Say **"cancel"** to abort

**Do not proceed until the user explicitly approves.** This is critical — creating issues is a visible action that others will see.

标题：[Issue标题] 标签：

bug

ui

（等）模板：[使用仓库模板的名称，或"默认"]

正文预览:

[展示将在GitHub上显示的完整Issue正文]


如果提案是更新现有Issue，请展示将要添加的内容（作为评论或正文编辑）并链接到现有Issue。

结尾给出明确提示：

> **这样是否合适？** 您可以：
> - 回复**"go"**或**"approve"**以按所示创建/更新所有Issue
> - 回复**"skip 2"**以排除特定Issue
> - 要求我修改任意Issue后再创建
> - 回复**"cancel"**以中止操作

**在获得用户明确批准前请勿继续。** 这一点至关重要——创建Issue是会被其他人看到的公开操作。

Phase 3: Create / Update Issues

阶段3：创建/更新Issue

Once approved, execute the actions using

gh

Creating a new issue:

bash

gh issue create --title "TITLE" --body "$(cat <<'ISSUE_BODY'
... issue body ...
ISSUE_BODY
)" --label "bug,ui"

Updating an existing issue (add a comment):

bash

gh issue comment ISSUE_NUMBER --body "$(cat <<'COMMENT_BODY'
... update content ...
COMMENT_BODY
)"

Adding labels to an existing issue:

bash

gh issue edit ISSUE_NUMBER --add-label "label1,label2"

After each action, confirm success and report the issue URL back to the user. At the end, provide a summary:

Done! Created/updated the following issues:

#42: Login button unresponsive on mobile Safari

#38: (updated) Add dark mode support — added reproduction details

获得批准后，使用

gh

执行操作：

创建新Issue：

bash

gh issue create --title "TITLE" --body "$(cat <<'ISSUE_BODY'
... issue body ...
ISSUE_BODY
)" --label "bug,ui"

更新现有Issue（添加评论）：

bash

gh issue comment ISSUE_NUMBER --body "$(cat <<'COMMENT_BODY'
... 更新内容 ...
COMMENT_BODY
)"

为现有Issue添加标签：

bash

gh issue edit ISSUE_NUMBER --add-label "label1,label2"

每个操作完成后，确认成功并向用户返回Issue URL。最后提供总结：

完成！ 创建/更新了以下Issue：

#42：移动端Safari登录按钮无响应

#38：（已更新）添加深色模式支持——补充了复现细节

Expected Output

预期输出

After the user approves the proposal, the skill creates the issue and reports:

Done! Created/updated the following issues:
- #47: Login button unresponsive on mobile Safari
  https://github.com/acme/webapp/issues/47
  Labels: bug, ui, mobile

The created issue body looks like:

markdown

undefined

用户批准提案后，该技能会创建Issue并返回：

Done! Created/updated the following issues:
- #47: Login button unresponsive on mobile Safari
  https://github.com/acme/webapp/issues/47
  Labels: bug, ui, mobile

创建的Issue正文示例：

markdown

undefined

Description

描述

The login button does not respond to taps on mobile Safari (iOS 17). Tapping the button produces no visual feedback and the login flow never initiates.

移动端Safari（iOS 17）上的登录按钮点击无响应。点击按钮无视觉反馈，登录流程从未启动。

Steps to Reproduce

复现步骤

Open https://app.example.com on iPhone with Safari (iOS 17)
Enter valid credentials
Tap the "Log In" button

在iPhone的Safari浏览器（iOS 17）中打开https://app.example.com
输入有效凭证
点击"登录"按钮

Expected Behavior

预期行为

The login flow initiates and the user is redirected to the dashboard.

登录流程启动，用户被重定向到仪表盘。

Actual Behavior

实际行为

Nothing happens. No spinner, no error message, no navigation.

无任何反应。无加载动画、无错误提示、无页面跳转。

Environment

环境

OS: iOS 17.4
Browser: Safari (mobile)
App Version: 2.3.1

操作系统：iOS 17.4
浏览器：Safari（移动端）
应用版本：2.3.1

Additional Context

额外上下文

Reported via screenshot on 2026-04-19. Note: reporter email and user ID were redacted before filing.

undefined

2026-04-19通过截图上报。注意：上报者邮箱和用户ID已脱敏后提交。

undefined

Edge Cases

边缘情况

No repo access / gh not authenticated: Run
```
gh auth status
```
at the start; stop and tell the user what's missing before extracting any data.
Duplicate issue: Search open issues for keyword matches before proposing creation; if a near-duplicate is found, offer to update it with a comment instead.
Missing required fields: If the input lacks enough detail to write a meaningful description or steps to reproduce, ask clarifying questions rather than filing a skeletal issue.
PII-heavy input: If redacting sensitive data would make the report meaningless, flag this to the user and offer to create a private/internal issue or use generic descriptions.
Multiple issues in one input: Extract each distinct problem as a separate numbered proposal; let the user approve, skip, or modify each independently.
YAML issue templates: Parse
```
.yml
```
templates with structured fields and map extracted data to the template's field IDs and types; respect required fields.
User drops image without context: Read the image to extract all visible text, UI state, error codes, and URLs; infer the issue from the visual context before asking for clarification.

无仓库权限/gh未认证：一开始就运行
```
gh auth status
```
；如果未通过验证，暂停操作并告知用户缺失的内容，之后再提取任何数据。
重复Issue：生成创建提案前搜索已打开的Issue；如果发现近似重复项，建议通过添加评论更新该Issue而非创建新Issue。
缺少必填字段：如果输入缺乏足够细节来撰写有意义的描述或复现步骤，请询问用户澄清问题，而非提交内容残缺的Issue。
包含大量PII的输入：如果脱敏敏感数据会导致报告失去意义，请告知用户并提供创建私有/内部Issue或使用通用描述的选项。
单次输入包含多个Issue：将每个独立问题提取为单独的编号提案；让用户独立批准、跳过或修改每个提案。
YAML格式Issue模板：解析
```
.yml
```
模板的结构化字段，将提取的数据映射到模板的字段ID和类型；遵守必填字段要求。
用户仅提供图片无上下文：读取图片提取所有可见文本、UI状态、错误代码和URL；先从视觉上下文推断问题，再询问用户澄清。

Acceptance Criteria

验收标准

```
gh auth status
```
and
```
gh repo view
```
succeed before any extraction begins
Each issue identified in the input is proposed individually with title, labels, template, and full body preview
PII (names, emails, API keys, internal IPs) is redacted before issue body is shown to the user
Existing open issues are searched for potential duplicates; matches are flagged
No issue is created or updated without explicit user approval ("go" / "approve")
Each created issue returns a URL confirming the issue number
Labels used exist in the repo (
```
gh label list
```
) or are clearly flagged as new
Sensitive data removal is disclosed in the proposal (e.g., "Note: removed API key")

```
gh auth status
```
和
```
gh repo view
```
在开始提取前执行成功
输入中识别出的每个Issue都单独生成提案，包含标题、标签、模板和完整正文预览
PII（姓名、邮箱、API密钥、内部IP）在向用户展示Issue正文前已脱敏
搜索现有已打开Issue以查找潜在重复项；标记匹配项
未获得用户明确批准（"go"/"approve"）的情况下，绝不创建或更新Issue
每个创建的Issue都返回确认编号的URL
使用的标签已存在于仓库中（
```
gh label list
```
）或明确标记为新标签
提案中披露敏感数据的移除情况（例如："注意：已移除API密钥"）

Step Completion Reports

步骤完成报告

After completing each major step, output a status report in this format:

◆ [Step Name] ([step N of M] — [context])
··································································
  [Check 1]:          √ pass
  [Check 2]:          √ pass (note if relevant)
  [Check 3]:          × fail — [reason]
  [Check 4]:          √ pass
  [Criteria]:         √ N/M met
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Adapt the check names to match what the step actually validates. Use

√

for pass,

×

for fail, and

—

to add brief context. The "Criteria" line summarizes how many acceptance criteria were met. The "Result" line gives the overall verdict.

完成每个主要步骤后，按以下格式输出状态报告：

◆ [步骤名称] ([第N步/共M步] — [上下文])
··································································
  [检查项1]:          √ 通过
  [检查项2]:          √ 通过（相关备注）
  [检查项3]:          × 未通过 — [原因]
  [检查项4]:          √ 通过
  [验收标准]:         √ 已满足N/M项
  ____________________________
  结果:             通过 | 未通过 | 部分通过

根据步骤实际验证的内容调整检查项名称。使用

√

表示通过，

×

表示未通过，

—

添加简要上下文。"验收标准"行总结已满足的验收标准数量。"结果"行给出整体结论。

Phase-specific checks

各阶段专属检查项

Phase 1 — Extract

◆ Extract (step 1 of 3 — [input type: screenshot/email/text])
··································································
  Input parsed:       √ pass | × fail — [parse error]
  Data extracted:     √ pass ([N] issues identified)
  PII redacted:       √ pass | × fail — [what was found/removed]
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Phase 2 — Template Detection & Proposal

◆ Template Detection (step 2 of 3 — [repo name])
··································································
  Templates found:    √ pass ([N] templates) | × fail — using default
  Fields mapped:      √ pass | × fail — [unmapped fields]
  ____________________________
  Result:             PASS | FAIL | PARTIAL

Phase 3 — Create / Update

◆ Create/Update (step 3 of 3 — [N issues])
··································································
  Issue created:      √ pass (#[number]: [title])
  Labels applied:     √ pass | × fail — [labels missing]
  Assignees set:      √ pass | × fail — [assignees not set]
  ____________________________
  Result:             PASS | FAIL | PARTIAL

阶段1 — 提取

◆ 提取（第1步/共3步 — [输入类型：截图/邮件/文本]）
··································································
  输入解析:       √ 通过 | × 未通过 — [解析错误]
  数据提取:       √ 通过（识别出[N]个Issue）
  PII脱敏:       √ 通过 | × 未通过 — [发现/移除的内容]
  ____________________________
  结果:             通过 | 未通过 | 部分通过

阶段2 — 模板检测与提案

◆ 模板检测（第2步/共3步 — [仓库名称]）
··································································
  找到模板:       √ 通过（[N]个模板） | × 未通过 — 使用默认模板
  字段映射:       √ 通过 | × 未通过 — [未映射字段]
  ____________________________
  结果:             通过 | 未通过 | 部分通过

阶段3 — 创建/更新

◆ 创建/更新（第3步/共3步 — [N个Issue]）
··································································
  Issue创建:       √ 通过（#[编号]: [标题]）
  标签应用:       √ 通过 | × 未通过 — [缺失标签]
  经办人设置:       √ 通过 | × 未通过 — [未设置经办人]
  ____________________________
  结果:             通过 | 未通过 | 部分通过

Important Guidelines

重要指南

Never create issues without approval. The proposal step is not optional.
Preserve original context. When the input is a screenshot or email, mention the source in the issue body (e.g., "Reported via email on 2026-03-17" or "From screenshot of error dialog"). Don't attach the screenshot itself to the issue unless the user asks — just describe what's visible.
One input can yield multiple issues. A single screenshot might show several problems. A forwarded email might contain a list of bugs. Extract them all as separate issues.
Be conservative with labels. Only suggest labels that clearly apply. If the repo has existing labels, prefer those over inventing new ones. Check with:
```
gh label list --limit 50
```
Handle ambiguity by asking. If you're not sure whether something is a bug or a feature request, or whether two things should be one issue or two, ask the user.
YAML template parsing. Some repos use
```
.yml
```
templates with structured fields (type: input, type: textarea, etc.). When you encounter these, map your extracted data to the template's field IDs and format the issue body accordingly, respecting required fields and field types.

绝不要未经批准创建Issue。 提案步骤是必填项。
保留原始上下文。 当输入是截图或邮件时，在Issue正文中提及来源（例如："2026-03-17通过邮件上报"或"来自错误对话框截图"）。除非用户要求，否则不要将截图附加到Issue中——仅描述可见内容即可。
单次输入可生成多个Issue。 单张截图可能显示多个问题。转发的邮件可能包含多个bug列表。将所有问题提取为独立Issue。
谨慎使用标签。 仅建议明确适用的标签。如果仓库已有标签，优先使用现有标签而非创建新标签。可通过
```
gh label list --limit 50
```
查看现有标签。
遇到歧义时询问用户。 如果不确定某内容是bug还是功能需求，或不确定两个内容应合并为一个Issue还是分为两个，请询问用户。
YAML模板解析。 部分仓库使用带结构化字段的
```
.yml
```
模板（type: input, type: textarea等）。遇到此类模板时，将提取的数据映射到模板的字段ID并相应格式化Issue正文，遵守必填字段和字段类型要求。