尧图网站建设 
claude-skills 回顾阶段实战指南Epic 收尾、12 节完成报告与系统描述闭环更新【免费下载链接】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 仓库的 docs/workflow/retrospective-phase.md 展开。回顾阶段Retrospective Phase是整个工作流生命周期的收尾环节当 Epic 内所有工单执行完毕后由 Agent 一次性完成完成度校验、生成综合完成报告、归档文档、在 Jira 中关闭 Epic并对docs/system-description.md做一次整体性复核更新。读完本文你将掌握retrospectives:complete-epic命令的完整执行链从上下文检索到知识转移、12 节完成报告的具体内容与填写要点、强制检查点与失败条件的处理方式以及回顾产出如何回馈到下一轮feature-forge迭代。为什么需要回顾阶段把 Epic 的闭环真正关上在 claude-skills 的工作流中一个 Epic 会依次经过 intake代码库建档、discovery探索、planning规划、execution执行四个阶段而回顾阶段是最后的收尾动作。根据 docs/workflow/retrospective-phase.md 的定义它的职责包含五件事验证所有工作已完成——逐一核对 Epic 下每个工单的状态生成综合完成报告——沉淀交付物、质量指标、经验教训、风险复盘与改进建议将文档移动到最终位置——从 In Progress 归档到 Complete 目录在工单系统中关闭 Epic——状态置为 Done执行系统描述的整体性复核——捕获逐工单增量更新过程中可能遗漏的架构变更。最后一点尤其关键回顾不是简单地把状态翻成 Done而是对docs/system-description.md做一次全局审视确保架构图、API 面与依赖映射能真实反映 Epic 完成后的系统状态。这正是回顾阶段区别于普通收尾脚本的核心价值。从工作流编排上看回顾阶段并非孤立存在。仓库根目录的 commands/workflow-manifest.yaml 定义了完整的阶段依赖链阶段依赖命令intake无intake:document-codebase、intake:capture-behavior、intake:create-system-descriptiondiscoveryintake建议discovery:create、discovery:synthesize、discovery:approveplanningdiscovery必需planning:epic-plan、planning:impl-planexecutionplanning必需execution:execute-ticket、execution:complete-ticketretrospectivesexecution必需retrospectives:complete-epic也就是说回顾阶段强依赖执行阶段的完成depends_on: execution, strength: required这保证了所有工单执行完毕是进入回顾的前提条件。核心命令retrospectives:complete-epic的输入与输出回顾阶段目前只有一条命令retrospectives:complete-epic。它的接口定义在 commands/project/retrospectives/complete-epic.yaml同时对应的完整操作手册是 docs/workflow/retrospective-complete-epic.md。输入参数参数类型是否必填说明epic-keystring是要关闭的 Jira Epic 键例如CC-62三个产出物产出类型说明completion-reportreport12 节完成报告摘要、目标、工单、交付物、架构、质量、债务、测试、文档、经验、风险、建议closed-epictickets在 Jira 中关闭的 Epic状态 Done、解决方式 Completedupdated-system-descriptionfile经整体性复核后更新的docs/system-description.md前置条件Epic 下所有工单已完成或经用户明确授权后移入 backlogOverview Document概览文档与 Implementation Plan实施计划可在 Confluence 中访问Jira 与 Confluence 访问权限已配置配置方法见 docs/ATLASSIAN_MCP_SETUP.md。调用形态为/project:retrospectives:complete-epic epic-key简写retrospectives:complete-epic每次仅针对一个 Epic命令不可重复执行repeat: false。命令在整条工作流链中的位置commands/project/retrospectives/complete-epic.md 开篇给出了清晰的 Workflow Chaincomplete-epic是执行链的倒数第二步紧随其后是可选的 sprint 级回顾/create-epic-plan epic-key → 创建 Overview Document ↓ /create-implementation-plan overview-doc-url → 创建 Implementation Plan ↓ /execute-ticket ticket-key → 逐个执行工单 ↓ /complete-epic epic-key → 完成 Epic本命令所在位置 ↓ /complete-sprint sprint-folder → Sprint 回顾从 docs/workflow/execution-phase.md 可以印证执行阶段是每工单一循环execute-ticket实现 complete-ticket收尾循环结束的标志是所有工单状态就绪随后进入回顾阶段。分阶段执行流程详解complete-epic的操作手册将整个过程划分为 5 个阶段Phase 0 Phase 5其中每个关键决策点都设置了强制检查点MANDATORY CHECKPOINT要求用户显式确认后才能继续。Phase 0上下文检索Context Retrieval从 Jira 拉取 Epic提取{Epic_Title}、{Jira_Project}、所有关联工单及 Epic 状态在 Confluence 中定位文档Overview Document 位于/Epics/In Progress/{Epic_Key}/Implementation Plan 是其子页面失败条件若文档找不到Agent 必须停下并向用户索要两个 URLOverview Document URL 与 Implementation Plan URL未确认前不得继续强制检查点Epic Completion ReadinessAgent 汇报 Epic 键、标题、总工单数、已完成数、进行中数、阻塞数以及两份文档的位置用户以Yes继续/No列出未完成工单并退出/Review查看详细工单状态作答。存在未完成工单且无用户显式覆盖时禁止继续。Phase 1完成度验证Verification逐一核对 Epic 下每个工单在 Jira 中的状态找出非 Done 的工单、阻塞问题与未解决的依赖失败条件存在未完成工单时Agent 停止并向用户呈现分类清单In Progress / Blocked / To Do给出三个选项A) 先完成剩余工单B) 将未完成工单移入 backlog 后关闭 EpicC) 延长 Epic 截止日期保持打开。等待用户决策后才继续复核实现质量确认与 Epic 工单相关的 PR 均已合并、测试覆盖率是否达到 90% 目标、记录偏离计划之处与技术债。Phase 2生成 Epic 完成报告Epic Completion Report这是整个命令信息量最大的环节报告包含 12 个章节详见下一节覆盖从目标达成度、工单明细到风险复盘的完整视图。Phase 3文档更新Documentation Updates强制检查点在修改任何文档前Agent 必须先展示提议的变更包括将 Completion Report 章节追加到 Overview Document展示将要添加的确切内容将 Epic 文档从/Epics/In Progress/{Epic_Key}/移动到/Epics/Complete/Sprint [N]/{Epic_Key}/更新全部工单中的文档链接以指向新位置。用户以Yes / No / Modify作答未经明确批准不得更新任何文档。Phase 4发布与关闭Publish Close将完成报告发布为 Overview Document 的新章节可选新建独立的 Completion Report 子页面移动文档至 Complete 目录并更新全部内部链接更新所有工单补充完成日期、更新文档链接、追加完成报告链接强制检查点Close Epic确认关闭 Epic 将设置状态 Done、更新解决方式为 Completed、添加带报告链接的完成评论未经批准不得关闭正式在 Jira 关闭 Epic生成 sprint 文件夹引用为后续 sprint 回顾记录位置。Phase 5知识转移Knowledge Transfer识别可复用模式记录应推广到后续工作的新模式更新 AGENTS.md新编码规范与 CLAUDE.md新命令/工作流分享关键经验对团队有价值的技术洞见、应采纳的过程改进、被验证有效的工具与技巧更新团队文档架构决策记录ADR、设计模式库、最佳实践指南。12 节完成报告内容与填写要点完成报告是回顾阶段最重要的可交付物。以下是操作手册规定的完整章节结构Epic Summary— Epic 键与标题、起止日期、计划 vs 实际故事点、完成工单数、贡献者名单Objectives Outcomes— 来自 Overview Document 的原始目标与成功指标逐项目标注 Met / Partially Met / Not Met 并说明理由以及可量化的业务影响Ticket Breakdown— 表格逐工单列出键、标题、点数、完成日期、偏离情况汇总总工单数、平均周期时间、含偏离的工单数、后续工单数Technical Deliverables— 新建/修改文件数与主要变更、代码行数增减additions/-deletions、测试覆盖率明细单元测试数量与覆盖率、集成测试、E2E 测试总体目标 90%Architecture Design Decisions— 使用的关键架构模式含影响的文件、设计权衡选择与备选方案及理由、创建的可复用组件Quality Metrics— PR 数量与平均评审时间、评审轮数、开发期与生产期缺陷数、严重问题数、pre-commit/pre-push 钩子通过率与常见失败模式Technical Debt Follow-up— 产生的技术债成因与修复计划、后续工单键、标题、优先级、Sprint 归属、重构机会、性能优化点Testing Quality Assurance— 测试策略有效性是否提前发现问题、覆盖的关键边界用例、新增回归测试数、测试遗漏的问题与改进建议Documentation Delivered— Confluence 页面Overview、Implementation Plan 及其他、代码文档JSDoc 覆盖率、README 更新、API 文档、Runbook 更新Lessons Learned— What Went Well / What Could Be Improved / Process Improvements 三组每条附具体示例Risk Assessment Review— 将规划期风险来自 Overview Document与实际结果对照风险、计划等级、实际影响、缓解有效性同时记录未预期风险及处置方式Recommendations for Future Epics— 按规划、实施、测试三个阶段分别给出可执行的改进建议。这 12 个章节的结构与 docs/WORKFLOW_COMMANDS.md 中 Completion Report Sections 的清单完全一致是该命令在仓库内的权威定义。强制检查点系统为什么每个关键动作都需要人确认回顾命令贯穿始终的检查点MANDATORY CHECKPOINT并非冗余。结合 docs/WORKFLOW_COMMANDS.md 对 Checkpoint System 的说明这套机制服务于四个目的防止对 Jira/Confluence 的意外修改、确保开工前方向一致、提供纠偏机会、维护决策审计轨迹。针对retrospectives:complete-epic共有三个检查点完成就绪确认、文档更新批准、Epic 关闭批准。核心原则是命令绝不能在缺少用户明确批准的情况下修改 Jira 或 ConfluenceCritical Rule。检查点统一支持四种响应Yes继续、No停止并询问所需修改、Modify用户反馈后重新生成再确认、Correct用户纠正后更新再确认。失败条件与降级路径操作手册末尾用表格汇总了全部失败场景及其应对失败条件处置方式Epic 未找到报错并请用户核实 epic key存在未完成工单报告未完成工单等待用户决策文档未找到向用户索要文档位置无法移动 Confluence 页面请用户手动移动并提供操作指引无法在 Jira 关闭 Epic报告错误并提供手动操作说明缺少 git 历史/PR 数据用现有数据生成报告并在报告中标注缺口完成后的标准输出命令完成时Agent 必须以固定模板汇报结果来自操作手册的 Output 段模板包含总故事点计划 → 实际、完成的工单数、工期天数、测试覆盖率目标 90%、后续工单数、文档链接与新位置、关键交付物计数、技术债条目、Top 3 经验教训以及下一步动作。模板最后特别强调CRITICAL: The sprint folder location is needed for sprint retrospective.——sprint 文件夹位置必须被保留记录用于后续 sprint 回顾。进入 Sprint 级回顾complete-sprint当整个 Sprint 的所有 Epic 均完成后可选执行 Sprint 级回顾命令 commands/project/retrospectives/complete-sprint.md。其参数$ARGUMENTS可以是数字如 1、2对应Sprint [N]、或一个 Confluence 文件夹路径默认/Epics/Complete/Sprint [N]/。该命令将 Sprint 内所有 Epic 的 Overview Document、Implementation Plan、Completion Report 全部读取并并行执行六个审查轨道Engineering Excellence— 代码质量模式、反模式、技术债增减、架构决策、性能、依赖管理、CI/CDQuality Assurance— 测试覆盖率起止对比、90% 目标达成、缺陷模式、回归问题、自动化测试与 flaky 测试Security Compliance— 安全漏洞、认证授权、数据隐私与合规要求、安全最佳实践遵守情况Product UX— 功能完成度、验收标准达成率、用户故事质量、UX 一致性、可访问性WCAG、范围蔓延DevOps Infrastructure— CI/CD 稳定性、环境配置、数据库迁移、容器管理、监控日志、性能指标Process Collaboration— 估算准确度计划 vs 实际点数方差、Sprint 规划、阻塞解决、文档质量、跨团队依赖、沟通效率、并行执行效果。六个轨道的结果在 Phase 3 合成为统一回顾报告包含 Executive Summary、Epic Breakdown、What Went Well / What Needs Improvement按轨道分组且必须带具体 Epic 引用、分优先级Critical / High / Medium / Deferred的 Action Items、Patterns Insights可复用模式与反模式、Metrics DashboardVelocity、故事点、缺陷、周期时间、评审、覆盖率、技术债、Knowledge Transfer、Systemic Issues 与回顾会议讨论要点。发布前同样有强制检查点通过后将报告发布到/Retrospectives/Sprint $ARGUMENTS/。需要说明的是docs/WORKFLOW_COMMANDS.md 中有一条备注指出 Sprint-level retrospectives (complete-sprint) have been removed in favor of epic-level analysis withretrospectives:complete-epic而complete-epic.md末尾仍保留了对complete-sprint的引用。从当前仓库文件结构看commands/project/retrospectives/complete-sprint.md 依然存在且内容完整因此本文将其视为可用的可选扩展两者在仓库中的定位差异读者可结合 WORKFLOW_COMMANDS.md 的说明自行判断取舍。回顾产出如何回馈下一轮迭代retrospective-phase.md的 Next Steps 明确指出了闭环的方向更新后的系统描述会进入下一轮循环——当新的特性经由feature-forge技能定义时它会读取当前的系统描述见 skills/feature-forge/SKILL.md 及其 references/specification-template.md使每一轮迭代都比上一轮更知情。这正是本阶段设计的精妙之处回顾阶段产出的updated-system-description不只是一份存档而是下一个 Discovery/Planning 周期的输入基础。逐工单的增量更新容易产生只见树木的盲区而回顾阶段对架构图、API 面、依赖映射的整体复核确保了系统描述始终与代码真实状态对齐从而让整个工作流形成执行 → 回顾 → 系统描述更新 → 下一轮特性定义的正向飞轮。小结回顾阶段是 claude-skills 工作流中唯一负责收口的阶段它通过一次命令完成五件事验证完成、生成 12 节完成报告、归档文档、关闭 Jira Epic、整体性更新系统描述。整套设计围绕三个原则展开人机共治三个强制检查点保证关键动作必有用户批准、数据沉淀完成报告是后续决策与知识转移的权威依据、闭环迭代系统描述更新反哺feature-forge的下一轮特性定义。对于在真实团队中运行 Claude Code 工作流的开发者而言参照 docs/workflow/retrospective-complete-epic.md 与 commands/project/retrospectives/complete-epic.md 中的检查点清单与 12 节报告模板即可将这套收尾机制平滑接入已有的 Jira Confluence 环境。【免费下载链接】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），仅供参考 claude-skills 回顾阶段实战指南：Epic 收尾、12 节完成报告与系统描述闭环更新
claude-skills 回顾阶段实战指南Epic 收尾、12 节完成报告与系统描述闭环更新【免费下载链接】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 仓库的 docs/workflow/retrospective-phase.md 展开。回顾阶段Retrospective Phase是整个工作流生命周期的收尾环节当 Epic 内所有工单执行完毕后由 Agent 一次性完成完成度校验、生成综合完成报告、归档文档、在 Jira 中关闭 Epic并对docs/system-description.md做一次整体性复核更新。读完本文你将掌握retrospectives:complete-epic命令的完整执行链从上下文检索到知识转移、12 节完成报告的具体内容与填写要点、强制检查点与失败条件的处理方式以及回顾产出如何回馈到下一轮feature-forge迭代。为什么需要回顾阶段把 Epic 的闭环真正关上在 claude-skills 的工作流中一个 Epic 会依次经过 intake代码库建档、discovery探索、planning规划、execution执行四个阶段而回顾阶段是最后的收尾动作。根据 docs/workflow/retrospective-phase.md 的定义它的职责包含五件事验证所有工作已完成——逐一核对 Epic 下每个工单的状态生成综合完成报告——沉淀交付物、质量指标、经验教训、风险复盘与改进建议将文档移动到最终位置——从 In Progress 归档到 Complete 目录在工单系统中关闭 Epic——状态置为 Done执行系统描述的整体性复核——捕获逐工单增量更新过程中可能遗漏的架构变更。最后一点尤其关键回顾不是简单地把状态翻成 Done而是对docs/system-description.md做一次全局审视确保架构图、API 面与依赖映射能真实反映 Epic 完成后的系统状态。这正是回顾阶段区别于普通收尾脚本的核心价值。从工作流编排上看回顾阶段并非孤立存在。仓库根目录的 commands/workflow-manifest.yaml 定义了完整的阶段依赖链阶段依赖命令intake无intake:document-codebase、intake:capture-behavior、intake:create-system-descriptiondiscoveryintake建议discovery:create、discovery:synthesize、discovery:approveplanningdiscovery必需planning:epic-plan、planning:impl-planexecutionplanning必需execution:execute-ticket、execution:complete-ticketretrospectivesexecution必需retrospectives:complete-epic也就是说回顾阶段强依赖执行阶段的完成depends_on: execution, strength: required这保证了所有工单执行完毕是进入回顾的前提条件。核心命令retrospectives:complete-epic的输入与输出回顾阶段目前只有一条命令retrospectives:complete-epic。它的接口定义在 commands/project/retrospectives/complete-epic.yaml同时对应的完整操作手册是 docs/workflow/retrospective-complete-epic.md。输入参数参数类型是否必填说明epic-keystring是要关闭的 Jira Epic 键例如CC-62三个产出物产出类型说明completion-reportreport12 节完成报告摘要、目标、工单、交付物、架构、质量、债务、测试、文档、经验、风险、建议closed-epictickets在 Jira 中关闭的 Epic状态 Done、解决方式 Completedupdated-system-descriptionfile经整体性复核后更新的docs/system-description.md前置条件Epic 下所有工单已完成或经用户明确授权后移入 backlogOverview Document概览文档与 Implementation Plan实施计划可在 Confluence 中访问Jira 与 Confluence 访问权限已配置配置方法见 docs/ATLASSIAN_MCP_SETUP.md。调用形态为/project:retrospectives:complete-epic epic-key简写retrospectives:complete-epic每次仅针对一个 Epic命令不可重复执行repeat: false。命令在整条工作流链中的位置commands/project/retrospectives/complete-epic.md 开篇给出了清晰的 Workflow Chaincomplete-epic是执行链的倒数第二步紧随其后是可选的 sprint 级回顾/create-epic-plan epic-key → 创建 Overview Document ↓ /create-implementation-plan overview-doc-url → 创建 Implementation Plan ↓ /execute-ticket ticket-key → 逐个执行工单 ↓ /complete-epic epic-key → 完成 Epic本命令所在位置 ↓ /complete-sprint sprint-folder → Sprint 回顾从 docs/workflow/execution-phase.md 可以印证执行阶段是每工单一循环execute-ticket实现 complete-ticket收尾循环结束的标志是所有工单状态就绪随后进入回顾阶段。分阶段执行流程详解complete-epic的操作手册将整个过程划分为 5 个阶段Phase 0 Phase 5其中每个关键决策点都设置了强制检查点MANDATORY CHECKPOINT要求用户显式确认后才能继续。Phase 0上下文检索Context Retrieval从 Jira 拉取 Epic提取{Epic_Title}、{Jira_Project}、所有关联工单及 Epic 状态在 Confluence 中定位文档Overview Document 位于/Epics/In Progress/{Epic_Key}/Implementation Plan 是其子页面失败条件若文档找不到Agent 必须停下并向用户索要两个 URLOverview Document URL 与 Implementation Plan URL未确认前不得继续强制检查点Epic Completion ReadinessAgent 汇报 Epic 键、标题、总工单数、已完成数、进行中数、阻塞数以及两份文档的位置用户以Yes继续/No列出未完成工单并退出/Review查看详细工单状态作答。存在未完成工单且无用户显式覆盖时禁止继续。Phase 1完成度验证Verification逐一核对 Epic 下每个工单在 Jira 中的状态找出非 Done 的工单、阻塞问题与未解决的依赖失败条件存在未完成工单时Agent 停止并向用户呈现分类清单In Progress / Blocked / To Do给出三个选项A) 先完成剩余工单B) 将未完成工单移入 backlog 后关闭 EpicC) 延长 Epic 截止日期保持打开。等待用户决策后才继续复核实现质量确认与 Epic 工单相关的 PR 均已合并、测试覆盖率是否达到 90% 目标、记录偏离计划之处与技术债。Phase 2生成 Epic 完成报告Epic Completion Report这是整个命令信息量最大的环节报告包含 12 个章节详见下一节覆盖从目标达成度、工单明细到风险复盘的完整视图。Phase 3文档更新Documentation Updates强制检查点在修改任何文档前Agent 必须先展示提议的变更包括将 Completion Report 章节追加到 Overview Document展示将要添加的确切内容将 Epic 文档从/Epics/In Progress/{Epic_Key}/移动到/Epics/Complete/Sprint [N]/{Epic_Key}/更新全部工单中的文档链接以指向新位置。用户以Yes / No / Modify作答未经明确批准不得更新任何文档。Phase 4发布与关闭Publish Close将完成报告发布为 Overview Document 的新章节可选新建独立的 Completion Report 子页面移动文档至 Complete 目录并更新全部内部链接更新所有工单补充完成日期、更新文档链接、追加完成报告链接强制检查点Close Epic确认关闭 Epic 将设置状态 Done、更新解决方式为 Completed、添加带报告链接的完成评论未经批准不得关闭正式在 Jira 关闭 Epic生成 sprint 文件夹引用为后续 sprint 回顾记录位置。Phase 5知识转移Knowledge Transfer识别可复用模式记录应推广到后续工作的新模式更新 AGENTS.md新编码规范与 CLAUDE.md新命令/工作流分享关键经验对团队有价值的技术洞见、应采纳的过程改进、被验证有效的工具与技巧更新团队文档架构决策记录ADR、设计模式库、最佳实践指南。12 节完成报告内容与填写要点完成报告是回顾阶段最重要的可交付物。以下是操作手册规定的完整章节结构Epic Summary— Epic 键与标题、起止日期、计划 vs 实际故事点、完成工单数、贡献者名单Objectives Outcomes— 来自 Overview Document 的原始目标与成功指标逐项目标注 Met / Partially Met / Not Met 并说明理由以及可量化的业务影响Ticket Breakdown— 表格逐工单列出键、标题、点数、完成日期、偏离情况汇总总工单数、平均周期时间、含偏离的工单数、后续工单数Technical Deliverables— 新建/修改文件数与主要变更、代码行数增减additions/-deletions、测试覆盖率明细单元测试数量与覆盖率、集成测试、E2E 测试总体目标 90%Architecture Design Decisions— 使用的关键架构模式含影响的文件、设计权衡选择与备选方案及理由、创建的可复用组件Quality Metrics— PR 数量与平均评审时间、评审轮数、开发期与生产期缺陷数、严重问题数、pre-commit/pre-push 钩子通过率与常见失败模式Technical Debt Follow-up— 产生的技术债成因与修复计划、后续工单键、标题、优先级、Sprint 归属、重构机会、性能优化点Testing Quality Assurance— 测试策略有效性是否提前发现问题、覆盖的关键边界用例、新增回归测试数、测试遗漏的问题与改进建议Documentation Delivered— Confluence 页面Overview、Implementation Plan 及其他、代码文档JSDoc 覆盖率、README 更新、API 文档、Runbook 更新Lessons Learned— What Went Well / What Could Be Improved / Process Improvements 三组每条附具体示例Risk Assessment Review— 将规划期风险来自 Overview Document与实际结果对照风险、计划等级、实际影响、缓解有效性同时记录未预期风险及处置方式Recommendations for Future Epics— 按规划、实施、测试三个阶段分别给出可执行的改进建议。这 12 个章节的结构与 docs/WORKFLOW_COMMANDS.md 中 Completion Report Sections 的清单完全一致是该命令在仓库内的权威定义。强制检查点系统为什么每个关键动作都需要人确认回顾命令贯穿始终的检查点MANDATORY CHECKPOINT并非冗余。结合 docs/WORKFLOW_COMMANDS.md 对 Checkpoint System 的说明这套机制服务于四个目的防止对 Jira/Confluence 的意外修改、确保开工前方向一致、提供纠偏机会、维护决策审计轨迹。针对retrospectives:complete-epic共有三个检查点完成就绪确认、文档更新批准、Epic 关闭批准。核心原则是命令绝不能在缺少用户明确批准的情况下修改 Jira 或 ConfluenceCritical Rule。检查点统一支持四种响应Yes继续、No停止并询问所需修改、Modify用户反馈后重新生成再确认、Correct用户纠正后更新再确认。失败条件与降级路径操作手册末尾用表格汇总了全部失败场景及其应对失败条件处置方式Epic 未找到报错并请用户核实 epic key存在未完成工单报告未完成工单等待用户决策文档未找到向用户索要文档位置无法移动 Confluence 页面请用户手动移动并提供操作指引无法在 Jira 关闭 Epic报告错误并提供手动操作说明缺少 git 历史/PR 数据用现有数据生成报告并在报告中标注缺口完成后的标准输出命令完成时Agent 必须以固定模板汇报结果来自操作手册的 Output 段模板包含总故事点计划 → 实际、完成的工单数、工期天数、测试覆盖率目标 90%、后续工单数、文档链接与新位置、关键交付物计数、技术债条目、Top 3 经验教训以及下一步动作。模板最后特别强调CRITICAL: The sprint folder location is needed for sprint retrospective.——sprint 文件夹位置必须被保留记录用于后续 sprint 回顾。进入 Sprint 级回顾complete-sprint当整个 Sprint 的所有 Epic 均完成后可选执行 Sprint 级回顾命令 commands/project/retrospectives/complete-sprint.md。其参数$ARGUMENTS可以是数字如 1、2对应Sprint [N]、或一个 Confluence 文件夹路径默认/Epics/Complete/Sprint [N]/。该命令将 Sprint 内所有 Epic 的 Overview Document、Implementation Plan、Completion Report 全部读取并并行执行六个审查轨道Engineering Excellence— 代码质量模式、反模式、技术债增减、架构决策、性能、依赖管理、CI/CDQuality Assurance— 测试覆盖率起止对比、90% 目标达成、缺陷模式、回归问题、自动化测试与 flaky 测试Security Compliance— 安全漏洞、认证授权、数据隐私与合规要求、安全最佳实践遵守情况Product UX— 功能完成度、验收标准达成率、用户故事质量、UX 一致性、可访问性WCAG、范围蔓延DevOps Infrastructure— CI/CD 稳定性、环境配置、数据库迁移、容器管理、监控日志、性能指标Process Collaboration— 估算准确度计划 vs 实际点数方差、Sprint 规划、阻塞解决、文档质量、跨团队依赖、沟通效率、并行执行效果。六个轨道的结果在 Phase 3 合成为统一回顾报告包含 Executive Summary、Epic Breakdown、What Went Well / What Needs Improvement按轨道分组且必须带具体 Epic 引用、分优先级Critical / High / Medium / Deferred的 Action Items、Patterns Insights可复用模式与反模式、Metrics DashboardVelocity、故事点、缺陷、周期时间、评审、覆盖率、技术债、Knowledge Transfer、Systemic Issues 与回顾会议讨论要点。发布前同样有强制检查点通过后将报告发布到/Retrospectives/Sprint $ARGUMENTS/。需要说明的是docs/WORKFLOW_COMMANDS.md 中有一条备注指出 Sprint-level retrospectives (complete-sprint) have been removed in favor of epic-level analysis withretrospectives:complete-epic而complete-epic.md末尾仍保留了对complete-sprint的引用。从当前仓库文件结构看commands/project/retrospectives/complete-sprint.md 依然存在且内容完整因此本文将其视为可用的可选扩展两者在仓库中的定位差异读者可结合 WORKFLOW_COMMANDS.md 的说明自行判断取舍。回顾产出如何回馈下一轮迭代retrospective-phase.md的 Next Steps 明确指出了闭环的方向更新后的系统描述会进入下一轮循环——当新的特性经由feature-forge技能定义时它会读取当前的系统描述见 skills/feature-forge/SKILL.md 及其 references/specification-template.md使每一轮迭代都比上一轮更知情。这正是本阶段设计的精妙之处回顾阶段产出的updated-system-description不只是一份存档而是下一个 Discovery/Planning 周期的输入基础。逐工单的增量更新容易产生只见树木的盲区而回顾阶段对架构图、API 面、依赖映射的整体复核确保了系统描述始终与代码真实状态对齐从而让整个工作流形成执行 → 回顾 → 系统描述更新 → 下一轮特性定义的正向飞轮。小结回顾阶段是 claude-skills 工作流中唯一负责收口的阶段它通过一次命令完成五件事验证完成、生成 12 节完成报告、归档文档、关闭 Jira Epic、整体性更新系统描述。整套设计围绕三个原则展开人机共治三个强制检查点保证关键动作必有用户批准、数据沉淀完成报告是后续决策与知识转移的权威依据、闭环迭代系统描述更新反哺feature-forge的下一轮特性定义。对于在真实团队中运行 Claude Code 工作流的开发者而言参照 docs/workflow/retrospective-complete-epic.md 与 commands/project/retrospectives/complete-epic.md 中的检查点清单与 12 节报告模板即可将这套收尾机制平滑接入已有的 Jira Confluence 环境。【免费下载链接】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），仅供参考