GitHubIssue自动生成技能Skill 用法详解

GitHubIssue自动生成技能：把一句需求变成 AI 代理可自主执行的完整 GitHub Issue

一句话定位：输入一句需求描述，技能按五步交互追问，输出一份「自包含工作包」级别的 GitHub Issue——包含问题规范、技术规范、TDD 实现计划、验收标准，以及覆盖「实现 → 评审 → 合并」全流程的代理指令。
三大模板：内置「功能 / 错误 / 重构」三类 Issue 模板，根据问题类型自动切换章节结构与标题前缀（feat: / fix: / refactor:）。
不止写 Issue：真正拉开差距的是内置的「代理指令」——它把 PR 生命周期的执行纪律写进 Issue 正文，包括阶段 0 研究、阶段 A 实现、阶段 B 评审迭代、阶段 C 线程解决、阶段 D 合并准备、阶段 E 压缩合并与清理。
调用极简：一个命令 /project:create-issue 即可进入交互流程，无需记忆模板结构。
适合谁用：独立开发者、小团队、开源维护者，以及把需求派给 AI 编程代理执行的团队。

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

基本信息

项目	内容
中文名	GitHubIssue自动生成技能Skill
英文名	create-issue
技能 ID	13662
调用入口	`/project:create-issue`
产出物	结构化的 GitHub Issue（功能 / 错误 / 重构三类模板）

它解决什么问题？

在真实项目里，「写 Issue」往往是效率黑洞，典型痛点有三个：

写得含糊：一句「搜索功能有问题」丢进 Issue 列表，几周后没人知道当时到底想改什么。
写得不成体系：需求、技术方案、测试计划、验收标准分散在文档、聊天记录和脑子里，接手的人要重新拼图。
写给 AI 代理也跑不动：很多团队已经让 AI 代理去实现 Issue，但 Issue 本身没有边界、没有测试规范、没有评审纪律，代理要么跑偏，要么把「能编译」当成「做完了」。

这个技能的解法是：把 Issue 升级为一份自包含的「工作包」。每个 Issue 固定包含五个组成部分——带清晰范围的问题/功能规范、涵盖类型与架构与接口设计的技术规范、采用测试优先循环的 TDD 实现计划、可勾选的验收标准清单，以及覆盖完整 PR 生命周期的代理指令。目标很明确：让无论是人还是 AI 代理，拿到这个 Issue 就能独立开工，不需要再回来问「你当时是什么意思」。

一键安装的思路与步骤

安装环节的具体命令、市场入口与目录路径，本技能详情中未提供，请以官方说明为准。下面给出通用思路，便于你按官方文档对号入座：

确认前提：你的 AI 编码客户端需要支持「技能（Skill）」机制，并且支持以 /project: 为前缀的项目级自定义命令。只要环境支持项目级命令，本技能就能以命令形式被调用。
执行安装：按官方说明完成技能添加（通常是在技能市场/技能列表中搜索英文名 create-issue，或在项目内安装该技能 ID 对应的技能包），随后在项目中确认技能已启用。
验证是否生效：在对话中输入 /project:create-issue。如果技能生效，应当立即看到它的第一步提问——「这是什么类型的问题？」并列出「功能 / 错误 / 重构」三个选项。看到这段交互提示，即说明技能已正常加载。
首次使用建议：先用一个小的功能需求走一遍完整流程（比如「给用户列表加一个按注册时间排序的选项」），确认生成的 Issue 结构符合团队习惯后，再用于正式任务。

说明：技能的安装方式、是否收费、可用客户端范围等，均以官方说明为准；本文只描述技能详情中明确给出的能力。

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

核心功能

五步交互式需求采集：依次确认「问题类型 → 简要描述 → 复杂度评估 → 上下文收集 → 生成 Issue」，把模糊想法逐步逼成可执行规格。复杂度分档为「简单（< 1 天）/ 中等（2–5 天）/ 复杂（> 1 周）」。
支持「探索代码库」：在上下文收集环节，你可以直接回复「探索代码库」，由代理自行调查相关文件、服务与历史 Issue，而不是要求你手动贴一堆路径。
三类专用模板：
- 功能模板：摘要、问题与证据、范围（✅ 范围内 / ❌ 范围外）、架构决策（决策 + 理由）、技术规范（类型定义、Zod 架构、API 端点表、数据库变更）、TDD 实现计划（快乐路径 / 错误处理 / 边界案例 / 集成四个循环）、错误处理表、分阶段实现任务、要创建/修改的文件、验收标准、代理指令。
- 错误模板：标题改为 fix: 前缀，用「错误报告」替换问题章节，包含优先级（P0–P3）、影响用户、首次报告、预期行为、实际行为、重现步骤、根因分析、证据；测试计划改为「验证修复 + 回归测试」两段。
- 重构模板：标题改为 refactor: 前缀，增加「背景」与「正在处理的审查反馈」（可引用原始 PR 与评论者），并在验收标准中追加「不破坏公共 API」「现有测试仍通过」「性能不降低」。
内置完整 PR 生命周期代理指令：这是最具差异化的部分，从阶段 0 的「先读服务清单/服务注册表/模拟工厂/相似服务，避免重复造轮子」，到阶段 A 实现、阶段 B 逐条处理评审评论、阶段 C 解决线程、阶段 D 合并前置检查、阶段 E 压缩合并与分支清理，全部写进 Issue 正文。
评审处理纪律：明确要求把评审评论按「🔴 关键 / 🟡 中等 / 🔵 琐碎挑剔 / 🟣 范围外」分类，其中琐碎评论也要修、范围外评论要彻底调查（技能原话：范围外 = 黄金，通常包含最佳见解）；工作量 < 1 天的当场修，> 1 天或架构性的另开 Issue 并在回复中链接。
生成后自动创建：先展示预览、询问是否需要修改，确认后用 GitHub CLI 创建 Issue 并打标签（enhancement / bug / refactor，配合 complexity: 或 priority: 标签），最后回报 Issue 编号。

和普通工具的差别在哪

普通 Issue 模板只解决「格式统一」，普通 AI 对话只解决「帮你写一段文字」。这个技能多做了两件事：一是把技术规范与 TDD 计划变成 Issue 的强制组成部分，让「怎么测」先于「怎么写」；二是把执行纪律写进 Issue，让 AI 代理在无人盯着的情况下也知道什么叫做完——比如「推送代码后不要标记完成，必须等待代码评审」「所有审查线程解决前 PR 不算完整」。

3. 如何使用该技能？

标准使用流程

发起命令。在项目对话中输入：
```
/project:create-issue
```
回答问题类型。技能会问「这是什么类型的问题？」并给出三个选项：功能 / 错误 / 重构。选择后，后续模板会自动切换。
给出 1–2 句简要描述。例如：想给用户列表加一个按注册时间倒序排列的选项，并记住用户上次的选择。
选择复杂度。简单（< 1 天）/ 中等（2–5 天）/ 复杂（> 1 周）。这个选择会影响 Issue 中任务的拆分粒度。
提供上下文。可以贴相关文件路径、服务名、历史 Issue 编号；如果一时说不清，直接回复「探索代码库」，让代理自己去调查。
预览并确认。技能生成完整 Issue 正文后先给你看预览，并询问是否需要修改。此时可以针对「范围外」「验收标准」「实现阶段拆分」等章节提修改意见。
创建 Issue。确认后由技能调用 GitHub CLI 创建，并按类型打标签。错误类型的参考命令形式如下（来自技能详情）：
```
gh issue create --title "fix: [标题]" --body "[内容]" \
  --label "bug" --label "priority:[级别]"
```
功能类型则使用 --label "enhancement" 与 --label "complexity:[级别]"，重构类型使用 --label "refactor"。
拿到 Issue 编号。技能会回报新 Issue 的编号，可直接转给同事或交给 AI 代理执行。

输入输出示例（功能类）

假设你输入：

类型：功能
描述：用户列表增加按注册时间排序并记忆选择
复杂度：中等（2–5 天）
上下文：探索代码库

那么生成的 Issue 会呈现为这样的骨架（节选）：

摘要：1–2 句描述 + 复杂度标注 + 预计工作量
问题：为什么需要这个排序能力、证据来源
范围：✅ 范围内——列表排序控件、本地记忆用户选择；❌ 范围外——服务端排序参数重构
架构决策：采用哪种方案，以及为什么不选替代方案
技术规范：关键类型定义、可选的 Zod 校验架构、API 端点表格、数据库变更说明
TDD 实现计划：循环 1 快乐路径、循环 2 错误处理、循环 3 边界案例、循环 4 集成
验收标准：包含「零 TypeScript 错误 pnpm typecheck」「零 lint 警告 pnpm lint」「所有测试通过 pnpm test --run」等可勾选项
代理指令：阶段 0 到阶段 E 的完整执行协议

使用小技巧

描述里带上一句话业务价值（「因为运营每周要人工翻页找新用户」），生成出的「问题」章节会更有说服力。
复杂任务建议在上下文环节明确列出「不做什么」，让「范围外」清单更可靠。
验收标准里的命令是技能给出的示例（pnpm typecheck / pnpm lint / pnpm test --run），如果你的项目用其他包管理器或脚本名，请在预览阶段改成自己的命令。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势	不足
create-issue（本技能）	面向 AI 代理执行的 Issue 生成器	三类模板 + 五步交互 + 技术规范 + TDD 计划 + 验收标准 + PR 全生命周期代理指令 + 自动创建打标签	需支持技能机制与 `/project:` 项目命令的客户端，装好后一条命令即可（安装细节以官方说明为准）	需要把需求交给 AI 代理端到端实现的团队；技术债与重构管理	产出物信息密度高、可直接驱动代理执行；把评审纪律固化进文档	结构较重，一行小改动也会生成较长正文；强依赖 GitHub 工作流与 CLI
GitHub Issue 模板 / Issue Forms	平台原生模板	固定字段、必填校验、标签自动带上	零安装，仓库内放模板文件即可	只想统一格式、规范填写	原生、稳定、零成本	不含技术规范与测试计划，不含代理指令；填完仍是「人写的需求」，AI 未必能直接执行
通用 AI 对话直接写 Issue	通用写作辅助	生成一段结构尚可的 Issue 文本	零门槛，随手可用	临时、轻量、一次性需求	灵活、上手最快	结构不稳定、每次质量波动大；不会追问复杂度与上下文；不会自动创建与打标签；缺少可执行的代理协议
AI 编程代理自动提 PR	从需求直达代码	直接生成代码与 PR	需配置仓库权限与运行环境	边界清晰的小改动	链路最短	跳过「问题定义」与「测试先行」，需求偏差难追溯；评审反馈处理缺乏统一纪律

怎么选：如果只是想统一 Issue 格式，用 GitHub 原生模板就够了；如果只想要一段能看的文字，通用 AI 对话更快；但如果你的目标是让 AI 代理按纪律把一个需求从实现做到合并，本技能的价值点——技术规范、TDD 计划、验收标准、代理指令四件套——是其他方案普遍缺失的部分。

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

场景一：独立开发者 / 小团队承接需求

角色与痛点：一个人既要写需求又要写代码，Issue 常常只写一句标题，三天后自己都看不懂；或者干脆不写 Issue，全靠记忆。
使用方式：每次开工前跑一遍 /project:create-issue，选「功能」，两句话描述需求，复杂度选「简单」，上下文回复「探索代码库」。
实际体验：上手几乎无门槛，五步问答像填表一样走完。最大收益是「范围外」清单——它逼你在动手前明确「这次不做什么」，避免小需求越做越大。需要注意的是，简单需求也会生成较完整的正文，长文档可能显得有点「重」，可以在预览阶段删减不需要的章节。

场景二：开源项目维护者处理外部 Issue

角色与痛点：社区提交的 Issue 常常只有截图和一句「不工作」，需要维护者反复追问重现步骤、影响范围、优先级。
使用方式：用「错误」模板重建 Issue：选类型「错误」，把用户描述贴进去，复杂度按影响面判断，上下文里引用相关 Issue 编号。生成的「错误报告」章节会自动带上优先级（P0–P3）、预期行为、实际行为、重现步骤、根因分析、证据六个栏目。
实际体验：把「追问」变成「填空」，维护者的沟通成本明显下降。测试计划部分会自动区分「验证修复」与「回归测试」两类用例，这对「改一个地方坏三个地方」的老项目尤其有用。注意根因分析如果你不清楚，可以留待实现阶段补充，不必勉强编造。

场景三：给 AI 编程代理派活

角色与痛点：技术负责人想让代理自动完成一批中等规模任务，但代理常常「写完就宣布完成」，评审评论不处理，琐碎意见直接忽略，PR 拖着不合。
使用方式：用本技能生成 Issue 后再交给代理。Issue 内的代理指令已经写死了执行协议：阶段 0 先读服务清单、服务注册表、模拟工厂与相似服务，避免重复造轮子；阶段 A 执行 TDD 循环并跑本地校验；阶段 B 逐条处理评审评论，包括「🔵 琐碎/挑剔」与「🟣 范围外」，并用 gh api 逐个线程回复；阶段 C 等审查者批准后再解决线程；阶段 D 做合并前置检查；阶段 E 坚持压缩合并（gh pr merge $PR_NUMBER --squash --delete-branch），从不使用常规合并。
实际体验：这是本技能最能体现差异化的场景。协议写得非常具体，连「推送代码后不要标记完成」「不要自己解决线程」这类容易被忽略的纪律都点名了。注意事项是：这套流程假设项目使用 GitHub CLI、有 CI 检查，且团队认同「琐碎评论也要修」的严格标准，落地前建议先和团队对齐。

场景四：重构与技术债清理

角色与痛点：重构类工作最难的是「说不清为什么改」和「改完怎么证明没改坏」。
使用方式：选「重构」模板，在「背景」里写清触发原因，并把原始 PR 与评论者引用进「正在处理的审查反馈」。验收标准会自动追加「不破坏公共 API」「所有现有测试仍通过，无需修改」「性能不降低（如果适用）」三条。
实际体验：把「评审里的一句建议」变成可追踪的重构 Issue，链接关系一目了然。三条额外验收标准直接对着重构最怕的三件事，实用性很高。

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

把「需求澄清」前置，降低返工率：五步交互逼着你在写代码之前回答类型、复杂度、上下文三个关键问题，「范围外」章节把边界固定下来。返工通常源于需求漂移，而漂移往往源于一开始没把边界写清。
显著提升 Issue 的信息密度：一份生成的 Issue 同时承载问题规范、技术规范、TDD 计划、验收标准与执行协议，等于把「需求文档 + 技术方案 + 测试计划 + 项目规范」压缩进一个链接。团队沟通可以直接贴 Issue 编号。
降低 AI 代理的使用门槛：过去要让代理可靠干活，需要资深工程师反复写提示词、盯着它别偷懒。本技能把这些纪律固化成模板里的固定章节，一次生成、长期复用。
把代码质量要求变成可勾选项：零 TypeScript 错误、零 lint 警告、测试全绿、JSDoc 文档、服务清单与注册表更新、模拟工厂维护——这些容易被跳过的收尾动作，在验收标准里都是复选框，跑没跑一目了然。
长期价值：形成可复用的组织资产：每次生成的 Issue 都是一份格式统一的历史记录。半年后回看，能清楚知道当时为什么这样决策、范围划在哪、测试覆盖了哪些场景。对新人接手和项目复盘，价值远超「省下的那十分钟写文档时间」。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认生效？

A：安装方式以官方说明为准（技能市场中搜索英文名 create-issue，或按技能 ID 13662 对应的官方指引添加）。你的客户端需要支持技能机制和 /project: 项目级命令。验证方法很简单：输入 /project:create-issue，如果出现「这是什么类型的问题？」并列出「功能 / 错误 / 重构」三个选项，就说明已生效。

Q2：收费吗？

A：本文所依据的技能详情中未提及定价信息，是否收费、是否有免费额度，请以官方说明为准。可以确定的是，技能本身依赖 GitHub 与 GitHub CLI（gh）完成 Issue 创建、评论回复、线程解决与合并操作，这些是 GitHub 侧的能力。

Q3：适合谁用？小项目用会不会太重？

A：最适合三类人：需要把需求派给 AI 代理端到端实现的团队、Issue 质量参差的开源维护者、以及技术债较多的项目。小改动确实会显得「重」——一份完整 Issue 可能比代码本身还长。建议做法是：小改动在预览阶段删掉不需要的章节（比如数据库变更、API 端点表），只保留问题、范围、验收标准和代理指令四块。

Q4：和直接用 GitHub Issue 模板、或者让 AI 随手写一段，有什么区别？

A：原生模板解决「格式统一」，通用 AI 对话解决「帮你写文字」，本技能解决的是「让 Issue 能被执行」。差别集中在两点：一是强制包含技术规范与 TDD 实现计划，测试先行；二是内置覆盖实现到合并的代理指令，包含评审评论分类处理、线程解决时机、压缩合并等具体纪律。如果只是记录一个想法，用原生模板更方便；如果要把 Issue 交给代理自动完成，本技能的产出物信息完整度明显更高。

Q5：生成的验收标准里那些命令（如 pnpm typecheck）和我项目不一致怎么办？

A：这些命令是技能模板中给出的示例，属于可编辑内容。技能的流程本身支持「先展示预览、再询问是否需要修改」，在预览阶段把包管理器、脚本名、文档路径改成你项目实际使用的即可。同理，代理指令中引用的服务清单、服务注册表、模拟工厂等路径，也应按你仓库的真实结构调整后再创建 Issue。