⚠️

重要前提

安装AI Skills的关键前提是：必须科学上网，且开启TUN模式，这一点至关重要，直接决定安装能否顺利完成，在此郑重提醒三遍：科学上网，科学上网，科学上网。查看完整安装教程 →

GitHub Issues 管理工具 - 创建、查看、列出 Issues 的 CLI 技能

issues by shpigford/skills

50 周安装量

161 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/shpigford/skills --skill issues

开发项目管理命令行工具

🇨🇳中文介绍

与 GitHub issues 交互 - 创建、列出和查看 issues。

说明

此命令帮助您使用 gh CLI 处理 GitHub issues。

步骤 1：确定操作

使用 AskUserQuestion 询问用户想要做什么：

问题：

question: "您想对 GitHub issues 做什么？"
header: "操作"
multiSelect: false
options:
- label: "创建新 issue" description: "使用标题、正文和可选标签打开一个新 issue"
- label: "列出 issues" description: "查看当前仓库中的开放 issues"
- label: "查看 issue" description: "按编号查看特定 issue 的详细信息"

如果选择了"创建新 issue"：

步骤 2a：获取 Issue 标题

使用 AskUserQuestion 获取 issue 标题：

问题：

question: "这个 issue 的简短、可扫描的标题是什么？保持简短（最多 5-10 个词）- 详细信息放在正文中。（使用'其他'来输入您的标题）"
header: "标题"
multiSelect: false
options:
- label: "我将输入一个标题" description: "输入一个简洁的标题，例如'登录按钮无响应'或'添加深色模式支持'"

标题指南：

保持标题简短且可扫描（最多 5-10 个词）
好的例子："修复损坏的密码重置流程"
坏的例子："当我尝试重置密码并点击按钮时，没有任何反应，并且我收到一个错误"
描述/正文是放置详细信息的地方，而不是标题

如果用户提供了长标题，帮助他们缩短它并将详细信息移到正文中。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

步骤 3a：获取 Issue 正文

使用 AskUserQuestion 收集 issue 正文内容：

问题 1 - Issue 类型上下文：

question: "这是什么类型的 issue？"
header: "类型"
multiSelect: false
options:
- label: "Bug" description: "需要修复的某些损坏内容"
- label: "Enhancement" description: "对现有功能的改进"
- label: "New feature" description: "全新的功能"
- label: "Task" description: "一般工作项或杂务"

问题 2 - 描述：

question: "现在提供完整的详细信息。这是您解释标题中无法容纳的上下文、背景和具体细节的地方。（使用'其他'来输入您的描述）"
header: "描述"
multiSelect: false
options:
- label: "我将详细描述它" description: "提供上下文、步骤、示例和任何相关信息"

用户将在此处选择"其他"以提供其完整描述。

这是放置所有详细信息的地方 - 要彻底
包括上下文：您当时在做什么，背景是什么？
包括具体细节：错误消息、URL、版本等
这里的细节越多越好 - 与应该简短的标题不同

问题 3 - 对于 bug，询问重现步骤： 如果 issue 类型是"Bug"，使用 AskUserQuestion：

question: "您能提供重现此 bug 的步骤吗？（使用'其他'来输入步骤）"
header: "重现步骤"
multiSelect: false
options:
- label: "提供步骤" description: "我将描述如何重现该问题"
- label: "无法重现" description: "该 bug 是间歇性的或难以重现"

问题 4 - 预期与实际行为（针对 bug）： 如果 issue 类型是"Bug"，使用 AskUserQuestion：

question: "您预期会发生什么与实际发生了什么？（使用'其他'来描述）"
header: "行为"
multiSelect: false
options:
- label: "描述行为" description: "我将解释预期与实际行为"

步骤 4a：获取标签（可选）

使用 AskUserQuestion 选择标签：

question: "我们应该添加哪些标签？（如果有的话）"
header: "标签"
multiSelect: true
options:
- label: "bug" description: "某些内容无法正常工作"
- label: "enhancement" description: "新功能或请求"
- label: "documentation" description: "文档改进"
- label: "good first issue" description: "适合新手的任务"

步骤 5a：创建 Issue

根据类型构建 issue 正文：

对于 Bug 报告：

## 描述
[用户的描述]

## 重现步骤
[用户的重现步骤或"不易重现"]

## 预期行为
[应该发生什么]

## 实际行为
[实际发生了什么]

对于功能请求/改进：

## 描述
[用户的描述]

## 使用场景
[为什么这会有用]

对于任务/其他：

## 描述
[用户的描述]

运行 gh 命令来创建 issue：

gh issue create --title "[标题]" --body "[构建的正文]" --label "[标签]"

将 issue URL 报告给用户。

如果选择了"列出 issues"：

步骤 2b：筛选选项

使用 AskUserQuestion 确定筛选条件：

question: "您希望如何筛选 issues？"
header: "筛选"
multiSelect: false
options:
- label: "所有开放 issues" description: "显示所有开放 issues"
- label: "分配给我" description: "分配给当前用户的 issues"
- label: "由我创建" description: "我创建的 issues"
- label: "具有特定标签" description: "按标签筛选"

如果选择了"具有特定标签"，使用 AskUserQuestion：

question: "按哪个标签筛选？（使用'其他'输入自定义标签）"
header: "标签"
multiSelect: false
options:
- label: "bug" description: "Bug 报告"
- label: "enhancement" description: "功能请求"
- label: "documentation" description: "文档 issues"

步骤 3b：列出 Issues

运行相应的 gh 命令：

所有开放：gh issue list
分配给我：gh issue list --assignee @me
由我创建：gh issue list --author @me
具有标签：gh issue list --label "[标签]"

以清晰的格式显示结果。

如果选择了"查看 issue"：

步骤 2c：获取 Issue 编号

使用 AskUserQuestion：

question: "您想查看哪个 issue 编号？（使用'其他'输入编号）"
header: "Issue #"
multiSelect: false
options:
- label: "输入 issue 编号" description: "我将输入 issue 编号"

步骤 3c：查看 Issue

运行：gh issue view [编号]

显示 issue 详细信息，包括标题、正文、标签、分配者和评论。

如果 gh 命令失败：

检查用户是否已认证：gh auth status
如果未认证，通知用户运行 gh auth login
检查是否在具有 GitHub 远程仓库的 git 仓库中
向用户报告具体的错误消息

标题应简洁（5-10 个词）- 如果用户提供了长标题，帮助缩短它并将详细信息移到正文中
正文应详细 - 鼓励用户提供彻底的上下文、步骤和具体细节
始终通过显示 URL 来确认 issue 已成功创建
对于 issue 正文，保留用户的格式和换行符
如果用户提供的信息很少，那也没关系 - 使用他们提供的内容创建 issue
使用 HEREDOC 作为正文以保留格式：
```
gh issue create --title "标题" --body "$(cat <<'EOF'
```
正文内容在这里 EOF )"

🇺🇸English

Interact with GitHub issues - create, list, and view issues.

Instructions

This command helps you work with GitHub issues using the gh CLI.

Step 1: Determine Action

Use AskUserQuestion to ask what the user wants to do:

Question:

question: "What would you like to do with GitHub issues?"
header: "Action"
multiSelect: false
options:
- label: "Create new issue" description: "Open a new issue with title, body, and optional labels"
- label: "List issues" description: "View open issues in the current repository"
- label: "View issue" description: "See details of a specific issue by number"

If "Create new issue" selected:

Step 2a: Get Issue Title

Use AskUserQuestion to get the issue title:

Question:

question: "What's a short, scannable title for this issue? Keep it brief (5-10 words max) - details go in the body. (Use 'Other' to type your title)"
header: "Title"
multiSelect: false
options:
- label: "I'll type a title" description: "Enter a concise title like 'Login button unresponsive' or 'Add dark mode support'"

Title guidelines:

Keep titles SHORT and scannable (5-10 words max)
Good: "Fix broken password reset flow"
Bad: "When I try to reset my password and click the button nothing happens and I get an error"
The description/body is where details belong, not the title

If the user provides a long title, help them shorten it and move the details to the body.

Step 3a: Get Issue Body

Use AskUserQuestion to gather the issue body content:

Question 1 - Issue type context:

question: "What type of issue is this?"
header: "Type"
multiSelect: false
options:
- label: "Bug" description: "Something broken that needs fixing"
- label: "Enhancement" description: "Improvement to existing functionality"
- label: "New feature" description: "Brand new functionality"
- label: "Task" description: "General work item or chore"

Question 2 - Description:

question: "Now provide the full details. This is where you explain context, background, and specifics that didn't fit in the title. (Use 'Other' to type your description)"
header: "Description"
multiSelect: false
options:
- label: "I'll describe it in detail" description: "Provide context, steps, examples, and any relevant information"

The user will select "Other" here to provide their full description.

Description guidelines:

This is where ALL the detail goes - be thorough
Include context: what were you doing, what's the background?
Include specifics: error messages, URLs, versions, etc.
The more detail here, the better - unlike the title which should be brief

Question 3 - For bugs, ask about reproduction: If issue type is "Bug", use AskUserQuestion:

question: "Can you provide steps to reproduce this bug? (Use 'Other' to type steps)"
header: "Repro steps"
multiSelect: false
options:
- label: "Provide steps" description: "I'll describe how to reproduce the issue"
- label: "Not reproducible" description: "The bug is intermittent or hard to reproduce"

Question 4 - Expected vs actual behavior (for bugs): If issue type is "Bug", use AskUserQuestion:

question: "What did you expect to happen vs what actually happened? (Use 'Other' to describe)"
header: "Behavior"
multiSelect: false
options:
- label: "Describe behavior" description: "I'll explain expected vs actual behavior"

Step 4a: Get Labels (Optional)

Use AskUserQuestion to select labels:

question: "Which labels should we add? (if any)"
header: "Labels"
multiSelect: true
options:
- label: "bug" description: "Something isn't working"
- label: "enhancement" description: "New feature or request"
- label: "documentation" description: "Improvements to docs"
- label: "good first issue" description: "Good for newcomers"

Step 5a: Create the Issue

Construct the issue body based on the type:

For Bug reports:

## Description
[User's description]

## Steps to Reproduce
[User's reproduction steps or "Not easily reproducible"]

## Expected Behavior
[What should happen]

## Actual Behavior
[What actually happens]

For Feature requests/Enhancements:

## Description
[User's description]

## Use Case
[Why this would be useful]

For Tasks/Other:

## Description
[User's description]

Run the gh command to create the issue:

gh issue create --title "[title]" --body "[constructed body]" --label "[labels]"

Report the issue URL back to the user.

If "List issues" selected:

Step 2b: Filter Options

Use AskUserQuestion to determine filtering:

question: "How would you like to filter issues?"
header: "Filter"
multiSelect: false
options:
- label: "All open issues" description: "Show all open issues"
- label: "Assigned to me" description: "Issues assigned to the current user"
- label: "Created by me" description: "Issues I created"
- label: "With specific label" description: "Filter by a label"

If "With specific label" selected, use AskUserQuestion:

question: "Which label to filter by? (Use 'Other' for custom label)"
header: "Label"
multiSelect: false
options:
- label: "bug" description: "Bug reports"
- label: "enhancement" description: "Feature requests"
- label: "documentation" description: "Documentation issues"

Step 3b: List Issues

Run the appropriate gh command:

All open: gh issue list
Assigned to me: gh issue list --assignee @me
Created by me: gh issue list --author @me
With label: gh issue list --label "[label]"

Display the results in a clean format.

If "View issue" selected:

Step 2c: Get Issue Number

Use AskUserQuestion:

question: "Which issue number would you like to view? (Use 'Other' to enter the number)"
header: "Issue #"
multiSelect: false
options:
- label: "Enter issue number" description: "I'll type the issue number"

Step 3c: View Issue

Run: gh issue view [number]

Display the issue details including title, body, labels, assignees, and comments.

Error Handling

If gh command fails:

Check if user is authenticated: gh auth status
If not authenticated, inform user to run gh auth login
Check if in a git repository with a GitHub remote
Report specific error message to user

Important Notes

Titles should be succinct (5-10 words) - if a user provides a long title, help shorten it and move details to body
Bodies should be detailed - encourage users to provide thorough context, steps, and specifics
Always confirm the issue was created successfully by showing the URL
For issue bodies, preserve user's formatting and newlines
If the user provides minimal information, that's okay - create the issue with what they gave
Use HEREDOC for the body to preserve formatting:
```
gh issue create --title "Title" --body "$(cat <<'EOF'
```
Body content here EOF )"

Weekly Installs

Repository

shpigford/skills

GitHub Stars

161

First Seen

Jan 24, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykWarn

Installed on

claude-code45

opencode44

codex43

cursor43

gemini-cli41

cline37

React 组合模式指南：Vercel 组件架构最佳实践，提升代码可维护性

127,000 周安装