尧图网页设计 
get-shit-done 阶段假设清单在规划前显式暴露并校正 Agent 对 Phase 的理解偏差【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done在 get-shit-doneGSD这套面向 Claude Code 的 spec-driven 开发系统中list-phase-assumptions工作流承担着一个容易被忽略却至关重要的职责在正式规划plan-phase之前把 Agent 基于 ROADMAP.md 对某个 Phase 所产生的全部隐性假设显式地摊开给用户看。它不产出任何文件、不做信息输入而是纯粹以对话形式做一次认知对账——让用户尽早纠正误解从而避免带着错误前提进入研究和规划阶段。读完本文你将掌握该工作流的完整调用方式、五个分析维度、置信度标记规范、输出模板与后续衔接路径并能结合源码理解它在 GSD 编排体系中的定位。一、工作流定位分析 Agent 所想而非采集用户所知get-shit-done/workflows/list-phase-assumptions.md的purpose段落开门见山地定义了它的核心意图Surface Claudes assumptions about a phase before planning, enabling users to correct misconceptions early.这里有一个非常关键的设计边界工作流文档特意用一句话点破它与discuss-phase的本质区别Key difference from discuss-phase: This is ANALYSIS of what Claude thinks, not INTAKE of what user knows. No file output - purely conversational to prompt discussion.也就是说discuss-phase是信息采集INTAKE——通过提问获取用户头脑中的知识、偏好与意图list-phase-assumptions是认知分析ANALYSIS——把 Claude 基于 roadmap 和项目上下文推断出的假设暴露出来等待用户验证或纠正。该工作流不产生任何文件输出No file output全程以对话形式驱动讨论这使它可以被嵌入到更大的编排流程中作为一个低成本的规划前检查点。事实上从命令入口 commands/gsd/discuss-phase.md 第 54 行可以看到它被discuss-phase命令显式调用Read and execute ~/.claude/get-shit-done/workflows/list-phase-assumptions.md end-to-end.二、完整流程五个步骤的编排骨架工作流的process部分定义了五个按序执行的步骤每一步都有明确的职责和分支逻辑。步骤一validate_phase —— 验证 Phase 编号优先级 firstPhase 编号通过$ARGUMENTS传入必填。缺失时输出如下错误并退出Error: Phase number required. Usage: /gsd-list-phase-assumptions [phase-number] Example: /gsd-list-phase-assumptions 3提供编号后需要验证该 Phase 确实存在于 roadmap 中验证命令为cat .planning/ROADMAP.md | grep -i Phase ${PHASE}如果 roadmap 中找不到该 Phase输出错误并列出可用 PhaseError: Phase ${PHASE} not found in roadmap. Available phases: [list phases from roadmap]验证通过后从 roadmap 中解析 Phase 的核心信息并进入下一环节Phase 编号Phase numberPhase 名称Phase namePhase 描述/目标Phase description/goal任何提及的范围细节Any scope details mentioned步骤二analyze_phase —— 从五个维度识别假设这是整个工作流的分析核心。基于 roadmap 描述和项目上下文Agent 需要在五个领域内系统性地识别自己的假设详见下一节。同时工作流明确要求 Agent诚实面对不确定性用三级置信度标记标注每条假设Fairly confident: ...—— 从 roadmap 中可以直接看出的结论Assuming: ...—— 基于合理推断得出的结论Unclear: ...—— 存在多种可能的结论无法确定。步骤三present_assumptions —— 以易扫描的格式呈现假设需要以清晰、可快速浏览的格式呈现给用户完整模板见第四节并在末尾抛出关键的确认问题What do you think?随后等待用户响应。步骤四gather_feedback —— 收集并确认反馈根据用户的不同反应分支处理用户提供纠正逐条承认纠正并重新总结理解Key corrections: - [correction 1] - [correction 2] This changes my understanding significantly. [Summarize new understanding]用户确认假设Assumptions validated.步骤五offer_next —— 提供后续路径反馈处理完毕后向用户展示接下来的可选动作Whats next? 1. Discuss context (/gsd:discuss-phase ${PHASE}) - Let me ask you questions to build comprehensive context 2. Plan this phase (/gsd:plan-phase ${PHASE}) - Create detailed execution plans 3. Re-examine assumptions - Ill analyze again with your corrections 4. Done for now各选项的衔接语义如下选择Discuss context注意 CONTEXT.md 将吸收在此讨论中产生的任何纠正选择Plan this phase带着已确认的假设进入规划选择Re-examine携带更新后的理解回到analyze_phase重新分析。三、五个分析维度假设的完整分类体系analyze_phase步骤要求假设覆盖以下五个领域工作流为每个领域都给出了引导性的提问句式1. Technical Approach技术方案Agent 会采用什么库、框架、模式或工具例如Id use X library because...我会用 X 库因为……Id follow Y pattern because...我会遵循 Y 模式因为……Id structure this as Z because...我会按 Z 结构组织因为……2. Implementation Order实施顺序Agent 会先构建什么、再构建什么例如Id start with X because its foundational我会先做 X因为它是基础Then Y because it depends on X然后做 Y因为它依赖 XFinally Z because...最后做 Z因为……3. Scope Boundaries范围边界Agent 对包含什么 / 不包含什么的解读This phase includes: A, B, C本阶段包含 A、B、CThis phase does NOT include: D, E, F本阶段不包含 D、E、FBoundary ambiguities: G could go either way边界模糊点G 两边都可以4. Risk Areas风险区域Agent 预期在哪些地方出现复杂度或挑战The tricky part is X because...棘手的部分是 X因为……Potential issues: Y, Z潜在问题Y、ZId watch out for...我需要警惕……5. Dependencies依赖关系Agent 假设哪些前置条件已存在或需要就位This assumes X from previous phases这假设前一阶段已产出 XExternal dependencies: Y, Z外部依赖Y、ZThis will be consumed by...这将被子阶段/后续阶段消费……这五个维度覆盖了做什么范围、怎么做方案、先做什么顺序、会踩什么坑风险、依赖什么依赖的完整规划前提集合恰好对应后续 research 与 planning 阶段所需的全部决策输入。四、输出模板可复制的呈现格式present_assumptions步骤给出了标准化的输出模板Agent 需严格按此格式呈现## My Assumptions for Phase ${PHASE}: ${PHASE_NAME} ### Technical Approach [List assumptions about how to implement] ### Implementation Order [List assumptions about sequencing] ### Scope Boundaries **In scope:** [whats included] **Out of scope:** [whats excluded] **Ambiguous:** [what could go either way] ### Risk Areas [List anticipated challenges] ### Dependencies **From prior phases:** [whats needed] **External:** [third-party needs] **Feeds into:** [what future phases need from this] --- **What do you think?** Are these assumptions accurate? Let me know: - What I got right - What I got wrong - What Im missing注意模板的刻意设计Scope Boundaries被细分为In scope/Out of scope/Ambiguous三栏Dependencies被细分为From prior phases/External/Feeds into三栏——这种结构化让用户能快速定位到哪一条假设需要纠正而不是面对一段笼统的文字。结尾的 What do you think? 明确邀请用户指出对错与遗漏形成闭环。五、与假设分析模式的协同从清单到证据驱动list-phase-assumptions是对话式的轻量检查点而 GSD 体系中还有一个功能更强、代码库证据驱动的变体discuss-phase-assumptions对应工作流 get-shit-done/workflows/discuss-phase-assumptions.md。两者的分析理念一脉相承——都强调用户是愿景家不是代码考古学家差别在于后者会先深度阅读代码库scout_codebase轻量扫描 deep_codebase_analysis深挖再形成观点每条假设必须引用证据文件路径、发现的模式并说明如果错了会怎样If wrong 后果将确认后的假设固化为 CONTEXT.md 的decisions编号 D-01、D-02……并提交 git将交互次数压到约 24 次纠正对比传统提问式约 1520 个问题。支撑该模式的核心子代理定义在 agents/gsd-assumptions-analyzer.md。它只被授予Read, Bash, Grep, Glob四种工具明确禁止联网与外部工具职责是读取 ROADMAP.md 的 Phase 描述与先前各阶段的 CONTEXT.md用 Glob/Grep 定位与 Phase 目标相关的文件精读 515 个最相关的源文件按校准等级full_maturity/standard/minimal_decisive输出 25 个领域的结构化假设每个假设必须携带Assumption决策陈述 Why this way代码库证据引用文件路径 If wrong具体后果 ConfidenceConfident/Likely/Unclear对代码库不足以回答的主题标记到Needs External Research区块。从 get-shit-done/references/agent-contracts.md 的 Agent Registry 可以看到gsd-assumptions-analyzer属于无完成标记类代理——它不输出## XX COMPLETE之类的标记而是直接返回## Assumptions结构区块由主工作流解析后呈现给用户确认。这正是分析结果必须经用户校验后才能成为决策这一设计哲学的体现。六、成功标准如何判定一次假设清单流程达标工作流success_criteria定义了可度量的完成标准也可视为对 Agent 行为的约束清单Phase 编号已对照 roadmap 完成验证假设覆盖五个领域技术方案、实施顺序、范围、风险、依赖在适当位置标注了置信度等级呈现了 What do you think? 确认提示用户反馈被明确承认提供了清晰的后续步骤选项。值得注意的是该工作流刻意不输出任何文件——这与discuss-phase-assumptions产出 CONTEXT.md、DISCUSSION-LOG.md 并提交 git形成鲜明对比。前者是零成本、纯对话的认知校准后者是带有审计痕迹的决策固化。两者的关系可以概括为先轻量暴露假设、快速纠偏再在确认后进行深度、证据驱动的决策捕获共同构成 GSD 在 research 与 planning 之前的质量闸门。七、实践要点小结在团队或个人项目中用好list-phase-assumptions建议把握以下要点时机在进入plan-phase之前执行尤其是 roadmap 描述较模糊、或跨多个 Phase 的依赖不清晰时收益最大必填参数Phase 编号是硬性入参缺失会立即报错退出核心产出是对齐而非文档不要期待它生成规划文件它的价值在于让用户用几分钟纠正 Agent 的认知偏差避免后续 research/planning 在错误前提上浪费算力与时间与 discuss-phase 配合假设清单完成确认后/gsd:discuss-phase ${PHASE}负责补齐剩余的用户意图输入/gsd:plan-phase ${PHASE}则消费两者产出的完整上下文进入正式规划置信度是诚实的标尺Fairly confident/Assuming/Unclear三级标注不仅是给用户看的也是给 Agent 自己的——标注为 Unclear 的假设就是下一步 discuss 或 research 应优先消除的不确定点。在 spec-driven 开发的流水线上想清楚再做往往比做得多更稀缺。list-phase-assumptions正是 GSD 用最小成本换取这一点的机制它让 Claude 的隐性推理显性化让用户的纠错发生在规划之前而非返工之后。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 get-shit-done 阶段假设清单：在规划前显式暴露并校正 Agent 对 Phase 的理解偏差
get-shit-done 阶段假设清单在规划前显式暴露并校正 Agent 对 Phase 的理解偏差【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done在 get-shit-doneGSD这套面向 Claude Code 的 spec-driven 开发系统中list-phase-assumptions工作流承担着一个容易被忽略却至关重要的职责在正式规划plan-phase之前把 Agent 基于 ROADMAP.md 对某个 Phase 所产生的全部隐性假设显式地摊开给用户看。它不产出任何文件、不做信息输入而是纯粹以对话形式做一次认知对账——让用户尽早纠正误解从而避免带着错误前提进入研究和规划阶段。读完本文你将掌握该工作流的完整调用方式、五个分析维度、置信度标记规范、输出模板与后续衔接路径并能结合源码理解它在 GSD 编排体系中的定位。一、工作流定位分析 Agent 所想而非采集用户所知get-shit-done/workflows/list-phase-assumptions.md的purpose段落开门见山地定义了它的核心意图Surface Claudes assumptions about a phase before planning, enabling users to correct misconceptions early.这里有一个非常关键的设计边界工作流文档特意用一句话点破它与discuss-phase的本质区别Key difference from discuss-phase: This is ANALYSIS of what Claude thinks, not INTAKE of what user knows. No file output - purely conversational to prompt discussion.也就是说discuss-phase是信息采集INTAKE——通过提问获取用户头脑中的知识、偏好与意图list-phase-assumptions是认知分析ANALYSIS——把 Claude 基于 roadmap 和项目上下文推断出的假设暴露出来等待用户验证或纠正。该工作流不产生任何文件输出No file output全程以对话形式驱动讨论这使它可以被嵌入到更大的编排流程中作为一个低成本的规划前检查点。事实上从命令入口 commands/gsd/discuss-phase.md 第 54 行可以看到它被discuss-phase命令显式调用Read and execute ~/.claude/get-shit-done/workflows/list-phase-assumptions.md end-to-end.二、完整流程五个步骤的编排骨架工作流的process部分定义了五个按序执行的步骤每一步都有明确的职责和分支逻辑。步骤一validate_phase —— 验证 Phase 编号优先级 firstPhase 编号通过$ARGUMENTS传入必填。缺失时输出如下错误并退出Error: Phase number required. Usage: /gsd-list-phase-assumptions [phase-number] Example: /gsd-list-phase-assumptions 3提供编号后需要验证该 Phase 确实存在于 roadmap 中验证命令为cat .planning/ROADMAP.md | grep -i Phase ${PHASE}如果 roadmap 中找不到该 Phase输出错误并列出可用 PhaseError: Phase ${PHASE} not found in roadmap. Available phases: [list phases from roadmap]验证通过后从 roadmap 中解析 Phase 的核心信息并进入下一环节Phase 编号Phase numberPhase 名称Phase namePhase 描述/目标Phase description/goal任何提及的范围细节Any scope details mentioned步骤二analyze_phase —— 从五个维度识别假设这是整个工作流的分析核心。基于 roadmap 描述和项目上下文Agent 需要在五个领域内系统性地识别自己的假设详见下一节。同时工作流明确要求 Agent诚实面对不确定性用三级置信度标记标注每条假设Fairly confident: ...—— 从 roadmap 中可以直接看出的结论Assuming: ...—— 基于合理推断得出的结论Unclear: ...—— 存在多种可能的结论无法确定。步骤三present_assumptions —— 以易扫描的格式呈现假设需要以清晰、可快速浏览的格式呈现给用户完整模板见第四节并在末尾抛出关键的确认问题What do you think?随后等待用户响应。步骤四gather_feedback —— 收集并确认反馈根据用户的不同反应分支处理用户提供纠正逐条承认纠正并重新总结理解Key corrections: - [correction 1] - [correction 2] This changes my understanding significantly. [Summarize new understanding]用户确认假设Assumptions validated.步骤五offer_next —— 提供后续路径反馈处理完毕后向用户展示接下来的可选动作Whats next? 1. Discuss context (/gsd:discuss-phase ${PHASE}) - Let me ask you questions to build comprehensive context 2. Plan this phase (/gsd:plan-phase ${PHASE}) - Create detailed execution plans 3. Re-examine assumptions - Ill analyze again with your corrections 4. Done for now各选项的衔接语义如下选择Discuss context注意 CONTEXT.md 将吸收在此讨论中产生的任何纠正选择Plan this phase带着已确认的假设进入规划选择Re-examine携带更新后的理解回到analyze_phase重新分析。三、五个分析维度假设的完整分类体系analyze_phase步骤要求假设覆盖以下五个领域工作流为每个领域都给出了引导性的提问句式1. Technical Approach技术方案Agent 会采用什么库、框架、模式或工具例如Id use X library because...我会用 X 库因为……Id follow Y pattern because...我会遵循 Y 模式因为……Id structure this as Z because...我会按 Z 结构组织因为……2. Implementation Order实施顺序Agent 会先构建什么、再构建什么例如Id start with X because its foundational我会先做 X因为它是基础Then Y because it depends on X然后做 Y因为它依赖 XFinally Z because...最后做 Z因为……3. Scope Boundaries范围边界Agent 对包含什么 / 不包含什么的解读This phase includes: A, B, C本阶段包含 A、B、CThis phase does NOT include: D, E, F本阶段不包含 D、E、FBoundary ambiguities: G could go either way边界模糊点G 两边都可以4. Risk Areas风险区域Agent 预期在哪些地方出现复杂度或挑战The tricky part is X because...棘手的部分是 X因为……Potential issues: Y, Z潜在问题Y、ZId watch out for...我需要警惕……5. Dependencies依赖关系Agent 假设哪些前置条件已存在或需要就位This assumes X from previous phases这假设前一阶段已产出 XExternal dependencies: Y, Z外部依赖Y、ZThis will be consumed by...这将被子阶段/后续阶段消费……这五个维度覆盖了做什么范围、怎么做方案、先做什么顺序、会踩什么坑风险、依赖什么依赖的完整规划前提集合恰好对应后续 research 与 planning 阶段所需的全部决策输入。四、输出模板可复制的呈现格式present_assumptions步骤给出了标准化的输出模板Agent 需严格按此格式呈现## My Assumptions for Phase ${PHASE}: ${PHASE_NAME} ### Technical Approach [List assumptions about how to implement] ### Implementation Order [List assumptions about sequencing] ### Scope Boundaries **In scope:** [whats included] **Out of scope:** [whats excluded] **Ambiguous:** [what could go either way] ### Risk Areas [List anticipated challenges] ### Dependencies **From prior phases:** [whats needed] **External:** [third-party needs] **Feeds into:** [what future phases need from this] --- **What do you think?** Are these assumptions accurate? Let me know: - What I got right - What I got wrong - What Im missing注意模板的刻意设计Scope Boundaries被细分为In scope/Out of scope/Ambiguous三栏Dependencies被细分为From prior phases/External/Feeds into三栏——这种结构化让用户能快速定位到哪一条假设需要纠正而不是面对一段笼统的文字。结尾的 What do you think? 明确邀请用户指出对错与遗漏形成闭环。五、与假设分析模式的协同从清单到证据驱动list-phase-assumptions是对话式的轻量检查点而 GSD 体系中还有一个功能更强、代码库证据驱动的变体discuss-phase-assumptions对应工作流 get-shit-done/workflows/discuss-phase-assumptions.md。两者的分析理念一脉相承——都强调用户是愿景家不是代码考古学家差别在于后者会先深度阅读代码库scout_codebase轻量扫描 deep_codebase_analysis深挖再形成观点每条假设必须引用证据文件路径、发现的模式并说明如果错了会怎样If wrong 后果将确认后的假设固化为 CONTEXT.md 的decisions编号 D-01、D-02……并提交 git将交互次数压到约 24 次纠正对比传统提问式约 1520 个问题。支撑该模式的核心子代理定义在 agents/gsd-assumptions-analyzer.md。它只被授予Read, Bash, Grep, Glob四种工具明确禁止联网与外部工具职责是读取 ROADMAP.md 的 Phase 描述与先前各阶段的 CONTEXT.md用 Glob/Grep 定位与 Phase 目标相关的文件精读 515 个最相关的源文件按校准等级full_maturity/standard/minimal_decisive输出 25 个领域的结构化假设每个假设必须携带Assumption决策陈述 Why this way代码库证据引用文件路径 If wrong具体后果 ConfidenceConfident/Likely/Unclear对代码库不足以回答的主题标记到Needs External Research区块。从 get-shit-done/references/agent-contracts.md 的 Agent Registry 可以看到gsd-assumptions-analyzer属于无完成标记类代理——它不输出## XX COMPLETE之类的标记而是直接返回## Assumptions结构区块由主工作流解析后呈现给用户确认。这正是分析结果必须经用户校验后才能成为决策这一设计哲学的体现。六、成功标准如何判定一次假设清单流程达标工作流success_criteria定义了可度量的完成标准也可视为对 Agent 行为的约束清单Phase 编号已对照 roadmap 完成验证假设覆盖五个领域技术方案、实施顺序、范围、风险、依赖在适当位置标注了置信度等级呈现了 What do you think? 确认提示用户反馈被明确承认提供了清晰的后续步骤选项。值得注意的是该工作流刻意不输出任何文件——这与discuss-phase-assumptions产出 CONTEXT.md、DISCUSSION-LOG.md 并提交 git形成鲜明对比。前者是零成本、纯对话的认知校准后者是带有审计痕迹的决策固化。两者的关系可以概括为先轻量暴露假设、快速纠偏再在确认后进行深度、证据驱动的决策捕获共同构成 GSD 在 research 与 planning 之前的质量闸门。七、实践要点小结在团队或个人项目中用好list-phase-assumptions建议把握以下要点时机在进入plan-phase之前执行尤其是 roadmap 描述较模糊、或跨多个 Phase 的依赖不清晰时收益最大必填参数Phase 编号是硬性入参缺失会立即报错退出核心产出是对齐而非文档不要期待它生成规划文件它的价值在于让用户用几分钟纠正 Agent 的认知偏差避免后续 research/planning 在错误前提上浪费算力与时间与 discuss-phase 配合假设清单完成确认后/gsd:discuss-phase ${PHASE}负责补齐剩余的用户意图输入/gsd:plan-phase ${PHASE}则消费两者产出的完整上下文进入正式规划置信度是诚实的标尺Fairly confident/Assuming/Unclear三级标注不仅是给用户看的也是给 Agent 自己的——标注为 Unclear 的假设就是下一步 discuss 或 research 应优先消除的不确定点。在 spec-driven 开发的流水线上想清楚再做往往比做得多更稀缺。list-phase-assumptions正是 GSD 用最小成本换取这一点的机制它让 Claude 的隐性推理显性化让用户的纠错发生在规划之前而非返工之后。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考