claude-skills 的 Discovery Phase 详解从 feature-forge 未知项到可执行 Jira 史诗的研究工作流【免费下载链接】claude-skills67 Specialized Skills for Full-Stack Developers. Transform Claude Code into your expert pair programmer.项目地址: https://gitcode.com/GitHub_Trending/claud/claude-skills导读Discovery Phase 是 claude-skills 工作流体系Discovery → Planning → Execution → Retrospectives中最前置、也是最容易被人忽视的一环当 feature-forge 产出的规格中暴露出现有知识无法回答的未知项需要用户访谈、竞品分析或技术 spike时Discovery Phase 为这些研究提供结构化框架并把研究成果最终转化为落地的 Epic 与 Ticket。读完本文你将掌握discovery:create/discovery:synthesize/discovery:approve三个命令的完整调用链、每一步生成的核心文档结构、以及贯穿全程的人工 Checkpoint 监督机制。一、Discovery Phase 的定位为什么不是每个功能都需要研究Discovery Phase 在 docs/workflow/discovery-phase.md 中被明确定义为Optional research phase可选研究阶段。它不是默认必经之路——只有当 feature-forge 访谈环节暴露出无法从既有知识回答的问题时这些未知项才会被路由到 Discovery。触发 Discovery 的典型未知项包括用户访谈需求无法确认用户是否真的需要 X这一类假设竞品分析需求需要对比竞品才能确定的定位与取舍技术 Spike 待办集成可行性、性能影响等无法靠推理得出结论的问题。这种按需触发的设计避免了为每个功能都做一遍沉重的调研流程。与此对应docs/workflow/planning-phase.md 也明确指出对于需求清晰、无重大未知的 Epic可以直接跳过 Discovery 进入规划阶段。整个生命周期在 docs/WORKFLOW_COMMANDS.md 中有完整的 mermaid 流程图与文档流转总表Discovery Document → Synthesis Document → Jira Tickets → Overview → Implementation Plan → Code → Completion Report。触发源feature-forge 与 Discovery RecommendationDiscovery 的输入侧依赖feature-forge技能。在 docs/workflow/discovery-phase.md 的 Prerequisites 中第一条就是Feature-forge spec with Discovery Recommendation section (recommended)——即 feature-forge 产出的规格文档中应包含一个建议是否进入 Discovery的章节。feature-forge 本身的访谈与规格模板可参见 skills/feature-forge/SKILL.md 及其 references。二、三个命令的总览与配置映射Discovery Phase 的核心由三个按顺序执行的命令组成。命令的中枢定义位于 commands/workflow-manifest.yaml 同级的命令目录中每个命令的元数据输入、输出、所需集成、参数提示分别声明在各自的 YAML 文件里顺序命令摘要命令实现Markdown元数据YAML1discovery:create创建带有研究问题与假设的结构化发现工作区create-epic-discovery.mdcreate.yaml2discovery:synthesize将研究产物整合为发现、建议与拟议 ticketsynthesize-discovery.mdsynthesize.yaml3discovery:approve解决阻塞性决策并在工单系统中创建 ticketapprove-synthesis.mdapprove.yaml在 Claude Code 中使用时命令以/project:discovery:create-epic-discovery epic-key这种全名形式触发见 docs/WORKFLOW_COMMANDS.md 的 Command Reference 表三个命令对应的斜杠命令别名则是/create-epic-discovery、/synthesize-discovery、/approve-synthesis。从 YAML 元数据可以确认三条关键信息三个命令的phase字段均为discoverystatus均为existing已实现不同于 Intake 阶段命令的 Planned 状态每个命令都声明了requires: [ticketing, documentation]即都需要 Jira 与 Confluence 集成命令均设置repeat: false属于单次执行命令。阶段之间的人工研究窗口值得强调的是第 1 步与第 2 步之间是留给人类执行真实研究的。正如 docs/workflow/discovery-phase.md 所述用户访谈、技术 Spike、竞品分析、设计冲刺design sprints都发生在这个窗口。Agent 负责搭建框架与整合结论而研究本身需要人类参与——这是整个工作流人机协作设计的关键体现。三、discovery:create搭建研究脚手架输入与输出命令配置create.yaml明确定义了唯一必填参数输入epic-keystring必填Jira Discovery Epic 的 key例如CC-60输出discovery-documenturl发布到 Confluence 的页面路径为/epics/Discovery/{epic-key}/。执行流程对应 create-epic-discovery.mdPhase 0 — Context Retrieval先从 Jira 拉取 Epic 及其关联 ticket提取 Epic 标题、Jira 项目 URL、关联 ticket 列表并确定 Confluence 发布位置默认/Epics/Discovery/{Epic_Key}/。该阶段有两个硬性停止条件Failure ConditionEpic 找不到或没有关联 ticket 时必须 STOP 并向用户提示[epic not found / no linked tickets / access denied]要求确认 Epic key、Jira 项目 URL 与发布位置Mandatory Checkpoint发布前必须向用户展示 Epic Key、Epic Title、Linked Tickets 数量与 Publish Location获得明确确认Yes / No / Correct才能继续。Phase 1 — Question Extraction使用 JQL 查询Epic Link {Epic_Key}读取全部子 ticket提取显式问题与隐式问题来自模糊需求、需要验证的假设、未知项清单并将问题按主题归类Customer/User Discovery谁在用、什么问题、什么工作流Technical Feasibility能否构建、复杂度如何Business Viability值不值得做、ROI 如何Integration Points外部系统、API、数据源Scope Boundaries做什么、不做什么随后为每个问题匹配合适的研究方法用户访谈、数据分析、技术 Spike/POC、竞品研究、专家咨询、原型设计。Phase 2 — Discovery Document Creation生成包含九个章节的发现文档这是整个发现阶段的核心交付物Discovery Overview— Epic 链接、发现目标、成功标准、时间线与干系人Hypothesis Map— 假设表Hypothesis ID / Statement / Confidence / Validation Method / Status例如H1: Users need X because Y、H2: We can integrate with ZResearch Questions Matrix— 按客户/技术/商业/范围四个维度组织的优先级问题矩阵ID / Question / Priority / Method / Owner / StatusDependencies Blockers— 外部依赖、内部依赖、信息阻塞项、时间线依赖Research Plan— 每个高优先级问题配一份研究活动模板Activity / Questions Addressed / Method / Participants / Expected Duration / OutputDecision Framework— 决策点、选项、评估标准与负责人例如 Build vs Buy、目标用户细分Risk Register— 风险、可能性、影响、缓解措施与负责人Target Implementation Epics— 研究成果可能流入的落地 Epic 列表Linked Tickets— 关联 ticket 及其对应的发现焦点。Phase 3/4 — Review Publish再次经过 Mandatory Checkpoint展示研究问题数、假设数、高优先级问题数、目标 Epic 列表用户批准后才发布到 Confluence页面标题格式为{Epic_Key} Discovery - {Epic_Title}。发布完成后必须输出发现文档 URL——这个 URL 是后续 synthesize 步骤的必需输入文档中对此标注为 CRITICAL。命令的失败条件矩阵还覆盖了 Epic key 不存在、无关联 ticket可询问是否生成最小文档、Confluence 位置无效、Jira/Confluence 凭据缺失等场景。四、discovery:synthesize跨源整合研究结论输入与输出根据 synthesize.yaml输入source-urlslist[url]必填——一个或多个 Confluence 文档 URLtargetstring可选——目标实现 Epic key例如--targetCC-62缺省时从来源文档自动探测输出synthesis-documenturl发布路径为/epics/Discovery/{discovery-epic-key}/Synthesis/。参数用法见 synthesize-discovery.md支持多种组合/synthesize-discovery https://confluence/doc1 /synthesize-discovery https://confluence/doc1 https://confluence/doc2 /synthesize-discovery https://confluence/doc1 --targetCC-62支持的来源类型包括Discovery 文档、研究发现文档、访谈纪要、技术 Spike 报告、竞品分析文档以及任何包含结构化发现的 Confluence 页面。执行流程Phase 0 — Source Retrieval拉取全部来源文档从每份文档提取文档类型、关键发现、已验证/证伪的假设、已回答的研究问题、剩余未知项与建议确定目标实现 Epic--target优先其次从 Target Implementation Epics 章节提取都没有则询问用户。同样存在 Failure Condition来源不可达或未找到目标 Epic 时 STOP与 Mandatory Checkpoint列出来源清单与目标 Epic 请用户确认。Phase 1 — Cross-Source Analysis合并假设验证结果、综合研究问题答案、识别一致主题与矛盾冲突建立 Findings InventoryFinding ID / Source / Category / Finding / Confidence / Actionable并记录跨来源反复出现的模式、收敛性结论以及仍待解决的未知项。Phase 2 — Recommendation Generation对每个可行动的发现判断是否应成为 ticket、工作类型Feature / Enhancement / Spike / Research、归属哪个实现 Epic、优先级、依赖关系。输出 Recommendation MatrixRec ID / Based On / Title / Type / Target Epic / Priority / Dependencies并识别需要干系人输入的 Scope 决策。Phase 3 — Synthesis Document Creation生成综合文档关键章节包括Executive Summary— 关键洞察、总体方向建议、置信度、需要的主要决策Consolidated Findings— 已验证/部分验证/证伪的假设表、已回答研究问题表、按主题用户/技术/商业组织的关键洞察叙述Remaining Unknowns— 未知项、影响、建议与优先级Recommendations by Epic— 每个目标 Epic 的推荐 ticket 表含 Story Points、依赖与 Based On、MVP 范围建议、风险调整Decision Log 与 Blocking Decisions— 决策表 必须解决的阻塞决策表D1/D2...Source Cross-Reference— 发现到来源的可追溯映射Proposed Tickets Data— 机器可读的 JSON 区块见下节供 approve 命令消费。机器可读的 Proposed Tickets JSON这是 synthesize 输出中最重要的结构化部分被!-- PROPOSED_TICKETS_START --与!-- PROPOSED_TICKETS_END --标记包裹结构示意如下{ version: 1.0, synthesis_url: [this document URL], discovery_epic: [Discovery Epic Key], blocking_decisions: [ { id: D1, question: [decision question], options: [A, B, C], status: pending, resolution: null, blocks_tickets: [T1, T3] } ], proposed_tickets: [ { id: T1, title: [Ticket title], type: Story, target_epic: CC-62, priority: High, story_points: 5, dependencies: [], blocked_by_decisions: [D1], based_on_findings: [F1, F2], description: [Full ticket description], acceptance_criteria: [Criterion 1, Criterion 2], notes_from_discovery: [Relevant insights] } ], approval_status: pending, approved_by: null, approved_date: null }其中blocking_decisions与proposed_tickets是discovery:approve的解析入口approval_status会在批准后被改写为approved。synthesize 阶段的 Checkpoint 同样强制发布前展示来源数、发现数、验证/证伪假设数、拟议 ticket 数与待决阻塞决策数获用户批准后才发布到/epics/Discovery/{Discovery_Epic_Key}/Synthesis/并同步在发现文档与目标 Epic 中补上综合文档链接与拟议 ticket 摘要。五、discovery:approve解决决策并落地 Jira 工单输入与输出根据 approve.yaml输入synthesis-urlurl必填decisionslist[string]可选用于预置决策解析例如--decisionD1:B --decisionD2:Y输出created-ticketstickets——创建在目标实现 Epic 下的 Jira ticket链接到 Discovery Epic包含完整描述与验收标准。执行流程对应 approve-synthesis.mdPhase 0 — Context Retrieval拉取综合文档提取 Discovery Epic 链接、目标 Epic、Proposed Tickets JSON注意它是从!-- PROPOSED_TICKETS_START --与!-- PROPOSED_TICKETS_END --标记之间解析的以及阻塞决策与批准状态。两个 Failure Condition综合文档缺失找不到 / 缺 Proposed Tickets 章节 / JSON 无效→ STOP 要求验证综合文档已批准approval_status: approved→ STOP 并给出选项查看已建工单 / 追加创建 / 取消。Phase 1 — Decision Resolution解析blocking_decisions数组先应用--decisionID:Value预置解析校验决策 ID 存在、值合法再以交互方式逐个呈现仍待决的决策含选项 A/B/C、综合文档给出的推荐与理由、被阻塞的工单 T1/T3/T5所有决策未解决前不得创建 ticket。每次解析都会记录选项、解析人用户与时间戳并在决策改变范围时更新受影响的 ticket。Phase 2 — Ticket Review Editing展示拟议 ticket 列表按 Epic 分组含 ID、标题、类型、点数、优先级、依赖用户可选择Approve / Edit / Cancel。Edit 模式支持 Add如 Add Story Implement caching to CC-62、Remove如 Remove T3、Modify如 Modify T1 points to 8的循环编辑直到输入 Done 回到最终批准 Checkpoint——没有显式的 Yes 绝不创建 ticket。Phase 3 — Ticket Creation在目标 Epic 下逐张创建 ticket设置字段Summary、TypeStory/Task/Bug/Spike、Epic Link、Story Points、Priority并打上from-discovery与{Discovery_Epic_Key}标签。描述使用统一模板包含 SourceDiscovery Epic / Synthesis 文档 / Based on Findings、Context、Summary、Acceptance Criteria、Notes from Discovery、Decisions Made。随后用 Jira issue link 建立工单依赖inward_issue_key blocker、outward_issue_key blocked链接语义可参见 atlassian-mcp 的 jira-queries 参考并维护{ T1: CC-123, T2: CC-124, ... }的映射。单张创建失败时提供 Retry / Skip / Stop 三个选项。Phase 4 — Update Output在综合文档中追加 Section 10: Approved Tickets含批准日期、批准人、已创建工单表、决策解析表、与原提案的差异清单将 Section 9 的 JSON 中approval_status更新为approved并补上approved_by、approved_date、created_tickets映射同时在 Discovery Epic 中补记综合文档链接与工单摘要。六、贯穿全程的 Checkpoint 机制人类监督是硬性约束三个命令尽管职责不同共享同一种质量门禁设计哲学详见 docs/WORKFLOW_COMMANDS.md 的 Checkpoint System 章节命令在任何情况下都不得未经用户明确批准就修改 Jira 或 Confluence。Discovery 阶段涉及的 Checkpoint 类型与命令对应关系如下命令必经 Checkpointdiscovery:createEpic 确认、发布前文档审查discovery:synthesize来源确认、发布前综合文档审查discovery:approve决策解析、工单修改、工单创建批准Checkpoint 的响应约定为Yes继续No停止并询问需要什么变更Modify用户反馈后重新生成再确认Correct用户纠正后更新再确认。这套机制一方面防止 Agent 对工单系统的意外写入另一方面为关键决策保留完整审计轨迹。七、输出物、前置条件与后续衔接三阶段输出物汇总Discovery Document发现文档——研究问题、假设、研究计划发布于/epics/Discovery/{epic-key}/Synthesis Document综合文档——整合后的发现、建议、带阻塞决策的拟议 ticket发布于/epics/Discovery/{discovery-epic-key}/Synthesis/Tickets工单——在工单系统中创建、以研究为依据的 Epic 与 Ticket。前置条件Feature-forge 规格文档建议包含 Discovery Recommendation 章节Jira 工单系统访问权限与 Confluence 的配置方法见 docs/ATLASSIAN_MCP_SETUP.md该技能能力总览见 skills/atlassian-mcp/SKILL.mdConfluence 文档系统访问权限。与 Planning 阶段的衔接Discovery 完成后即进入规划阶段docs/workflow/planning-phase.md先由planning:epic-plan分析代码库与工单、产出干系人可读的 Overview 文档含 7 维风险评分再由planning:impl-plan将其转化为带拓扑排序执行顺序、并行执行波次与 agent 推荐的实现计划并把每个 Jira ticket 充实为自包含的实现细节文件路径、代码片段、测试代码与验收标准。若采用完整的 Discovery-First 流程整个链路的形态为discovery:create → [人工研究] → discovery:synthesize → discovery:approve → planning:epic-plan → planning:impl-plan → [execution:execute-ticket execution:complete-ticket] × N → retrospectives:complete-epic而需求清晰、无需研究的 Epic 则可以直接走标准实现流程planning:epic-plan → planning:impl-plan → ...这也再次印证了 Discovery 的可选、按需定位。八、关键实现与文档索引若要在仓库中深入研读本阶段建议按以下路径展开阶段总览docs/workflow/discovery-phase.md三个命令的规格文档docs/workflow/discovery-create.md、docs/workflow/discovery-synthesize.md、docs/workflow/discovery-approve.md命令元数据与参数声明commands/project/discovery/create.yaml、commands/project/discovery/synthesize.yaml、commands/project/discovery/approve.yaml命令的完整执行提示词分阶段流程、失败条件、Checkpoint、输出模板commands/project/discovery/create-epic-discovery.md、commands/project/discovery/synthesize-discovery.md、commands/project/discovery/approve-synthesis.md全生命周期、集成点与 Checkpoint 总表docs/WORKFLOW_COMMANDS.md触发源技能skills/feature-forge/SKILL.md 及 specification-templateJira/Confluence 配置与链接语义docs/ATLASSIAN_MCP_SETUP.md、skills/atlassian-mcp/references/jira-queries.md需要说明的是当前仓库提供的是命令提示词与元数据定义实际执行依赖 Jira Confluence 的外部集成配置见 ATLASSIAN_MCP_SETUP。因此在生产环境中运行本阶段命令前应确认 Epic 已存在于 Jira 且关联了 ticket、Jira 与 Confluence 访问已就绪并准备好 feature-forge 产出的规格文档作为触发依据。【免费下载链接】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），仅供参考