创建GitHub问题Skill：一句话把「写 Issue」变成对话，30 秒生成规范的 GitHub 问题
- 核心能力：在 AI 助手对话中通过
/create-issue命令，引导式收集仓库、标题、正文和标签，最终调用 GitHub MCP 的create_issue工具真实创建问题，并返回问题编号与 URL。 - 解决的痛点：告别手动切浏览器、找仓库、点「New Issue」、纠结模板字段的碎片操作，把「描述需求」和「提交 Issue」合并成一次对话。
- 关键前提：需要预先安装并配置 GitHub MCP 服务器，完成 OAuth 认证，并且账号在目标仓库中拥有创建 Issue 的权限。
- 最大差异点：这不是一个「帮你写文案」的生成器，而是真正打通 GitHub API 的执行型技能，写完即提交，落地到具体 issue 编号。
- 适用人群：开发者、测试工程师、开源项目维护者、需要把用户反馈转成研发工单的产品与运营人员。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 创建GitHub问题Skill |
| 技能英文名 | create-issue |
| 技能ID | 14059 |
| 技能定位 | 在 GitHub 仓库中创建一个新问题 |
| 调用方式 | /create-issue [参数] |
它解决的问题非常具体：在软件开发协作中，「发现问题」与「登记问题」之间往往隔着一长串操作——打开浏览器、登录 GitHub、进入正确仓库、点击新建 Issue、回忆团队的模板字段、补标签、检查 Markdown 语法。这个过程对熟练开发者是几十秒的摩擦，对非研发角色则常常意味着干脆不登记，最终导致信息丢失、责任不清。创建GitHub问题Skill 把这一整套动作压缩成一次自然语言对话。
「一键安装」AI 技能提升开发效率的思路
所谓「一键安装」，本质是把技能的调用入口、所需的外部能力（此处是 GitHub MCP 服务器）和身份认证一次性打通，之后每次使用都只需一句命令。通用步骤如下（具体命令、入口与配置方式请以官方说明为准）：
- 确认安装前提：你的 AI 客户端支持技能（Skill）机制与斜杠命令；已具备 GitHub 账号；在目标仓库中拥有创建 Issue 的权限（公开仓库同样需要具备提 Issue 的账号状态）。
- 安装技能本体：在技能市场或技能管理入口中搜索技能ID
14059或英文名create-issue，点击安装/启用。安装后应能在命令列表中看到/create-issue。 - 配置 GitHub MCP 服务器：本技能不直接拼接 HTTP 请求，而是调用 GitHub MCP 提供的
create_issue工具。因此必须先在客户端中安装并配置 GitHub MCP 服务器（配置方式与服务器地址以官方说明为准）。 - 完成 OAuth 认证：按客户端提示完成 GitHub 的 OAuth 授权流程，使技能具备代表你操作仓库的凭据。认证未完成时，创建动作会失败。
- 验证是否生效：新建一个会话，输入
/create-issue，若助手开始询问「什么仓库？（所有者/仓库格式）」，说明技能已正常加载；也可先用一个测试仓库完成一次低风险的 Issue 创建，确认返回了问题编号与 URL。
这种安装思路的价值在于：安装一次，后续所有 Issue 创建都复用同一套认证与工具链，边际使用成本几乎为零。
该技能的主要功能和特点
- 引导式信息收集：按固定顺序依次询问仓库、标题、正文/描述、标签（可选），避免用户漏填关键信息，从源头减少「一句话 Issue」。
- 真实创建而非仅生成草稿：最终通过 GitHub MCP 的
create_issue工具在目标仓库中提交问题，返回问题编号（如#42）与可点击的 URL。 - 支持标签管理：可在创建时一并传入标签，多个标签以逗号分隔，例如
bug, high-priority，便于后续筛选与分派。 - 原生 Markdown 正文：描述内容支持 GitHub 风格的 Markdown，可写标题层级、有序列表、代码块，重现步骤可以写得很规整。
- 支持协作引用语法：正文中可用
#123引用已有 Issue/PR，用@用户名提及成员并触发通知，让新 Issue 自动挂进讨论链路。 - 灵活的调用参数：概要为
/create-issue [参数]，用法为/create-issue [所有者/仓库]，即可以在命令后直接带上仓库标识，减少一轮往返问答。 - 与工作流上下游自然衔接：与
/search-code（提交前查找相关代码）、/create-pr（创建 PR 修复问题）、/review-pr（审查相关 PR）形成「搜代码 → 提 Issue → 提 PR → 审 PR」的闭环。
和普通工具相比强在哪？普通的 Issue 模板只是在网页端给你一个空表单，AI 写作工具则往往只能产出文案、你还得复制粘贴。这个技能把「结构化引导 + Markdown 撰写 + GitHub API 写入 + 结果回执」串成一条链，用户只需要表达意图，剩下的动作用工具完成。
如何使用该技能？
以下为分步骤使用指南，操作路径基于技能详情中的交互流程。
步骤 1：发起命令
在对话中输入：
/create-issue
如果你已经明确目标仓库，可以直接带上仓库标识：
/create-issue my-org/my-repo
步骤 2：提供仓库（所有者/仓库格式）
技能会首先询问仓库。注意必须使用 所有者/仓库 格式，例如 my-org/my-repo，而不是完整 URL 或仅仓库名。
步骤 3：输入问题标题
标题应清晰、可操作。对比示例：
- 较差：
内存有问题 - 较好：
修复图像处理器中的内存泄漏
步骤 4：填写问题正文/描述
这是最有价值的一步。建议包含现象、影响、重现步骤、期望行为。可直接使用 Markdown：
处理大图像时内存使用量持续增加。
处理100多张图像后，应用程序因OOM错误崩溃。
## 重现步骤
1. 启动图像处理器
2. 处理100多张大图像（每张>5MB）
3. 观察内存使用量上升
步骤 5：添加标签（可选）
按提示输入以逗号分隔的标签，如 bug, high-priority；不需要标签时直接按 Enter 跳过。
步骤 6：等待创建并接收回执
技能会提示「在 my-org/my-repo 中创建问题…」，成功后返回形如下方的结果：
问题创建成功！
#42 - 修复图像处理器中的内存泄漏
https://github.com/my-org/my-repo/issues/42
拿到编号与链接后，你可以把它贴进聊天群、写进提交信息，或用 #42 在其他 Issue/PR 中引用。
输入输出要点小结：输入 = 仓库 + 标题 + 正文 +（可选）标签；输出 = 问题编号 + 问题 URL。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 创建GitHub问题Skill（create-issue） | 对话式 Issue 创建执行器 | 引导收集仓库/标题/正文/标签，调用 GitHub MCP create_issue 真实建单并回执编号与 URL |
需安装技能 + 配置 GitHub MCP 服务器 + 完成 OAuth 认证 | 开发过程中随手登记缺陷、把讨论结论沉淀为工单 | 优势：全流程一次对话完成，结构化程度高；不足：强依赖 MCP 与认证，前置配置比网页端更重 |
| GitHub 网页端新建 Issue | 官方原生入口 | 表单填写、模板选择、预览、指派、里程碑等完整字段 | 零安装，登录即可 | 需要精细设置里程碑、指派、项目看板等复杂字段 | 优势：字段最全、官方支持；不足：需离开当前工作上下文，模板字段靠人记 |
| AI 写作类助手（生成 Issue 文案） | 文本生成 | 根据描述生成标题与正文草稿 | 极低，直接对话 | 只想润色措辞、整理措辞不规范的口述内容 | 优势：上手最快；不足：不写入 GitHub，仍需手动复制粘贴并补齐字段 |
| GitHub CLI（命令行建单） | 命令行工具 | 通过命令参数与编辑器创建 Issue | 需安装 CLI 并完成登录授权 | 终端重度用户、脚本化批量操作 | 优势：可脚本化、可自动化；不足：需要记参数语法，标签与正文需自行拼装，无引导 |
从对比可见：网页端胜在字段完整，写作类助手胜在零门槛，GitHub CLI 胜在可脚本化，而 create-issue 的独特生态位是「在对话上下文里完成填写与提交」，把思考与登记合并。
该技能的典型应用场景与实际体验情况
场景一：开发过程中临时发现缺陷
角色：后端/前端开发者。痛点：正在读代码或跑测试，发现一个与当前任务无关但确实存在的缺陷，切浏览器登记会打断心流，不登记又怕忘。使用方式：直接在对话框输入 /create-issue，两分钟内把仓库、标题、复现步骤和 bug 标签填完。实际体验：引导顺序清晰，标题与正文被自然拆成两问，反而促使你把复现步骤写清楚；注意仓库格式必须是 所有者/仓库，写成链接会需要重来一次。
场景二：测试工程师批量登记验证问题
角色：QA。痛点：一轮回归往往产出多条问题，逐条在网页端填写模板耗时且容易漏标签。使用方式：连续多次调用 /create-issue，标签统一使用 bug 等约定值，正文统一带上「重现步骤」。实际体验：结构一致性明显提升，回执里的问题编号便于直接贴进测试报告；注意标签需按团队既有命名，写错不会自动纠正。
场景三：开源维护者把用户反馈转成工单
角色：开源项目维护者。痛点：用户常在聊天群、邮件里用口语描述问题，维护者需要翻译成规范 Issue。使用方式：据反馈内容调用技能，正文中用 @用户名 提及报告者、用 #123 关联同类历史问题。实际体验：提及与引用语法让新 Issue 自带上下文，减少来回澄清；注意提及他人前应确认对方 GitHub 用户名准确，避免误通知。
场景四：产品/运营把需求讨论沉淀为可执行任务
角色：产品经理。痛点：不熟悉 GitHub 操作，需求口头传达后无人跟进。使用方式：在具备权限的仓库中，请 AI 协助把讨论结论整理成标题 + 背景 + 验收要点，再提交并打上对应标签。实际体验：上手门槛主要在 OAuth 授权与仓库命名规范，通过一次就顺畅；建议先在测试仓库演练一遍，确认权限无误。
整体体验小结：上手难度中等偏低——难点集中在一次性配置（MCP + OAuth），配好之后每次使用都是几句话的事。效果上，最大收益不是「快了几十秒」，而是「Issue 质量变稳定」：标题更可操作、正文更可能包含重现步骤、标签不再遗漏。
该技能能为用户带来的价值
- 把碎片操作收敛为一次对话：原本「切窗口 → 找仓库 → 填表 → 补标签」的多步操作变成一次问答，减少上下文切换带来的心流损耗。
- 提升 Issue 质量而非仅提升速度：固定的询问顺序天然形成「仓库—标题—描述—标签」的结构化检查清单，让遗漏字段的概率显著降低。
- 降低非研发角色的参与门槛：产品、运营、测试不必熟悉 GitHub 页面结构，也能按引导产出符合研发要求的问题单，减少「转述失真」。
- 沉淀可协作的上下文：Markdown 正文、
#123引用、@用户名提及的组合，让每条 Issue 天然挂在项目的信息网络中，便于追溯与追责。 - 与上下游技能形成闭环：配合
/search-code、/create-pr、/review-pr，把「搜代码—提问题—提修复—审修复」串联，长期看提升的是团队协作流程的确定性，而不只是单点效率。
常见问题 FAQ
Q1：怎么安装这个技能？需要准备什么？
在技能管理入口搜索技能ID 14059 或英文名 create-issue 安装启用，然后完成两项前置：配置 GitHub MCP 服务器、完成 GitHub OAuth 认证。安装后输入 /create-issue，若助手开始询问仓库，即表示生效。具体安装命令与入口以官方说明为准。
Q2：这个技能收费吗？
技能详情中未包含任何价格信息，收费情况请以官方说明为准。需要注意的是，它依赖 GitHub 账号权限与客户端提供的 MCP 能力，这部分成本取决于你所使用的客户端与 GitHub 账号类型。
Q3：为什么创建失败？最常见的原因是什么？
按技能的先决条件排查三类问题：GitHub MCP 服务器是否已安装并正确配置、OAuth 认证是否已完成、你的账号在目标仓库中是否拥有创建 Issue 的权限。此外，仓库需使用 所有者/仓库 格式，写成完整网址可能导致识别失败。
Q4：适合谁用？不适合谁？
适合开发者、测试、开源维护者以及需要把讨论转成工单的产品运营；也适合希望统一团队 Issue 书写规范的团队。若你需要设置里程碑、指派多人、挂项目看板等复杂字段，官方网页端仍然更完整，本技能更适合「快速、规范地建单」。
Q5：和直接用 GitHub 网页端或写作类 AI 助手怎么选？
追求字段完整与官方支持，选网页端；只想润色文案、不介意手动粘贴，选写作类助手；需要脚本化批量操作，选 GitHub CLI。若你的核心诉求是「在对话里把想法直接变成有编号的真实 Issue」，且愿意一次性配置 MCP 与认证，本技能最省心。