create-issue（GitLabIssue创建器）Skill 是什么？

GitLabIssue创建器Skill：用一句话把零散需求变成结构规范的 GitLab 问题单

• 一句话定位：create-issue 是一个把「口头需求 / 聊天里的 bug 反馈」快速变成规范 GitLab 问题单的 AI 技能，通过 /create-issue 一条指令走完创建流程。
• 核心机制：技能本身不直接写数据库，而是引导式地收集项目、标题、描述、标签，再调用 GitLab MCP 的 create_issue 工具真正落单，并回传问题编号与链接。
• 使用前提：必须已安装并配置 GitLab MCP 服务器、完成 OAuth 身份验证，且在目标项目拥有创建问题（Issue）的权限。
• 最大差异点：不是「生成一段文案让你自己复制粘贴」，而是「问清楚 → 直接创建 → 返回可点击链接」，闭环在对话里完成。
• 适合谁用：日常在 GitLab 上做需求管理、缺陷跟踪的研发、测试、项目经理，以及用 AI 助手做日常协作的效率工具用户。

1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？

这个技能的中文名是 GitLabIssue创建器Skill，英文名是 create-issue，技能 ID 为 14053。在技能自身的命令体系中，它也以 gitlab:create-issue 的形式出现，调用入口是斜杠命令 /create-issue。

它解决什么问题？

在真实的研发协作里，「提一个问题单」看似简单，实际很费神：要打开浏览器、找到对的 GitLab 项目、挑对的项目 ID、想一个清晰的标题、把复现步骤补齐、再选标签。结果是三种常见情况——要么漏提，bug 只留在聊天记录里；要么提得潦草，标题写成「有个问题」，描述只有一句「打不开」，后续排查全靠追问；要么标签乱用，导致看板统计失真。create-issue 的价值就在于：把这些「格式要求」和「流程跳转」交给 AI 引导，人只负责说清楚问题是什么。

一键安装的思路与步骤

所谓「一键安装」，本质是把三件事一次性配好：技能本体、GitLab MCP 连接、身份授权。具体安装命令、安装入口地址与版本信息，请以官方说明为准。通用流程如下：

1. 准备前提环境：确认你的 AI 客户端支持技能（Skill）机制与 MCP 协议；准备好一个可访问的 GitLab 实例地址（SaaS 或自建均可）。
2. 安装并配置 GitLab MCP 服务器：这是该技能的硬性前提。技能本身只负责「对话引导」，真正创建问题的是 GitLab MCP 提供的 create_issue 工具。若 MCP 未配置，技能会在执行环节失败。
3. 完成 OAuth 身份验证：技能需要以「你」的身份在 GitLab 中操作，因此必须完成授权登录，否则即使 MCP 通了，也会因为没有身份而被拒绝。
4. 确认项目权限：确保你的账号在目标项目中具有创建问题的权限（Developer 及以上通常是必要条件，具体以你们 GitLab 实例的权限策略为准）。
5. 安装技能本体：通过官方技能市场/技能安装入口搜索技能名 create-issue 或技能 ID 完成安装，安装后确认技能处于启用状态。
6. 验证是否生效：在对话中输入 /create-issue，如果 AI 回复类似「我将帮助您创建 GitLab 问题。项目 ID 或路径是什么？」的引导语，说明技能已正常加载；随后可先在测试项目里真实提交一个 Issue，确认能拿到问题编号与 URL。

安装小贴士：如果你所在团队用自建 GitLab，最容易踩的坑不是技能装不上，而是 MCP 服务器访问不到内网实例、或 OAuth 回调地址配置不正确。建议先单独验证 MCP 连接可用，再安装技能。

2. 该技能的主要功能和特点

• 引导式问题创建：不会让你面对一堆参数发愁，而是按「项目 → 标题 → 描述 → 标签」的顺序逐项询问，缺失的信息当场补齐。
• 直接落单，返回可追溯结果：创建成功后返回问题编号（如 #42）和问题 URL，可直接贴进群聊或周报，避免「提了吗？在哪？」的来回确认。
• 标签可选、支持批量输入：用逗号分隔即可一次写入多个标签（如 bug, 高优先级, 性能），既保证了分类规范，又不强制你必须打标签。
• 描述可跳过：确认描述为可选，按 Enter 即可跳过，适合「先记下来，稍后补充」的轻量场景。
• 支持项目 ID 与路径两种定位方式：既可以用数字项目 ID（查找更快），也可以用 URL 编码的路径形式（如 my-group%2Fmy-project），跨组协作时更直观。
• 天然贴合 GitLab 的写法习惯：技能提示中建议使用 #123 语法在描述里引用相关问题或合并请求，让问题单之间的关联关系在 GitLab 里可视化。
• 可与其他命令组合成流水线：配套的 /search-issues 用于查重、/view-issue 用于查看详情、/create-mr 用于创建修复该问题的合并请求，形成「查重 → 提单 → 修复」的闭环。

和普通工具比强在哪？ 相比手动在 Web 界面点「New issue」，它省掉了页面跳转和表单记忆成本；相比写一段 curl 调 API 的脚本，它不需要你记参数结构和鉴权方式；相比让通用 AI 助手「帮我写一个 Issue 描述」，它能真的把内容提交上去，而不只是产出一段文本。

3. 如何使用该技能？

方式一：直接使用斜杠命令（最常用）

/create-issue

技能会进入引导流程。一次典型的完整交互如下（示例内容参考技能自带示例）：

1. 第一步：提供项目定位。AI 询问「项目 ID 或路径是什么？」，你回答 123 或 my-group%2Fmy-project。
2. 第二步：给出问题标题。AI 询问「问题标题应该是什么？」，你回答 修复图像处理器中的内存泄漏。标题建议写成「动作 + 对象 + 现象」，让人一眼知道要做什么。
3. 第三步：补充问题描述（可选）。你可以按 Enter 跳过，也可以粘贴复现步骤、环境信息、日志片段。
4. 第四步：添加标签（可选）。用逗号分隔，例如 bug, 高优先级, 性能。
5. 第五步：确认并创建。AI 提示「正在项目 123 中创建问题…」，随后通过 GitLab MCP 的 create_issue 工具提交。
6. 第六步：接收结果。返回形如 #42 - 修复图像处理器中的内存泄漏 的问题编号与对应 URL，可直接分享。

方式二：一句话带上关键信息（更省轮次）

在调用后直接把要素说清楚，减少来回问答，例如：

/create-issue 项目 123，标题「登录页在 Safari 下白屏」，描述「Safari 17 打开登录页白屏，控制台报 CORS 错误，Chrome 正常」，标签 bug,前端,兼容性

AI 会基于已有信息直接确认并创建，只对缺失项追问。

方式三：与查重、修复组合使用

先用 /search-issues 搜一下关键词，确认没有重复问题；再 /create-issue 落单；问题进入开发后，用 /create-mr 创建关联的合并请求。这条链路能让「问题」和「代码变更」在 GitLab 中自动关联。

输出说明：成功时返回问题编号 + 问题 URL；如果失败（如 MCP 未连接、鉴权过期、权限不足、项目 ID 无效），需要回到前提条件逐项排查，而不是反复重试同一句话。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
GitLabIssue创建器Skill（create-issue）	对话式 AI 提单助手	引导式收集项目/标题/描述/标签，调用 GitLab MCP create_issue 创建问题并返回编号与 URL	需安装技能 + 配置 GitLab MCP 服务器 + 完成 OAuth 授权 + 具备项目权限	边聊边提单、批量记录反馈、非 GitLab 高频用户快速上手	优势：零表单记忆、闭环在对话内完成、自然语言即可；不足：强依赖 MCP 与授权配置，复杂字段（如里程碑、指派人）未在引导流程中体现
GitLab Web 界面手动创建	官方图形化入口	表单填写全部字段，支持里程碑、指派人、截止日期、附件等	极低，登录即可用	需要完整字段配置的正式需求单	优势：字段最全、可视化最强；不足：页面跳转多、模板合规靠人自觉、移动端或碎片时间体验差
GitLab REST API / curl 脚本	自动化接口调用	通过 HTTP 接口创建 Issue，可脚本化、可批量化	中等偏高，需处理 Token、参数结构、错误码	CI 流水线自动建单、监控告警自动转 Issue	优势：可无人值守、易集成流水线；不足：需要开发维护，非工程人员难以独立使用
glab 命令行工具	官方 CLI 客户端	终端内创建、查看、管理 Issue 与 MR	中等，需安装 CLI 并完成认证登录	习惯终端工作的开发者、脚本化操作	优势：终端不切换上下文、命令可组合；不足：需要记子命令与参数，自然语言表达力弱

怎么选？ 如果你每天泡在终端和 AI 对话里，希望「想到就提」，create-issue 的体验最顺；如果问题单需要填里程碑、指派人等完整字段，Web 界面仍是最稳的兜底；如果是监控告警自动建单或流水线场景，REST API 更合适。

5. 该技能的典型应用场景与实际体验情况

场景一：测试工程师的缺陷快报 测试同学在验证过程中连着发现几个问题，痛点是「切到浏览器提单会打断测试节奏，不记下来又容易漏」。使用方式是在对话里连续输入 /create-issue，把看到的异常口述成标题和描述，标签统一用 bug, 待复现。实际体验：上手难度极低，第一次用几乎不需要学习成本；效果最明显的是「不漏单」和「标题不再敷衍」；注意事项是要提前和团队约定标签命名，否则标签会越用越散。

场景二：项目经理把会议纪要转成任务单 需求评审会后，纪要里往往躺着七八条「要改的地方」。痛点是人工逐条建单耗时，且容易丢掉上下文。使用方式是让 AI 按纪要逐条调用 /create-issue，把背景写进描述，并统一打上 需求, 迭代XX 标签。实际体验：批量场景下收益最大，原本二三十分钟的机械操作被压缩到几分钟；注意事项是描述里应保留「谁提的、为什么改」这类决策信息，否则后期回溯会丢失依据。

场景三：开发者的自发现问题记录 开发在写代码时顺手发现一个历史遗留缺陷，痛点是「现在没空修，过两天就忘了」。使用方式是 /create-issue 快速落单，描述里写上文件路径和推测原因，标签用 技术债。实际体验：这是最顺手的用法，因为只需十几秒就能完成；优势在于问题进入了正式跟踪体系而不再靠记忆；注意事项是描述尽量包含复现路径，否则未来的自己会成为最痛苦的接手人。

场景四：新人快速融入协作流程 新同事不熟悉项目结构，连项目 ID 都要查半天。使用方式是先用 /search-issues 熟悉已有问题的写法，再用 /create-issue 提单，用 URL 编码路径 my-group%2Fmy-project 定位项目。实际体验：学习曲线平缓，引导式问答本身就是一种「团队提单规范」的示范；注意事项是数字项目 ID 查找更快，熟练后建议记住常用项目的 ID。

6. 该技能能为用户带来的价值

• 效率上的直接收益：单次提单从「打开浏览器 → 找项目 → 填四五个字段 → 复制链接」的多步操作，收敛为一次对话。按每次节省 1-2 分钟、团队每天提 10 个问题估算，一个月就能省下数小时纯机械操作时间。
• 质量上的隐性收益：引导式流程天然强制「标题 + 描述 + 标签」三要素，问题单的可读性和可检索性显著提升，减少后续「这个 bug 到底啥现象」的追问成本。
• 门槛上的降低：非工程岗位（产品、运营、设计）不再需要熟悉 GitLab 的界面层级和字段规则，用自然语言描述即可产出规范的问题单，协作参与度更高。
• 流程上的长期价值：/search-issues 查重、/create-issue 落单、/create-mr 关联修复，三件事连成一条轻量闭环，问题从「聊天记录里的碎片」变成「可统计、可追溯、可关联代码」的正式资产。
• 习惯上的正向引导：把「随手记」变成「随手提」，问题在产生的那一刻就进入跟踪体系，减少漏单带来的返工和线上事故风险。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认能用？ A：需要三步——安装技能本体、安装并配置 GitLab MCP 服务器、完成 OAuth 身份验证，并确保你对目标项目有创建问题的权限。具体安装入口与命令请以官方说明为准。验证方式很简单：输入 /create-issue，如果 AI 开始询问「项目 ID 或路径是什么？」，就说明技能已加载成功。

Q2：这个技能收费吗？ A：技能本身是否收费取决于你获取它的技能市场或平台政策，请以官方说明为准。需要提醒的是，实际使用成本还包括你所使用的 AI 客户端订阅、GitLab 实例本身的费用，以及 GitLab MCP 服务器的部署成本（若为自建）。

Q3：我用的不是 gitlab.com，是公司自建 GitLab，能用吗？ A：可以，关键在于把 GitLab MCP 服务器正确指向你们的内网实例，并解决好网络可达性与 OAuth 回调配置。技能本身的逻辑与实例地址无关，它只关心「项目定位 + 标题 + 描述 + 标签」。建议先单独验证 MCP 能连通，再安装技能。

Q4：这个技能适合谁用？不适合谁？ A：最适合日常在 GitLab 上跟踪需求与缺陷、且已经在用 AI 助手工作的人，尤其是测试、产品、项目经理和写代码时顺手记问题的开发者。如果你需要填写里程碑、指派人、截止日期等完整字段，或者所在团队尚未配置 MCP，那么用 GitLab Web 界面或 glab CLI 更直接。

Q5：创建失败怎么办？是不是技能坏了？ A：绝大多数失败不是技能本身的问题，而是前提条件没满足：GitLab MCP 服务器未启动或配置错误、OAuth 授权已过期、账号在目标项目无创建权限、项目 ID 或路径写错。建议按「MCP 连接 → 授权状态 → 项目权限 → 项目标识」的顺序逐项排查。另外，提单前先用 /search-issues 查一下是否已有重复问题，能省下不少无效单。