使用 awesome-copilot 技能将未实现规范需求自动转成 GitHub Issue【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot在基于规范驱动的开发spec-driven development流程中规范specification文件定义了需求的应然而代码库则反映需求的实然。两者之间的落差——那些尚未实现的需求——往往以零散、不可追踪的形式散落在讨论与记忆中。本指南介绍的create-github-issues-for-unmet-specification-requirements技能位于 skills/create-github-issues-for-unmet-specification-requirements/SKILL.md正是为此而设计它让 Agent 读取规范文件、逐条核对代码库实现状态、去重后为每一个未实现需求创建一条结构化 GitHub Issue。读完本指南你将掌握从规范到 Issue 的完整自动化闭环并能结合本仓库的配套技能create-specification、create-implementation-plan、github-issues落地一套可追溯的规范 → 需求追踪 → 实现计划工作流。技能定位与核心目标该技能的本质是一条可复用的 Agent 指令集给定一个规范文件路径以${file}占位符传入Agent 需要执行一个规范缺口分析specification gap analysis即找出规范中所有尚未在代码库中实现的需求并为其中每一条创建独立的 GitHub Issue。这与仓库中另外两个相近技能形成互补create-github-issue-feature-from-specification为整个规范创建一个汇总型 Issuecreate-github-issues-feature-from-implementation-plan按实现计划的阶段为每个阶段创建 Issue本技能unmet specification requirements按未实现需求逐条创建 Issue粒度最细聚焦缺口而非全量。三者的共同点在于都依赖search_issues去重、create_issue创建、以及feature_request.yml或chore_request.yml模板兜底使用方式与触发场景可对照 docs/README.skills.md 中的技能清单。完整执行流程Process技能定义了一个五步流水线每一步都有明确职责分析规范文件提取全部需求完整阅读${file}指向的规范逐条抽取需求包括需求 ID、描述、约束、验收标准。核对代码库实现状态对每条需求在代码库中检索对应的代码模式判断其是已实现、部分实现还是未实现。这正是本技能区别于把整个规范转成一个 Issue的关键——它要求先做实现审计。使用search_issues搜索既有 Issue 以避免重复在创建之前先搜索仓库中是否已存在覆盖相同需求的 Issue防止重复劳动与噪音。为每条未实现需求使用create_issue创建新 Issue每条需求对应一条独立 Issue保证可单独追踪、指派与关闭。使用feature_request.yml模板找不到时回退到默认模板优先套用仓库配置的功能请求表单模板若仓库未配置该模板则退回到 GitHub 默认 Issue 表单。需求与质量门槛Requirements技能对创建过程施加了四条硬性约束它们共同保证了 Issue 的质量与可追踪性约束说明价值每条未实现需求一条 Issue一需求一 Issue不做合并单一职责便于指派、状态追踪与关闭明确的需求 ID 与描述映射Issue 中必须携带规范中的需求 ID如REQ-001实现与规范的对应关系可追溯包含实现指引与验收标准描述中写入实现方法Implementation method与验收标准Acceptance Criteria开发者可直接按 Issue 开工创建前与既有 Issue 核对先search_issues再create_issue避免重复 Issue 污染看板其中需求 ID这一设计直接呼应了 create-specification 技能规定的规范模板——该模板明确要求使用REQ-001、SEC-001、CON-001、GUD-001、PAT-001等标准化前缀来声明需求。也就是说规范在前端用编号化 ID 定义需求本技能在后端用这些 ID 建立 Issue 与规范之间的双向映射形成一条完整的追踪链。Issue 内容规范Issue Content技能规定了每条 Issue 的标准三要素标题Title需求 ID 简短描述。例如REQ-003: 实现用户头像上传。标题继承了 github-issues 的标题准则——具体、可执行、不超过 72 字符、避免冗余前缀。描述Description详细需求、实现方法与上下文。建议按 github-issues/references/templates.md 中的 Feature Request 模板组织包含## Summary、## Motivation、## Proposed Solution、## Acceptance Criteria、## Alternatives Considered等区块。标签Labelsfeature、enhancement视情况选择。github-issues 同时提示若组织配置了 Issue Type如Feature应优先使用type参数而非等价标签标签仅在无 Issue Type 时作为兜底。实现检查Implementation Check这是本技能最具操作性的部分决定了哪些需求算未实现。技能给出的检查方法是三管齐下搜索代码库中相关的代码模式针对每条需求检索可能存在的实现痕迹例如函数名、类名、接口、配置键等。检查/spec/目录下的相关规范文件除了${file}本身还要顺带查看/spec/目录中其他相关规范避免因规范间相互引用而误判需求状态。确认需求并非部分实现这是最容易被忽略的坑——代码里可能已有 80% 的实现仅缺个别边界条件或接口。技能明确要求验证需求是否被部分实现从而决定是创建新 Issue 还是补充既有工作。这一步骤本质上是一个证据收集过程Agent 必须基于代码库中实际存在的符号、文件和配置作出判断而不是凭规范文本猜测。判断为未实现的需求才会进入 Issue 创建阶段。底层支撑GitHub Issues 技能与工具链本技能描述中出现的search_issues、create_issue属于 GitHub MCP 服务器modelcontextprotocol/server-github提供的能力完整用法记录在 skills/github-issues/SKILL.md 中。该技能同时给出了不依赖 MCP 的 CLI 等价方案即gh api# 创建 Issue支持 Issue Type 参数 gh api repos/{owner}/{repo}/issues \ -X POST \ -f titleREQ-003: 实现用户头像上传 \ -f typeFeature \ -f labels[]enhancement \ -f body## Summary ...Feature Request 模板内容 ## Acceptance Criteria - [ ] 支持上传与裁剪 - [ ] 校验文件类型与大小 \ --jq {number, html_url} # 检索既有 Issue 以避免重复 gh search issues --repo {owner}/{repo} REQ-003需要注意两点操作细节均来自 skills/github-issues/SKILL.md引号问题zshmacOS 默认 shell会把未加引号的labels[]bug当作 glob 通配符导致命令失败必须整体加引号写成-f labels[]enhancement创建前先读更新 Issue 前应先用issue_read/gh api拉取当前内容避免覆盖未修改字段。如何在规范驱动工作流中组合使用本技能不是孤立存在的它位于仓库规范 → 实现计划 → 需求追踪的工具链末端。推荐的工作流闭环如下用 create-specification 生成 AI 友好的规范文件保存到/spec/spec-xxx.md其中每条需求以REQ-NNN编号并在末尾定义AC-NNN验收标准用 create-implementation-plan 生成分阶段实现计划保存到/plan/目录用本技能扫描规范 vs 代码的缺口为每个未实现需求创建可追踪的 Issue用 github-issues 管理这些 Issue 的状态、标签、里程碑与依赖关系。这样的组合让规范中的一行需求与看板上的一张卡片之间始终保持一一对应需求实现完成、验收通过后对应 Issue 即可关闭规范与代码重新回到一致状态下次再运行本技能该需求会因已实现而自动跳过从而让缺口清单保持精确。使用前提与限制前置条件仓库需配置 GitHub MCP 服务器search_issues/create_issue或可用的ghCLI 与相应仓库权限仓库需存在/spec/目录及规范文件。模板依赖feature_request.yml属于仓库级配置未配置时技能会回退到默认模板Issue 结构化程度会降低。判断边界是否已实现依赖 Agent 对代码库的检索质量部分实现的判定尤其需要人工复核建议在生成 Issue 后由维护者抽查确认。只读约束本技能仅创建/检索 GitHub Issue不修改规范文件与代码库本身对规范与代码的修改请走常规 PR 流程。通过上述步骤你可以把需求遗漏这个开发流程中最常见的隐性成本转化为一张张清晰、可指派、可验收的 GitHub Issue让规范驱动开发真正做到闭环可追踪。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 awesome-copilot 技能将未实现规范需求自动转成 GitHub Issue
使用 awesome-copilot 技能将未实现规范需求自动转成 GitHub Issue【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot在基于规范驱动的开发spec-driven development流程中规范specification文件定义了需求的应然而代码库则反映需求的实然。两者之间的落差——那些尚未实现的需求——往往以零散、不可追踪的形式散落在讨论与记忆中。本指南介绍的create-github-issues-for-unmet-specification-requirements技能位于 skills/create-github-issues-for-unmet-specification-requirements/SKILL.md正是为此而设计它让 Agent 读取规范文件、逐条核对代码库实现状态、去重后为每一个未实现需求创建一条结构化 GitHub Issue。读完本指南你将掌握从规范到 Issue 的完整自动化闭环并能结合本仓库的配套技能create-specification、create-implementation-plan、github-issues落地一套可追溯的规范 → 需求追踪 → 实现计划工作流。技能定位与核心目标该技能的本质是一条可复用的 Agent 指令集给定一个规范文件路径以${file}占位符传入Agent 需要执行一个规范缺口分析specification gap analysis即找出规范中所有尚未在代码库中实现的需求并为其中每一条创建独立的 GitHub Issue。这与仓库中另外两个相近技能形成互补create-github-issue-feature-from-specification为整个规范创建一个汇总型 Issuecreate-github-issues-feature-from-implementation-plan按实现计划的阶段为每个阶段创建 Issue本技能unmet specification requirements按未实现需求逐条创建 Issue粒度最细聚焦缺口而非全量。三者的共同点在于都依赖search_issues去重、create_issue创建、以及feature_request.yml或chore_request.yml模板兜底使用方式与触发场景可对照 docs/README.skills.md 中的技能清单。完整执行流程Process技能定义了一个五步流水线每一步都有明确职责分析规范文件提取全部需求完整阅读${file}指向的规范逐条抽取需求包括需求 ID、描述、约束、验收标准。核对代码库实现状态对每条需求在代码库中检索对应的代码模式判断其是已实现、部分实现还是未实现。这正是本技能区别于把整个规范转成一个 Issue的关键——它要求先做实现审计。使用search_issues搜索既有 Issue 以避免重复在创建之前先搜索仓库中是否已存在覆盖相同需求的 Issue防止重复劳动与噪音。为每条未实现需求使用create_issue创建新 Issue每条需求对应一条独立 Issue保证可单独追踪、指派与关闭。使用feature_request.yml模板找不到时回退到默认模板优先套用仓库配置的功能请求表单模板若仓库未配置该模板则退回到 GitHub 默认 Issue 表单。需求与质量门槛Requirements技能对创建过程施加了四条硬性约束它们共同保证了 Issue 的质量与可追踪性约束说明价值每条未实现需求一条 Issue一需求一 Issue不做合并单一职责便于指派、状态追踪与关闭明确的需求 ID 与描述映射Issue 中必须携带规范中的需求 ID如REQ-001实现与规范的对应关系可追溯包含实现指引与验收标准描述中写入实现方法Implementation method与验收标准Acceptance Criteria开发者可直接按 Issue 开工创建前与既有 Issue 核对先search_issues再create_issue避免重复 Issue 污染看板其中需求 ID这一设计直接呼应了 create-specification 技能规定的规范模板——该模板明确要求使用REQ-001、SEC-001、CON-001、GUD-001、PAT-001等标准化前缀来声明需求。也就是说规范在前端用编号化 ID 定义需求本技能在后端用这些 ID 建立 Issue 与规范之间的双向映射形成一条完整的追踪链。Issue 内容规范Issue Content技能规定了每条 Issue 的标准三要素标题Title需求 ID 简短描述。例如REQ-003: 实现用户头像上传。标题继承了 github-issues 的标题准则——具体、可执行、不超过 72 字符、避免冗余前缀。描述Description详细需求、实现方法与上下文。建议按 github-issues/references/templates.md 中的 Feature Request 模板组织包含## Summary、## Motivation、## Proposed Solution、## Acceptance Criteria、## Alternatives Considered等区块。标签Labelsfeature、enhancement视情况选择。github-issues 同时提示若组织配置了 Issue Type如Feature应优先使用type参数而非等价标签标签仅在无 Issue Type 时作为兜底。实现检查Implementation Check这是本技能最具操作性的部分决定了哪些需求算未实现。技能给出的检查方法是三管齐下搜索代码库中相关的代码模式针对每条需求检索可能存在的实现痕迹例如函数名、类名、接口、配置键等。检查/spec/目录下的相关规范文件除了${file}本身还要顺带查看/spec/目录中其他相关规范避免因规范间相互引用而误判需求状态。确认需求并非部分实现这是最容易被忽略的坑——代码里可能已有 80% 的实现仅缺个别边界条件或接口。技能明确要求验证需求是否被部分实现从而决定是创建新 Issue 还是补充既有工作。这一步骤本质上是一个证据收集过程Agent 必须基于代码库中实际存在的符号、文件和配置作出判断而不是凭规范文本猜测。判断为未实现的需求才会进入 Issue 创建阶段。底层支撑GitHub Issues 技能与工具链本技能描述中出现的search_issues、create_issue属于 GitHub MCP 服务器modelcontextprotocol/server-github提供的能力完整用法记录在 skills/github-issues/SKILL.md 中。该技能同时给出了不依赖 MCP 的 CLI 等价方案即gh api# 创建 Issue支持 Issue Type 参数 gh api repos/{owner}/{repo}/issues \ -X POST \ -f titleREQ-003: 实现用户头像上传 \ -f typeFeature \ -f labels[]enhancement \ -f body## Summary ...Feature Request 模板内容 ## Acceptance Criteria - [ ] 支持上传与裁剪 - [ ] 校验文件类型与大小 \ --jq {number, html_url} # 检索既有 Issue 以避免重复 gh search issues --repo {owner}/{repo} REQ-003需要注意两点操作细节均来自 skills/github-issues/SKILL.md引号问题zshmacOS 默认 shell会把未加引号的labels[]bug当作 glob 通配符导致命令失败必须整体加引号写成-f labels[]enhancement创建前先读更新 Issue 前应先用issue_read/gh api拉取当前内容避免覆盖未修改字段。如何在规范驱动工作流中组合使用本技能不是孤立存在的它位于仓库规范 → 实现计划 → 需求追踪的工具链末端。推荐的工作流闭环如下用 create-specification 生成 AI 友好的规范文件保存到/spec/spec-xxx.md其中每条需求以REQ-NNN编号并在末尾定义AC-NNN验收标准用 create-implementation-plan 生成分阶段实现计划保存到/plan/目录用本技能扫描规范 vs 代码的缺口为每个未实现需求创建可追踪的 Issue用 github-issues 管理这些 Issue 的状态、标签、里程碑与依赖关系。这样的组合让规范中的一行需求与看板上的一张卡片之间始终保持一一对应需求实现完成、验收通过后对应 Issue 即可关闭规范与代码重新回到一致状态下次再运行本技能该需求会因已实现而自动跳过从而让缺口清单保持精确。使用前提与限制前置条件仓库需配置 GitHub MCP 服务器search_issues/create_issue或可用的ghCLI 与相应仓库权限仓库需存在/spec/目录及规范文件。模板依赖feature_request.yml属于仓库级配置未配置时技能会回退到默认模板Issue 结构化程度会降低。判断边界是否已实现依赖 Agent 对代码库的检索质量部分实现的判定尤其需要人工复核建议在生成 Issue 后由维护者抽查确认。只读约束本技能仅创建/检索 GitHub Issue不修改规范文件与代码库本身对规范与代码的修改请走常规 PR 流程。通过上述步骤你可以把需求遗漏这个开发流程中最常见的隐性成本转化为一张张清晰、可指派、可验收的 GitHub Issue让规范驱动开发真正做到闭环可追踪。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考