GitHub Copilot 项目规划流水线awesome-copilot 的 project-planning 插件实战指南【免费下载链接】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本文基于 awesome-copilot 仓库中的 project-planning 插件系统讲解如何利用该插件在 GitHub Copilot 中构建「Epic 拆解 → 需求文档 → 架构设计 → 实施计划 → GitHub Issues → 技术验证」的完整项目规划闭环。读完本文你将掌握 8 个斜杠命令与 7 个规划类 Agent 的定位与用法理解底层agent.md与 skill 的协作机制并能在团队中直接落地一套可复制的规划工作流。一、插件定位把规划变成 Copilot 的专项能力软件团队在启动一个功能或重构任务时往往卡在想法到可执行计划的鸿沟上Epic 没人拆、PRD 写不完整、实施计划停留在口头、技术风险无人验证。awesome-copilot 社区仓库中的project-planning插件plugins/project-planning/README.md正是为此设计——它为 GitHub Copilot 注入了一套面向软件项目规划、特性拆解、Epic 管理、实施计划与任务组织的工具集和智能体。从插件的清单文件 plugin.json 可以看到该插件的声明信息如下字段值名称project-planning版本1.0.0作者Awesome Copilot Community许可证MIT关键词planning、project-management、epic、feature、implementation、task、architecture、technical-spike插件在extensions.com.github.awesome-copilot命名空间下挂载了两类资产7 个 Agent./agents/*.md与8 个 Skill./skills/*/二者分别对应角色化智能体与斜杠命令提示词两种使用形态共同构成完整的规划能力矩阵。二、安装一条命令接入该插件通过 Copilot CLI 安装命令来自 插件 READMEcopilot plugin install project-planningawesome-copilot安装完成后Copilot 会话中即可使用project-planning:前缀的斜杠命令并可在 Agent 选择器中调用本插件的规划类 Agent。仓库根目录的mcp.json、package.json等文件表明该仓库本身是可复现的 Node.js 工程但插件使用不需要任何额外编译——它完全由 Markdown 提示词驱动。三、斜杠命令Slash Commands8 个命令覆盖全生命周期插件提供了 8 个斜杠命令对应 8 个 skill 提示词。下表汇总了各命令的职责随后逐一展开命令职责/project-planning:breakdown-epic-pm基于一个 Epic 想法产出 Epic 级 PRD/project-planning:breakdown-epic-arch基于 Epic PRD产出高层技术架构规范/project-planning:breakdown-feature-prd基于 Epic为单个特性产出详细 PRD/project-planning:breakdown-feature-implementation基于功能 PRD产出详细实施计划遵循 Epoch monorepo 结构/project-planning:create-implementation-plan为新增特性/重构/升级/设计/架构/基础设施创建实施计划文件/project-planning:update-implementation-plan用新需求更新既有实施计划文件/project-planning:create-github-issues-feature-from-implementation-plan按实施计划的阶段用feature_request.yml或chore_request.yml模板创建 GitHub Issues/project-planning:create-technical-spike创建有时限的技术 Spike 文档用于在实现前研究并解决关键决策3.1 breakdown-epic-pm把想法固化为 Epic PRD命令 prompt 见 skills/breakdown-epic-pm/SKILL.md。该 skill 让 Copilot 扮演大型 SaaS 平台的资深产品经理将用户的高层想法翻译为 Epic 级 PRD并明确该 PRD 将作为生成技术架构规范的输入。信息不足时要求先提问澄清。产出一份完整的 Epic PRD保存到/docs/ways-of-work/plan/{epic-name}/epic.md包含 8 个部分Epic 名称、目标问题/方案/影响、用户画像、高层用户旅程、业务需求功能 非功能、成功指标KPI、范围外事项防 Scope 蔓延、业务价值评估。3.2 breakdown-epic-arch从 PRD 推导高层架构命令 prompt 见 skills/breakdown-epic-arch/SKILL.md。该 skill 让 Copilot 以资深软件架构师身份基于 Epic PRD 输出高层技术架构规范产物保存为/docs/ways-of-work/plan/{epic-name}/arch.md。其约束上下文明确了一个典型的技术栈假设领域驱动架构Domain-driven、自托管与 SaaS 双模式部署、全服务 Docker 容器化、TypeScript/Next.js App Router、Turborepo monorepo、tRPC 类型安全 API、Stack Auth 认证——使用前需确认与团队实际栈是否一致。架构规范要求产出 6 部分内容Epic 架构总览技术方案摘要系统架构图用 Mermaid 图呈现五层结构——用户层浏览器/移动端/管理界面、应用层负载均衡、应用实例、Stack Auth、服务层tRPC API、后台服务、n8n 工作流、数据层PostgreSQL、Qdrant 向量库、Redis 缓存、外部 API、基础设施层Docker 容器化与部署要求用子图分层、统一配色、标注数据流含同步请求与异步处理两类路径高层特性与技术使能项要构建的特性清单以及支撑特性所需的新服务/库/基础设施技术栈关键技术、框架与库技术价值High/Medium/Low 评估并附理由T-Shirt 尺寸估算S/M/L/XL 级别的规模预判。同时约定除非技术情境需要伪代码否则不输出实际代码。3.3 breakdown-feature-prd为单个特性撰写详细 PRD命令 prompt 见 skills/breakdown-feature-prd/SKILL.md。该 skill 承接 Epic将 Epic 中的某个高层特性/使能项细化为特性级 PRD作为工程团队的唯一事实来源并作为后续技术规格生成的输入。产物保存为/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md包含特性名称、父级 Epic链接回 Epic PRD 与架构文档、目标、用户画像、用户故事统一采用 As apersona, I want toactionso that I canbenefit 格式并覆盖主路径与边界情况、需求功能 非功能、验收标准采用清单或 Given/When/Then 格式以便验证、范围外事项。3.4 breakdown-feature-implementation产出落地级实施计划命令 prompt 见 skills/breakdown-feature-implementation/SKILL.md。该 skill 让 Copilot 以行业资深工程师身份基于功能 PRD 输出可直接执行的技术实施计划保存为/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md。其文件系统约定遵循Epoch monorepo 结构apps/ [app-name]/ services/ [service-name]/ packages/ [package-name]/实施计划要求覆盖以下技术决策面目标与需求特性目标3-5 句与详细需求清单系统架构Mermaid 五层架构图前端层/API 层/业务逻辑层/数据层/基础设施层标注请求-响应、数据转换与事件流技术栈选型理由、集成边界与通信协议、Docker 部署策略、水平/垂直扩展方案数据库 Schema 设计Mermaid ER 图含字段定义类型与约束、索引策略、外键关系、数据库迁移策略API 设计端点完整规格、带 TypeScript 类型的请求/响应格式、基于 Stack Auth 的认证授权、错误处理与状态码、限流与缓存策略前端架构基于shadcn/ui的组件层级文档含布局结构示例、Mermaid 状态流图、Zustand/React Query 状态管理模式、TypeScript 接口安全与性能认证/授权要求、数据校验与净化、性能优化策略、缓存机制。3.5 create / update-implementation-plan实施计划的创建与演进这两个命令对应的 skillskills/create-implementation-plan/、skills/update-implementation-plan/负责创建新的实施计划文件与用新增/变更需求更新既有计划覆盖范围包括新特性、既有代码重构、依赖升级、设计、架构或基础设施。update命令解决了规划文档的保鲜问题——需求变更时无需推倒重来而是增量演进。3.6 create-github-issues-feature-from-implementation-plan计划到 Issue 的自动化该命令将实施计划中的**阶段Phase**批量转换为 GitHub Issues并支持feature_request.yml与chore_request.yml两类模板从而让计划 → 跟踪两个环节无缝衔接。这解释了为什么实施计划要按原子阶段组织——阶段即 Issue 的粒度来源详见下文 3.8 与第五节的完整流水线。3.7 create-technical-spike用 Spike 消解技术不确定性该命令用于创建有时间盒time-boxed的技术 Spike 文档专门针对实现前的关键开发决策做研究验证。与之配套的 Agent 是research-technical-spike见 agents/research-technical-spike.agent.md二者形成创建文档 → 系统化验证的闭环属于插件中验证优先路线的核心资产。3.8 斜杠命令背后的目录约定从 plugin.json 可以看出8 个命令与 8 个 skill 一一对应命令底层 skill 目录breakdown-epic-pmskills/breakdown-epic-pm/breakdown-epic-archskills/breakdown-epic-arch/breakdown-feature-prdskills/breakdown-feature-prd/breakdown-feature-implementationskills/breakdown-feature-implementation/create-implementation-planskills/create-implementation-plan/update-implementation-planskills/update-implementation-plan/create-github-issues-feature-from-implementation-planskills/create-github-issues-feature-from-implementation-plan/create-technical-spikeskills/create-technical-spike/每个 skill 目录均为单SKILL.md文件采用 frontmatternamedescription声明元数据正文即提示词主体——这正是斜杠命令 可复用提示词的仓库级实现形态。四、Agent 角色体系7 个规划智能体除命令外插件还提供 7 个 Agent。其中task-planner与task-researcher由microsoft/edge-ai贡献planner、plan、prd、implementation-plan、research-technical-spike为社区贡献。下表为概览Agent定位task-researcher任务研究专家负责全面项目分析edge-ai 出品task-planner任务规划者产出可执行的实施计划edge-ai 出品planner为新特性或重构生成实施计划plan战略规划与架构助手强调实现前的深入思考prd生成结构化、可行动的 PRD可选创建 GitHub Issuesimplementation-plan面向 AI 执行优化的实施计划生成research-technical-spike系统性研究并验证技术 Spike 文档4.1 task-researcher只研究、不写代码的专项角色完整指令见 agents/task-researcher.agent.md。该 Agent 是纯研究角色唯一职责是在./.copilot-tracking/research/下创建/更新研究文档禁止改动任何源码与配置。其核心约束包括只记录经实际工具使用验证的发现绝不基于假设输出必须跨多个权威来源交叉验证发现新方案后立即删除过时信息杜绝重复内容研究过程提供多个备选方案并引导用户收敛到唯一推荐方案。研究文件遵循命名规范YYYYMMDD-task-description-research.md专题研究为YYYYMMDD-topic-specific-research.md并使用固定的研究模板包含Research Executed文件分析/代码搜索/外部研究/项目约定→ Key Discoveries项目结构/实现模式/完整示例/API 与 Schema/配置示例/技术要求→ Recommended Approach → Implementation Guidance等区块。4.2 task-planner基于已验证研究的三件套规划器完整指令见 agents/task-planner.agent.md。该 Agent 的硬性前置条件是任何规划活动前必须先验证./.copilot-tracking/research/下是否存在完整研究否则立即调用task-researcher补齐。其核心约定用户输入一律视为规划请求禁止直接实现项目文件——Create/Add/Implement/Build/Deploy类指令被解释为规划请求每个任务产出三个文件计划清单YYYYMMDD-task-description-plan.instructions.md→./.copilot-tracking/plans/实施细节YYYYMMDD-task-description-details.md→./.copilot-tracking/details/实施提示implement-task-description.prompt.md→./.copilot-tracking/prompts/模板占位符统一使用{{snake_case}}双花括号标记如{{task_name}}、{{date}}、{{file_path}}交付前必须确保无残留占位符行号引用管理研究→细节、细节→计划之间必须维护精确的(Lines X-Y)引用文件变更后同步更新。三个文件的模板要素为计划文件frontmatterapplyTo指向变更跟踪文件、Overview、Objectives、Research Summary、带复选框与行号引用的分阶段 Implementation Checklist、Dependencies、Success Criteria细节文件Research Reference、逐阶段的完整规格、文件操作、成功标准实施提示文件模式为mode: agent、分步执行指引、阶段/任务粒度的暂停开关${input:phaseStop}/${input:taskStop}以及收尾时的变更汇总与清理建议。4.3 planner / plan / implementation-plan三种规划视角planneragents/planner.agent.md规划模式明确不做任何代码编辑只产出计划输出 Markdown 计划文档包含 Overview、Requirements、Implementation Steps、Testing 四个部分。planagents/plan.agent.md战略规划与架构助手核心原则是Think First, Code Later。它强调先通过codebase/search/usages/problems/fetch/githubRepo等工具充分收集信息再开展需求分析、上下文构建、约束识别、策略开发与风险评估以顾问式对话引导开发者做出知情决策。implementation-planagents/implementation-plan.agent.md面向AI 到 AI的自动化执行场景要求计划确定性、零歧义、机器可解析、完全自包含所有标识符使用REQ-/TASK-/SEC-/CON-/TEST-等标准前缀。计划文件保存到/plan/目录命名约定为[purpose]-[component]-[version].mdpurpose 前缀upgrade|refactor|feature|data|infrastructure|process|architecture|design并在 frontmatter 中声明goal、version、date_created、statusCompleted/In progress/Planned/Deprecated/On Hold并渲染为徽章等字段。模板严格规定 8 个章节Requirements Constraints、Implementation Steps分阶段、任务表含 Completed/Date 列、Alternatives、Dependencies、Files、Testing、Risks Assumptions、Related Specifications。4.4 prd带验收标准与 Issue 对接的 PRD 生成器见 agents/prd.agent.md。该 Agent 扮演资深产品经理默认输出prd.md路径由用户指定或建议项目根目录并严格遵循 10 大部分的大纲产品概述、目标业务/用户/非目标、用户画像与基于角色的访问、功能需求带优先级、用户体验入口与首次使用流程、核心体验、高级特性与边界情况、UI/UX 要点、叙事、成功指标用户/业务/技术三维度、技术考量集成点、数据存储与隐私、扩展性与性能、潜在挑战、里程碑与排期、用户故事。用户故事规范尤其严格每个用户故事分配唯一需求 ID如 GH-001覆盖主路径/备选/边界情况涉及认证/安全时必须有对应故事且每个故事都必须可测试。生成 PRD 后Agent 会请求用户确认随后询问是否将用户故事创建为 GitHub Issues并返回 Issue 链接列表——与命令create-github-issues-feature-from-implementation-plan形成互补一个面向 PRD 用户故事一个面向实施计划阶段。4.5 research-technical-spike递归式技术验证见 agents/research-technical-spike.agent.md。该 Agent 专门系统化验证技术 Spike 文档其方法论有三个显著特征递归研究协议从一个主研究问题出发用#search/#fetch/#githubRepo/#extensions组合挖掘从每个结果中提取新术语/API/库并立即继续研究直到无新信息涌现且跨源交叉验证Todo 驱动的进度管理研究开始即建立粒度化 todo 列表每个研究分支一个 todo实时更新用 todo 追踪递归分支确保无遗漏持续文档化Spike 文档被当作活的研究笔记本而非最终报告每次工具使用与发现后立即更新Investigation Results / External Resources / Prototype/Testing Notes / Technical Constraints / Decision Trail等区块任何创建文件、执行命令、修改系统的操作前必须征得用户许可。其前置条件是用户必须提供 Spike 文档路径未提供则停止。同时Agent 会在研究前识别与 Spike 技术领域匹配的文档型 MCP 服务器如微软技术栈对应 Microsoft Learn MCP并给出安装建议。五、端到端流水线从 Epic 想法到可执行 Issue综合上述命令与 Agent一个完整的规划闭环可以这样串联这也正是该插件设计意图的体现Epic 层用breakdown-epic-pm产出 Epic PRDplan/{epic-name}/epic.md架构层用breakdown-epic-arch基于 Epic PRD 产出架构规范plan/{epic-name}/arch.md特性层用breakdown-feature-prd把 Epic 拆成特性级 PRDplan/{epic-name}/{feature-name}/prd.md实现层用breakdown-feature-implementation或create-implementation-plan产出分阶段实施计划plan/{epic-name}/{feature-name}/implementation-plan.md研究验证层对不确定性高的部分用create-technical-spikeresearch-technical-spike先行验证edge-ai 系的task-researcher/task-planner则提供研究 → 计划/细节/提示三件套的另一种精细化路径./.copilot-tracking/目录体系跟踪层用create-github-issues-feature-from-implementation-plan将计划阶段批量转为 GitHub Issues进入常规迭代需求变更时用update-implementation-plan演进计划。该流水线在每个环节都产出了持久化的 Markdown 工件PRD、架构图、计划、研究笔记使规划过程可追溯、可评审、可复用于后续版本——这既是该插件区别于一次性问答式 Copilot 提示词的关键也是文档即代码工作流在规划领域的体现。六、使用前提与适用边界基于仓库实际内容以下几点需要在使用前明确插件完全由 Markdown 提示词驱动无需编译但需要 GitHub Copilot含 CLI环境支持插件机制与copilot plugin install命令多个 skill 内含特定的技术栈假设TypeScript/Next.js Turborepo tRPC Stack Auth Docker PostgreSQL/Qdrant/Redis这些是 Epoch 式项目的预设团队栈不同时应让 Copilot 按自身工程约定调整输出task-planner/task-researcher依赖./.copilot-tracking/目录体系与严格的命名/模板约定落地前建议先在单个任务上试点确认研究-规划-实施链路与团队习惯兼容本插件定位是规划多数 skill 明确约定不写实现代码除非是伪代码最终实现仍由常规开发流程承接。如需深入研读各能力的具体实现建议从 插件 README 出发对照 plugin.json 的资产清单依次阅读 agents/task-planner.agent.md、agents/task-researcher.agent.md、agents/implementation-plan.agent.md、agents/prd.agent.md 以及skills/目录下各SKILL.md即可获得完整的提示词级参考资料在此基础上按团队实际裁剪即可投入使用。【免费下载链接】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），仅供参考 
长河君 · 2026/9/10 16:24:59 · 阅读 1.2k GitHub Copilot 项目规划流水线：awesome-copilot 的 project-planning 插件实战指南
GitHub Copilot 项目规划流水线awesome-copilot 的 project-planning 插件实战指南【免费下载链接】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本文基于 awesome-copilot 仓库中的 project-planning 插件系统讲解如何利用该插件在 GitHub Copilot 中构建「Epic 拆解 → 需求文档 → 架构设计 → 实施计划 → GitHub Issues → 技术验证」的完整项目规划闭环。读完本文你将掌握 8 个斜杠命令与 7 个规划类 Agent 的定位与用法理解底层agent.md与 skill 的协作机制并能在团队中直接落地一套可复制的规划工作流。一、插件定位把规划变成 Copilot 的专项能力软件团队在启动一个功能或重构任务时往往卡在想法到可执行计划的鸿沟上Epic 没人拆、PRD 写不完整、实施计划停留在口头、技术风险无人验证。awesome-copilot 社区仓库中的project-planning插件plugins/project-planning/README.md正是为此设计——它为 GitHub Copilot 注入了一套面向软件项目规划、特性拆解、Epic 管理、实施计划与任务组织的工具集和智能体。从插件的清单文件 plugin.json 可以看到该插件的声明信息如下字段值名称project-planning版本1.0.0作者Awesome Copilot Community许可证MIT关键词planning、project-management、epic、feature、implementation、task、architecture、technical-spike插件在extensions.com.github.awesome-copilot命名空间下挂载了两类资产7 个 Agent./agents/*.md与8 个 Skill./skills/*/二者分别对应角色化智能体与斜杠命令提示词两种使用形态共同构成完整的规划能力矩阵。二、安装一条命令接入该插件通过 Copilot CLI 安装命令来自 插件 READMEcopilot plugin install project-planningawesome-copilot安装完成后Copilot 会话中即可使用project-planning:前缀的斜杠命令并可在 Agent 选择器中调用本插件的规划类 Agent。仓库根目录的mcp.json、package.json等文件表明该仓库本身是可复现的 Node.js 工程但插件使用不需要任何额外编译——它完全由 Markdown 提示词驱动。三、斜杠命令Slash Commands8 个命令覆盖全生命周期插件提供了 8 个斜杠命令对应 8 个 skill 提示词。下表汇总了各命令的职责随后逐一展开命令职责/project-planning:breakdown-epic-pm基于一个 Epic 想法产出 Epic 级 PRD/project-planning:breakdown-epic-arch基于 Epic PRD产出高层技术架构规范/project-planning:breakdown-feature-prd基于 Epic为单个特性产出详细 PRD/project-planning:breakdown-feature-implementation基于功能 PRD产出详细实施计划遵循 Epoch monorepo 结构/project-planning:create-implementation-plan为新增特性/重构/升级/设计/架构/基础设施创建实施计划文件/project-planning:update-implementation-plan用新需求更新既有实施计划文件/project-planning:create-github-issues-feature-from-implementation-plan按实施计划的阶段用feature_request.yml或chore_request.yml模板创建 GitHub Issues/project-planning:create-technical-spike创建有时限的技术 Spike 文档用于在实现前研究并解决关键决策3.1 breakdown-epic-pm把想法固化为 Epic PRD命令 prompt 见 skills/breakdown-epic-pm/SKILL.md。该 skill 让 Copilot 扮演大型 SaaS 平台的资深产品经理将用户的高层想法翻译为 Epic 级 PRD并明确该 PRD 将作为生成技术架构规范的输入。信息不足时要求先提问澄清。产出一份完整的 Epic PRD保存到/docs/ways-of-work/plan/{epic-name}/epic.md包含 8 个部分Epic 名称、目标问题/方案/影响、用户画像、高层用户旅程、业务需求功能 非功能、成功指标KPI、范围外事项防 Scope 蔓延、业务价值评估。3.2 breakdown-epic-arch从 PRD 推导高层架构命令 prompt 见 skills/breakdown-epic-arch/SKILL.md。该 skill 让 Copilot 以资深软件架构师身份基于 Epic PRD 输出高层技术架构规范产物保存为/docs/ways-of-work/plan/{epic-name}/arch.md。其约束上下文明确了一个典型的技术栈假设领域驱动架构Domain-driven、自托管与 SaaS 双模式部署、全服务 Docker 容器化、TypeScript/Next.js App Router、Turborepo monorepo、tRPC 类型安全 API、Stack Auth 认证——使用前需确认与团队实际栈是否一致。架构规范要求产出 6 部分内容Epic 架构总览技术方案摘要系统架构图用 Mermaid 图呈现五层结构——用户层浏览器/移动端/管理界面、应用层负载均衡、应用实例、Stack Auth、服务层tRPC API、后台服务、n8n 工作流、数据层PostgreSQL、Qdrant 向量库、Redis 缓存、外部 API、基础设施层Docker 容器化与部署要求用子图分层、统一配色、标注数据流含同步请求与异步处理两类路径高层特性与技术使能项要构建的特性清单以及支撑特性所需的新服务/库/基础设施技术栈关键技术、框架与库技术价值High/Medium/Low 评估并附理由T-Shirt 尺寸估算S/M/L/XL 级别的规模预判。同时约定除非技术情境需要伪代码否则不输出实际代码。3.3 breakdown-feature-prd为单个特性撰写详细 PRD命令 prompt 见 skills/breakdown-feature-prd/SKILL.md。该 skill 承接 Epic将 Epic 中的某个高层特性/使能项细化为特性级 PRD作为工程团队的唯一事实来源并作为后续技术规格生成的输入。产物保存为/docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md包含特性名称、父级 Epic链接回 Epic PRD 与架构文档、目标、用户画像、用户故事统一采用 As apersona, I want toactionso that I canbenefit 格式并覆盖主路径与边界情况、需求功能 非功能、验收标准采用清单或 Given/When/Then 格式以便验证、范围外事项。3.4 breakdown-feature-implementation产出落地级实施计划命令 prompt 见 skills/breakdown-feature-implementation/SKILL.md。该 skill 让 Copilot 以行业资深工程师身份基于功能 PRD 输出可直接执行的技术实施计划保存为/docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md。其文件系统约定遵循Epoch monorepo 结构apps/ [app-name]/ services/ [service-name]/ packages/ [package-name]/实施计划要求覆盖以下技术决策面目标与需求特性目标3-5 句与详细需求清单系统架构Mermaid 五层架构图前端层/API 层/业务逻辑层/数据层/基础设施层标注请求-响应、数据转换与事件流技术栈选型理由、集成边界与通信协议、Docker 部署策略、水平/垂直扩展方案数据库 Schema 设计Mermaid ER 图含字段定义类型与约束、索引策略、外键关系、数据库迁移策略API 设计端点完整规格、带 TypeScript 类型的请求/响应格式、基于 Stack Auth 的认证授权、错误处理与状态码、限流与缓存策略前端架构基于shadcn/ui的组件层级文档含布局结构示例、Mermaid 状态流图、Zustand/React Query 状态管理模式、TypeScript 接口安全与性能认证/授权要求、数据校验与净化、性能优化策略、缓存机制。3.5 create / update-implementation-plan实施计划的创建与演进这两个命令对应的 skillskills/create-implementation-plan/、skills/update-implementation-plan/负责创建新的实施计划文件与用新增/变更需求更新既有计划覆盖范围包括新特性、既有代码重构、依赖升级、设计、架构或基础设施。update命令解决了规划文档的保鲜问题——需求变更时无需推倒重来而是增量演进。3.6 create-github-issues-feature-from-implementation-plan计划到 Issue 的自动化该命令将实施计划中的**阶段Phase**批量转换为 GitHub Issues并支持feature_request.yml与chore_request.yml两类模板从而让计划 → 跟踪两个环节无缝衔接。这解释了为什么实施计划要按原子阶段组织——阶段即 Issue 的粒度来源详见下文 3.8 与第五节的完整流水线。3.7 create-technical-spike用 Spike 消解技术不确定性该命令用于创建有时间盒time-boxed的技术 Spike 文档专门针对实现前的关键开发决策做研究验证。与之配套的 Agent 是research-technical-spike见 agents/research-technical-spike.agent.md二者形成创建文档 → 系统化验证的闭环属于插件中验证优先路线的核心资产。3.8 斜杠命令背后的目录约定从 plugin.json 可以看出8 个命令与 8 个 skill 一一对应命令底层 skill 目录breakdown-epic-pmskills/breakdown-epic-pm/breakdown-epic-archskills/breakdown-epic-arch/breakdown-feature-prdskills/breakdown-feature-prd/breakdown-feature-implementationskills/breakdown-feature-implementation/create-implementation-planskills/create-implementation-plan/update-implementation-planskills/update-implementation-plan/create-github-issues-feature-from-implementation-planskills/create-github-issues-feature-from-implementation-plan/create-technical-spikeskills/create-technical-spike/每个 skill 目录均为单SKILL.md文件采用 frontmatternamedescription声明元数据正文即提示词主体——这正是斜杠命令 可复用提示词的仓库级实现形态。四、Agent 角色体系7 个规划智能体除命令外插件还提供 7 个 Agent。其中task-planner与task-researcher由microsoft/edge-ai贡献planner、plan、prd、implementation-plan、research-technical-spike为社区贡献。下表为概览Agent定位task-researcher任务研究专家负责全面项目分析edge-ai 出品task-planner任务规划者产出可执行的实施计划edge-ai 出品planner为新特性或重构生成实施计划plan战略规划与架构助手强调实现前的深入思考prd生成结构化、可行动的 PRD可选创建 GitHub Issuesimplementation-plan面向 AI 执行优化的实施计划生成research-technical-spike系统性研究并验证技术 Spike 文档4.1 task-researcher只研究、不写代码的专项角色完整指令见 agents/task-researcher.agent.md。该 Agent 是纯研究角色唯一职责是在./.copilot-tracking/research/下创建/更新研究文档禁止改动任何源码与配置。其核心约束包括只记录经实际工具使用验证的发现绝不基于假设输出必须跨多个权威来源交叉验证发现新方案后立即删除过时信息杜绝重复内容研究过程提供多个备选方案并引导用户收敛到唯一推荐方案。研究文件遵循命名规范YYYYMMDD-task-description-research.md专题研究为YYYYMMDD-topic-specific-research.md并使用固定的研究模板包含Research Executed文件分析/代码搜索/外部研究/项目约定→ Key Discoveries项目结构/实现模式/完整示例/API 与 Schema/配置示例/技术要求→ Recommended Approach → Implementation Guidance等区块。4.2 task-planner基于已验证研究的三件套规划器完整指令见 agents/task-planner.agent.md。该 Agent 的硬性前置条件是任何规划活动前必须先验证./.copilot-tracking/research/下是否存在完整研究否则立即调用task-researcher补齐。其核心约定用户输入一律视为规划请求禁止直接实现项目文件——Create/Add/Implement/Build/Deploy类指令被解释为规划请求每个任务产出三个文件计划清单YYYYMMDD-task-description-plan.instructions.md→./.copilot-tracking/plans/实施细节YYYYMMDD-task-description-details.md→./.copilot-tracking/details/实施提示implement-task-description.prompt.md→./.copilot-tracking/prompts/模板占位符统一使用{{snake_case}}双花括号标记如{{task_name}}、{{date}}、{{file_path}}交付前必须确保无残留占位符行号引用管理研究→细节、细节→计划之间必须维护精确的(Lines X-Y)引用文件变更后同步更新。三个文件的模板要素为计划文件frontmatterapplyTo指向变更跟踪文件、Overview、Objectives、Research Summary、带复选框与行号引用的分阶段 Implementation Checklist、Dependencies、Success Criteria细节文件Research Reference、逐阶段的完整规格、文件操作、成功标准实施提示文件模式为mode: agent、分步执行指引、阶段/任务粒度的暂停开关${input:phaseStop}/${input:taskStop}以及收尾时的变更汇总与清理建议。4.3 planner / plan / implementation-plan三种规划视角planneragents/planner.agent.md规划模式明确不做任何代码编辑只产出计划输出 Markdown 计划文档包含 Overview、Requirements、Implementation Steps、Testing 四个部分。planagents/plan.agent.md战略规划与架构助手核心原则是Think First, Code Later。它强调先通过codebase/search/usages/problems/fetch/githubRepo等工具充分收集信息再开展需求分析、上下文构建、约束识别、策略开发与风险评估以顾问式对话引导开发者做出知情决策。implementation-planagents/implementation-plan.agent.md面向AI 到 AI的自动化执行场景要求计划确定性、零歧义、机器可解析、完全自包含所有标识符使用REQ-/TASK-/SEC-/CON-/TEST-等标准前缀。计划文件保存到/plan/目录命名约定为[purpose]-[component]-[version].mdpurpose 前缀upgrade|refactor|feature|data|infrastructure|process|architecture|design并在 frontmatter 中声明goal、version、date_created、statusCompleted/In progress/Planned/Deprecated/On Hold并渲染为徽章等字段。模板严格规定 8 个章节Requirements Constraints、Implementation Steps分阶段、任务表含 Completed/Date 列、Alternatives、Dependencies、Files、Testing、Risks Assumptions、Related Specifications。4.4 prd带验收标准与 Issue 对接的 PRD 生成器见 agents/prd.agent.md。该 Agent 扮演资深产品经理默认输出prd.md路径由用户指定或建议项目根目录并严格遵循 10 大部分的大纲产品概述、目标业务/用户/非目标、用户画像与基于角色的访问、功能需求带优先级、用户体验入口与首次使用流程、核心体验、高级特性与边界情况、UI/UX 要点、叙事、成功指标用户/业务/技术三维度、技术考量集成点、数据存储与隐私、扩展性与性能、潜在挑战、里程碑与排期、用户故事。用户故事规范尤其严格每个用户故事分配唯一需求 ID如 GH-001覆盖主路径/备选/边界情况涉及认证/安全时必须有对应故事且每个故事都必须可测试。生成 PRD 后Agent 会请求用户确认随后询问是否将用户故事创建为 GitHub Issues并返回 Issue 链接列表——与命令create-github-issues-feature-from-implementation-plan形成互补一个面向 PRD 用户故事一个面向实施计划阶段。4.5 research-technical-spike递归式技术验证见 agents/research-technical-spike.agent.md。该 Agent 专门系统化验证技术 Spike 文档其方法论有三个显著特征递归研究协议从一个主研究问题出发用#search/#fetch/#githubRepo/#extensions组合挖掘从每个结果中提取新术语/API/库并立即继续研究直到无新信息涌现且跨源交叉验证Todo 驱动的进度管理研究开始即建立粒度化 todo 列表每个研究分支一个 todo实时更新用 todo 追踪递归分支确保无遗漏持续文档化Spike 文档被当作活的研究笔记本而非最终报告每次工具使用与发现后立即更新Investigation Results / External Resources / Prototype/Testing Notes / Technical Constraints / Decision Trail等区块任何创建文件、执行命令、修改系统的操作前必须征得用户许可。其前置条件是用户必须提供 Spike 文档路径未提供则停止。同时Agent 会在研究前识别与 Spike 技术领域匹配的文档型 MCP 服务器如微软技术栈对应 Microsoft Learn MCP并给出安装建议。五、端到端流水线从 Epic 想法到可执行 Issue综合上述命令与 Agent一个完整的规划闭环可以这样串联这也正是该插件设计意图的体现Epic 层用breakdown-epic-pm产出 Epic PRDplan/{epic-name}/epic.md架构层用breakdown-epic-arch基于 Epic PRD 产出架构规范plan/{epic-name}/arch.md特性层用breakdown-feature-prd把 Epic 拆成特性级 PRDplan/{epic-name}/{feature-name}/prd.md实现层用breakdown-feature-implementation或create-implementation-plan产出分阶段实施计划plan/{epic-name}/{feature-name}/implementation-plan.md研究验证层对不确定性高的部分用create-technical-spikeresearch-technical-spike先行验证edge-ai 系的task-researcher/task-planner则提供研究 → 计划/细节/提示三件套的另一种精细化路径./.copilot-tracking/目录体系跟踪层用create-github-issues-feature-from-implementation-plan将计划阶段批量转为 GitHub Issues进入常规迭代需求变更时用update-implementation-plan演进计划。该流水线在每个环节都产出了持久化的 Markdown 工件PRD、架构图、计划、研究笔记使规划过程可追溯、可评审、可复用于后续版本——这既是该插件区别于一次性问答式 Copilot 提示词的关键也是文档即代码工作流在规划领域的体现。六、使用前提与适用边界基于仓库实际内容以下几点需要在使用前明确插件完全由 Markdown 提示词驱动无需编译但需要 GitHub Copilot含 CLI环境支持插件机制与copilot plugin install命令多个 skill 内含特定的技术栈假设TypeScript/Next.js Turborepo tRPC Stack Auth Docker PostgreSQL/Qdrant/Redis这些是 Epoch 式项目的预设团队栈不同时应让 Copilot 按自身工程约定调整输出task-planner/task-researcher依赖./.copilot-tracking/目录体系与严格的命名/模板约定落地前建议先在单个任务上试点确认研究-规划-实施链路与团队习惯兼容本插件定位是规划多数 skill 明确约定不写实现代码除非是伪代码最终实现仍由常规开发流程承接。如需深入研读各能力的具体实现建议从 插件 README 出发对照 plugin.json 的资产清单依次阅读 agents/task-planner.agent.md、agents/task-researcher.agent.md、agents/implementation-plan.agent.md、agents/prd.agent.md 以及skills/目录下各SKILL.md即可获得完整的提示词级参考资料在此基础上按团队实际裁剪即可投入使用。【免费下载链接】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），仅供参考