claude-skills 实施计划生成工作流从 Overview Document 到可并行执行的开发蓝图【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读本文深入剖析 claude-skills 项目规划阶段的核心命令create-implementation-plan它以planning:epic-plan产出的 Overview Document 为唯一输入经过上下文校验、代码库调研、Jira 工单精化最终生成一份发布到 Confluence 的实施计划并把所有 Jira 工单改写成「自包含」self-contained的可执行规格。读完本文你将掌握这套命令的完整阶段流程、强制检查点机制、工单拆分与故事点估算规则、基于依赖的拓扑排序与并行执行波次设计以及它与execute-ticket之间的衔接方式。一、流程定位实施计划在开发生命周期中的位置在 claude-skills 的docs/workflow工作流体系里实施计划生成处于Planning规划阶段的第二环是连接「规划」与「执行」的枢纽。整条标准实现流程如下见 WORKFLOW_COMMANDS.md 的 Document Flow Summaryplanning:epic-plan → planning:impl-plan → [execution:execute-ticket execution:complete-ticket] × N → retrospectives:complete-epic对应到本文档legacy 版 .claude/old-commands/legacy/create-implementation-plan.md中的 Workflow Chain 概念/create-epic-plan epic-key → 创建 Overview Document上游 /create-implementation-plan overview-doc-url → 创建 Implementation Plan本文档YOU ARE HERE /execute-ticket ticket-key → 逐个执行工单下游命令的输入输出在 impl-plan.yaml 中被正式定义项目定义命令名planning:impl-plan阶段planning输入overview-doc-url必填Confluence URL即planning:epic-plan的产出输出implementation-plan已发布的 Confluence 实施计划含执行顺序、并行波次、Agent 建议与updated-tickets被回写自包含实现细节的 Jira 工单前置依赖ticketingJira、documentationConfluence这份工作流产出两种核心产物实施计划文档Confluence 协调看板与更新后的 Jira 工单自包含完整实现细节。前者用于整体追踪后者让每个工单无需再回头翻阅外部文档即可独立执行。二、Phase 0上下文检索与信息强制校验2.1 提取关键信息命令的第一步是从传入的{Overview_Document}中提取三类信息{Epic_Key}—— Epic 工单键如MA-123/CC-123{Jira_Project}—— Jira 项目/看板的链接相关的工单链接列表。2.2 失败条件信息缺失时必须停止如果无法从文档中确定 Epic Key 或项目信息必须立即停止并提示用户示例提示如下I was unable to extract required information from the overview document. Found: [list what was found] Please provide: 1. Epic Key: [e.g., MA-123] 2. Jira Project URL: [paste link]在用户确认补齐信息之前不得继续推进DO NOT PROCEED。2.3 强制检查点文档确认即便信息提取成功也必须经过一次显式的用户确认示例输出如下Please confirm the following before I proceed: Overview Document: {Overview_Document} Epic Key: {Epic_Key} Jira Project: {Jira_Project} Is this correct? (Yes / No / Correct)只有在用户明确确认后才能进入下一阶段。这一设计体现了本工作流的核心原则在修改 Jira 或 Confluence 之前必须获得用户的显式授权。在 create-implementation-plan.md 的 Checkpoints Summary 中该检查点被正式记为 Phase 0 的 Document confirmation。三、Phase 1Discovery 调研在正式生成计划前Agent 需要完成三个维度的信息收集阅读 Overview Document获取 Epic 的上下文、范围和风险评估结论阅读该 Epic 关联的全部 Jira 工单获取详细需求探索代码库重点理解文件结构与命名约定可参考的相似已有实现可用的测试模式与 fixturesAPI 模式与数据模型。当前版本命令commands/project/planning/create-implementation-plan.md进一步细化了代码库探索的聚焦点每个工单受影响的文件/模块、API 模式路由、中间件、响应格式、组件模式命名、状态管理、测试模式位置、fixtures、mocks以及参考实现。与上游create-epic-plan见 create-epic-plan.md不同epic-plan 阶段的代码库探索是为了产出「给人看的决策文档」而 impl-plan 阶段的探索是为了让工单达到「可直接交给 AI Agent 执行」的粒度。四、Phase 2Ticket 精化与强制批准检查点在创建实施计划之前需要先分析既有工单并做出必要调整。任何改动都必须先在检查点展示给用户并获得批准。4.1 强制检查点工单变更提案向用户展示完整的提案表格式如下## Proposed Ticket Changes for {Epic_Key} ### New Tickets to Create | Title | Description | Points | Justification | |-------|-------------|--------|---------------| | [title] | [brief desc] | [pts] | [why needed] | ### Tickets to Split | Original | New Tickets | Reason | |----------|-------------|--------| | [KEY] | [list new] | [why split] | ### Story Point Updates | Ticket | Current | Proposed | Reason | |--------|---------|----------|--------| | [KEY] | [old] | [new] | [justification] | ### Dependencies to Add | Ticket | Blocked By | Reason | |--------|------------|--------| | [KEY] | [blocker] | [why] | Proceed with these changes? (Yes / No / Modify)Yes→ 执行变更并继续No→ 跳过工单变更直接进入 Phase 3Modify→ 用户提供调整意见后重新确认。未经明确批准不得修改任何 Jira 工单。4.2 工单描述格式强制所有工单新建与既有的描述顶部必须包含以下链接头Overview Document: {Overview_Document} Implementation Plan: {Implementation_Plan} --- [Rest of ticket description]新工单创建时即添加该头既有工单若缺少则更新描述补齐{Implementation_Plan}是 Phase 4 创建的 Confluence 子页面 URL。由于 Phase 2 时实施计划尚不存在需先用占位符待 Phase 4 发布后再回填真实 URLImplementation Plan: [To be added after plan is published]这一设计保证了/execute-ticket能从任意一张工单中同时提取两个链接实现执行阶段无需跳转文档即可自取上下文。4.3 工单精化规则创建新工单Create New Tickets识别覆盖面缺口缺失功能、边界情况、搭建任务为发现的技术依赖创建工单为阻塞实现的必要重构或技术债添加工单。拆分大工单Split Large Tickets任何估算超过8 个故事点的工单必须拆分每张工单应代表一个单一、可交付的工作单元。添加故事点Add Story Points为所有工单新、旧估算并添加故事点参考分级PointsComplexityExample1-2简单、隔离的变更修 typo、更新配置、添加简单校验3-5中等、涉及少数文件新 API endpoint、带测试的组件8复杂、涉及多组件横跨前端 后端的特性13过大必须拆分Epic 级工作量链接依赖Link Dependencies在 Jira 中为所有依赖设置 blocked by 关系并确保不存在循环依赖。关于依赖链接的具体调用参考 jira-queries.md 中的 Issue Linking 一节jira_create_issue_link使用inward_issue_key阻塞方与outward_issue_key被阻塞方表达 Blocks 关系参数语义与直觉相反调用前务必核对该文档同时给出了参数写反的 Anti-Pattern 示例。五、Phase 3生成实施计划Phase 3 生成一份详细、可被 Agent 直接执行的实施计划并在发布前经过强制预览检查点。5.1 强制检查点计划预览## Implementation Plan Preview for {Epic_Key} [Full implementation plan content] --- Review the plan above. Proceed to publish? (Yes / No / Modify)Yes→ 进入 Phase 4No→ 放弃并询问需要哪些修改Modify→ 用户反馈后重新生成并再次确认。未经明确批准不得进入发布环节。5.2 Summary 摘要段计划开头应包含任务总数含新建工单总体复杂度评估Low/Medium/High基于风险分数故事点总和关键依赖概览建议执行顺序。5.3 Task Breakdown 任务分解每张 Jira 工单对应一个任务条目包含任务头Task Header工单键与标题如 MA-124 - Add user authentication、Jira 链接、故事点、规划文档中的风险等级Low/Medium/High、依赖清单必须先完成的工单。实现步骤Implementation Steps提供足够详细、Agent 可直接执行的步骤包括待创建/修改的具体文件路径应遵循的代码模式参考既有代码库模式待实现的 API endpoint数据库变更如有需要的配置更新遵循现有的命名、文件结构、架构约定。每个步骤必须具体到一个 AI 编码 Agent 无需额外上下文即可直接执行。待修改文件Files to Modify列出所有将涉及的文件如path/to/file.ts - Brief description of changes待编写测试Tests to Write精确说明需要哪些测试单元测试列出具体要测的函数/组件集成测试列出要测的 API endpoint 或服务交互E2E 测试列出要测的用户流程如适用。验收标准Acceptance Criteria每项任务完成的标准所有实现步骤完成Pre-commit hooks 通过lint、格式化、类型检查Pre-push hooks 通过测试、构建单元测试已编写并通过集成测试已编写并通过如适用E2E 测试已编写并通过如适用保持 90% 分支覆盖率所有既有测试继续通过代码已评审并获得批准满足 Jira 工单验收标准六、执行顺序与并行执行策略6.1 执行顺序拓扑排序基于依赖关系提供拓扑排序的任务清单1. Task A (no dependencies) - X points 2. Task B (depends on A) - X points 3. Task C (depends on A) - X points 4. Task D (depends on B, C) - X points无依赖的任务排在最前依赖链越深的越靠后。6.2 并行执行波次Parallel Execution Waves识别可以由独立 Agent 同时执行的工单按波次分组同一波次内所有工单可并发Wave 1 (no dependencies - execute in parallel): - TICKET-101: [title] (3 pts) → frontend-developer - TICKET-102: [title] (5 pts) → backend-developer - TICKET-103: [title] (2 pts) → test-automator Wave 2 (depends on Wave 1 - execute in parallel after Wave 1): - TICKET-104: [title] (5 pts) → fullstack-developer - TICKET-105: [title] (3 pts) → frontend-developer Wave 3 (depends on Wave 2): - TICKET-106: [title] (8 pts) → fullstack-developer6.3 Agent 专业化建议根据工作类型为每个工单推荐最优 Agent 类型Work TypeRecommended AgentFrontend UI/componentsfrontend-developerAPI/backend servicesbackend-developerDatabase changesdatabase-optimizerFull-stack featuresfullstack-developerTest coveragetest-automatorSecurity-sensitivesecurity-auditorPerformance-criticalperformance-engineer6.4 协调说明Coordination Notes同一波次的工单彼此无依赖Wave N1 的工单依赖一个或多个 Wave N 工单波次内的独立 Agent 可同时工作进入下一波次前须同步并验证完成情况。七、Phase 4发布与文档回写7.1 强制检查点父文档更新在更新父规划文档之前先展示拟添加的内容## Proposed Updates to Overview Document I will add the following Adjustments Section to {Overview_Document}: [Show exact content to be added] Proceed with update? (Yes / No / Modify)未经明确批准不得更新父文档。7.2 发布与链接回填将实施计划发布为 Confluence 子页面{Implementation_Plan}回填所有工单的实施计划链接发布后 URL 已知将全部 Epic 工单中的占位符替换为真实 URLOverview Document: {Overview_Document} Implementation Plan: {Implementation_Plan}这确保了/execute-ticket能从任何工单中提取出两个链接用已批准的调整内容更新父规划文档。7.3 父文档调整段Adjustments Section更新原 Confluence 规划文档追加以下内容Tickets Added新建的工单及其理由Tickets Split被拆分的工单及原因Scope Changes规划过程中发现的任何范围调整New Risks实施规划过程中发现的新风险Revised Dependencies变更后的依赖图如有Updated Estimates基于故事点的修订总工作量。7.4 输出位置父页面{Overview_Document}子页面标题{Epic_Key} Implementation Plan若子页面已存在则更新若无法创建子页面向用户询问替代位置。7.5 完成输出命令完成时向用户提供实施计划 URL新子页面执行阶段需要更新后的 Overview Document URL父页面变更摘要创建/拆分/更新的工单。八、与当前仓库实现的对应关系8.1 从 legacy 到正式命令的演化本文所讲解的 legacy 版命令位于 .claude/old-commands/legacy/create-implementation-plan.md。在仓库当前版本中该命令已正式落地为planning:impl-plan主流程文件commands/project/planning/create-implementation-plan.md命令定义impl-plan.yaml用户文档docs/workflow/planning-impl-plan.md。新版在保留全部五个阶段骨架Context Retrieval → Discovery → Ticket Refinement → Generate Plan → Update Tickets → Update Overview的基础上做了几处关键增强工单自包含度提升Ticket Description Template 中加入了完整的文件修改表格File | Action | Description和「完整、可直接复制的测试代码」明确强调「/execute-ticket仅凭工单即可运行无需外部文档抓取降低执行期 token 消耗支持并行 Agent 执行」实施计划结构标准化提供了可直接套用的 Markdown 模板含 Summary 指标表、Completion Status 追踪表、拓扑排序执行顺序表、按波次的并行执行策略表、Agent 推荐表与文档链接检查点清单显式化末尾的 Checkpoints Summary 表格四个阶段Phase 0 文档确认、Phase 2 工单变更、Phase 3 计划预览、Phase 5 Overview 更新一目了然。8.2 与下游执行命令的衔接实施计划的最终消费方是 commands/project/execution/execute-ticket.mdexecution:execute-ticket。其 Phase 1 Preparation 明确要求强制阅读工单的自包含实现步骤视为首要事实来源、强制阅读实施计划获取波次/依赖上下文并检查并行执行机会——即当前波次首个存在未完成工单的波次内所有工单可同时执行可考虑按工作类型委派给frontend-developer、backend-developer、database-optimizer、test-automator等专职 Agent并将并行机会展示给用户批准。这正是实施计划中「Parallel Execution Waves」与「Agent Specialization Recommendations」两个章节被消费的具体场景。上游衔接方面Overview Document 由planning:epic-plandocs/workflow/planning-epic-plan.md产出其输出会明确给出下一步命令提示/create-implementation-plan {Overview_Document}8.3 仓库中的配套佐证全局命令参考docs/WORKFLOW_COMMANDS.md 的 Planning Phase 章节给出了planning:impl-plan的命令签名/project:planning:create-implementation-plan overview-doc-url、完整处理步骤与「工单自包含」最佳实践说明Jira 集成细节skills/atlassian-mcp/references/jira-queries.md 提供了jira_search、jira_update_issue、jira_transition_issue、jira_create_issue_link等 MCP 工具调用示例以及 JQLEpic Link {Epic_Key}这类本工作流实际使用的查询模式生命周期图docs/WORKFLOW_COMMANDS.md 中的 Mermaid 图完整描绘了planning:epic-plan→planning:impl-plan→execution:execute-ticket→execution:complete-ticket的流转链路。九、检查点系统与使用要点9.1 检查点总览本命令共有四个强制检查点commands/project/planning/create-implementation-plan.md 中 Checkpoints SummaryPhaseCheckpointAction0Document confirmation确认 Epic Key 与项目2Ticket changes批准新建/拆分/更新的工单3Plan preview发布前批准计划5Overview updates批准调整段内容核心红线未经用户明确批准绝不修改 Jira 或 Confluence。9.2 使用要点总结输入必须来自 epic-planoverview-doc-url是planning:epic-plan的 Confluence 产出其中已含风险评分、代码库分析等上下文见 docs/workflow/planning-epic-plan.md工单是执行单元计划是协调层所有实现细节下沉到工单描述实施计划只承担摘要指标、完成状态、执行顺序、并行波次与 Agent 推荐等协调职责并行能力前置设计波次划分与 Agent 类型建议在规划期确定执行期由execute-ticket直接消费实现「规划即调度」链接是粘合剂Overview Document 与 Implementation Plan 两个 URL 必须出现在每张工单顶部保证从任何入口都能回溯上下文90% 分支覆盖率是本工作流反复出现的质量门槛从 epic-plan 的测试策略到 impl-plan 的验收标准一脉相承。这套流程的最终效果是规划阶段产出「人可读的决策文档 Agent 可执行的工单」执行阶段以并行波次驱动多个专职 Agent 协同交付同时通过强制检查点保证每一步都有人的监督与授权。【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考