get-shit-done 处理小改动时 /gsd-fast 与 /gsd-quick 的边界怎么划分【免费下载链接】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中做小改动时有两个容易混淆的入口/gsd-fast和/gsd-quick。两者都能处理正式 phase 流程之外的零散任务但执行路径完全不同——一个是纯内联执行一个走 planner executor 子代理并留下完整的任务档案。用错了不是功能损坏而是要么白白付出规划开销要么把需要验证的多步任务塞进了本应“一分钟完成”的通道。本文依据仓库文档给出两者的边界判定规则、各自的执行与验证方式。文档给出的边界判定标准GSD 文档对两者的分工写得非常直白见 docs/FEATURES.md 的 Fast Mode 章节和 docs/COMMANDS.md/gsd-fast—— 能用一句话描述、2 分钟内可执行的任务修 typo、改配置值、小重构、补一次忘掉的提交、简单新增。/gsd-quick—— 任何需要研究、多步规划或验证的任务。/gsd-fast的工作流get-shit-done/workflows/fast.md在执行前有一个scope_check步骤任务必须同时满足以下条件才算“trivial”文件编辑数 ≤ 3 处工作量 ≤ 1 分钟不引入新依赖、不改架构不需要研究。只要任务看起来不像 trivial多文件重构、新功能、需要查资料/gsd-fast会直接停下来并提示改用This looks like it needs planning. Use /gsd:quick instead: /gsd:quick {task description}guardrail 部分还有两条强制规则如果实际执行中编辑超过 3 个文件立即 STOP 并转给/gsd:quick如果实现方式拿不准同样 STOP 并转给/gsd:quick。所以边界不是“你觉得”而是内建在 fast 工作流里的检查。/gsd-fast内联执行与它的验证方式/gsd-fast的路径是 understand → do → commit → log全程在当前上下文完成明确禁止三件事见 commands/gsd/fast.md 的 allowed-tools 与工作流 guardrails不派生任何 subagent不生成 PLAN.md 或 SUMMARY.md不做 research 或 plan-checking。基本用法示例命令来自 docs/COMMANDS.md/gsd-fast fix typo in README /gsd-fast add .env to gitignore省略任务描述时会交互式询问Whats the quick fix? (one sentence)。执行完成后fast 工作流按顺序做三件事构成它的“验证”改动本身读相关文件、做修改然后“verify the change works如适用跑现有测试或做快速 sanity check”——这是工作流明确写出的检查动作。原子提交git add -A git commit -m fix: {concise description of what changed}提交信息使用 conventional commit 前缀fix:、feat:、docs:、chore:、refactor:视情况选用。状态记录如果.planning/STATE.md存在且其中已有 Quick Tasks Completed 表格追加一行带fast来源标记和当次日期表格不存在则静默跳过不新建。最终会看到形如以下的完成报告模板来自工作流文档✅ Done: {what was changed} Commit: {short hash} Files: {list of changed files}文档给出的成功判据是任务在当前上下文内完成无 subagent、产生带 conventional 信息的原子提交、STATE.md若存在已更新、整体操作墙钟时间 2 分钟以内。/gsd-quickGSD 保证与它的验证方式/gsd-quickcommands/gsd/quick.md、get-shit-done/workflows/quick.md处理的是“小型但非平凡”的临时任务保留 GSD 的核心保证原子提交、STATE.md 追踪。它与 fast 的关键差异派生gsd-plannerquick 模式gsd-executor子代理任务档案放在.planning/quick/YYMMDD-xxx-slug/下每次任务一个目录含 PLAN.md完成后有 SUMMARY.md独立于 ROADMAP.md 里的计划 phase完成后更新 STATE.md 的 Quick Tasks Completed 表格——注意它不写 ROADMAP.md因为 quick task 不属于计划 phasephase 执行途中也可以使用。前置条件有两个quick 工作流启动时就会检查gsd-sdk必须在 PATH 中否则报错并提示npm install -g get-shit-done-cc或运行/gsd:update项目必须有ROADMAP.md即已经跑过/gsd:new-project的活跃项目。文档原文“Quick mode requires an active project with ROADMAP.md. Run/gsd:new-projectfirst.” 注意它只检查 ROADMAP.md 存在不检查 phase 状态。默认行为是跳过research、discussion、plan-checker 和 verifier——文档建议“use when you know exactly what to do”。不确定时可以组合四个可叠加的 flag/gsd-quick # 基础 quick 任务 /gsd-quick --discuss --research # 讨论 研究 规划 /gsd-quick --validate # 只做 plan-checking最多 2 轮 执行后验证 /gsd-quick --full # 完整质量管线讨论 研究 计划检查 验证--validate和--full会额外产出验证文件${quick_id}-VERIFICATION.md其status取值决定了后续动作文档给出的对照表Status动作passed记为 Verified继续收尾human_needed展示需人工检查的条目记为 Needs Review继续gaps_found展示缺口摘要选择重跑 executor 修复或接受现状quick task 的验证方式还包括三个子命令用于审计累积的任务/gsd-quick list # 列出所有 quick task 及状态 /gsd-quick status my-task-slug # 查看某个 quick task 的状态 /gsd-quick resume my-task-slug # 按 slug 恢复中断的 quick tasklist的展示格式以下为文档示例实际内容以你项目为准Quick Tasks ──────────────────────────────────────────────────────────── slug date status backup-s3-policy 2026-04-10 in-progress auth-token-refresh-fix 2026-04-09 complete ✓ update-node-deps 2026-04-08 abandoned? (7 days, no summary) ──────────────────────────────────────────────────────────── 3 tasks (1 complete, 2 incomplete/in-progress)状态推导规则来自目录与文件的实际存在情况SUMMARY.md 存在且 frontmatterstatuscomplete为complete ✓SUMMARY.md 缺失且目录创建超过 7 天则标记为abandoned? (7 days, no summary)。怎么划这条线一个可操作的判断流程把两边文档的规则合起来判断顺序是任务能不能用一句话描述、3 处以内文件编辑、不碰新依赖和架构能且你知道确切怎么改 →/gsd-fast。任务需要研究实现方案、拆成多步、或执行后要有验证结论是 →/gsd-quick如果你对方案没把握加--research如果任务有值得先澄清的灰色地带加--discuss如果要质量兜底加--validate或直接--full。执行到一半发现改的文件超过了 3 个/gsd-fast会自己停下并把任务指向/gsd:quick——这是 fast 工作流内建的兜底而不是你需要手动判断的分支。还有一个边界情况值得注意/gsd-quick要求项目有ROADMAP.md而/gsd-fast的 STATE.md 记录步骤是“存在则更新、不存在则跳过”。所以在没有跑过 GSD 项目初始化的仓库里fast 依然可以完成“改完 原子提交”这一核心动作只是不会有状态记录quick 则会被前置检查拦下。相关机制与限制workflow_guard 钩子配置项hooks.workflow_guard默认false开启后一个 PreToolUse 钩子会在 Claude 试图在 GSD 工作流上下文之外直接编辑文件时发出警告并建议改用/gsd-quick或/gsd-fast见 docs/CONFIGURATION.md 与 docs/ARCHITECTURE.md。它只是建议性警告不阻断编辑。fast 的硬性禁令/gsd-fast明确 NOT 是/gsd-quick的替代品REQ-FAST-04 规定它不得用于需要研究、多步规划或验证的任务。把需要验证的任务交给 fast验证环节就是缺失的文档没有提供 fast 侧的补偿路径。quick 的 subagent 链quick 会真实派生gsd-planner、gsd-executor--validate/--full时还有gsd-plan-checker、gsd-verifier计划约束是“单个 plan、1–3 个聚焦任务、任务原子且自包含”——超出这个体量说明该任务属于 phase应该走/gsd-plan-phase而不是 quick。两者的状态落点相同fast 与 quick 完成的任务都写进 STATE.md 的 Quick Tasks Completed 表格fast 行带fast标记quick 行带 commit hash 与.planning/quick/目录链接所以用/gsd-quick list只能审计走 quick 通道的任务fast 的记录要回到 STATE.md 查看。按以上边界操作后验证落点是具体的fast 任务看✅ Done报告与 conventional 提交quick 任务看.planning/quick/下的 SUMMARY.md--validate时加看 VERIFICATION.md 的 status、STATE.md 新增行以及/gsd-quick list中的状态列。【免费下载链接】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 处理小改动时 /gsd-fast 与 /gsd-quick 的边界怎么划分
get-shit-done 处理小改动时 /gsd-fast 与 /gsd-quick 的边界怎么划分【免费下载链接】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中做小改动时有两个容易混淆的入口/gsd-fast和/gsd-quick。两者都能处理正式 phase 流程之外的零散任务但执行路径完全不同——一个是纯内联执行一个走 planner executor 子代理并留下完整的任务档案。用错了不是功能损坏而是要么白白付出规划开销要么把需要验证的多步任务塞进了本应“一分钟完成”的通道。本文依据仓库文档给出两者的边界判定规则、各自的执行与验证方式。文档给出的边界判定标准GSD 文档对两者的分工写得非常直白见 docs/FEATURES.md 的 Fast Mode 章节和 docs/COMMANDS.md/gsd-fast—— 能用一句话描述、2 分钟内可执行的任务修 typo、改配置值、小重构、补一次忘掉的提交、简单新增。/gsd-quick—— 任何需要研究、多步规划或验证的任务。/gsd-fast的工作流get-shit-done/workflows/fast.md在执行前有一个scope_check步骤任务必须同时满足以下条件才算“trivial”文件编辑数 ≤ 3 处工作量 ≤ 1 分钟不引入新依赖、不改架构不需要研究。只要任务看起来不像 trivial多文件重构、新功能、需要查资料/gsd-fast会直接停下来并提示改用This looks like it needs planning. Use /gsd:quick instead: /gsd:quick {task description}guardrail 部分还有两条强制规则如果实际执行中编辑超过 3 个文件立即 STOP 并转给/gsd:quick如果实现方式拿不准同样 STOP 并转给/gsd:quick。所以边界不是“你觉得”而是内建在 fast 工作流里的检查。/gsd-fast内联执行与它的验证方式/gsd-fast的路径是 understand → do → commit → log全程在当前上下文完成明确禁止三件事见 commands/gsd/fast.md 的 allowed-tools 与工作流 guardrails不派生任何 subagent不生成 PLAN.md 或 SUMMARY.md不做 research 或 plan-checking。基本用法示例命令来自 docs/COMMANDS.md/gsd-fast fix typo in README /gsd-fast add .env to gitignore省略任务描述时会交互式询问Whats the quick fix? (one sentence)。执行完成后fast 工作流按顺序做三件事构成它的“验证”改动本身读相关文件、做修改然后“verify the change works如适用跑现有测试或做快速 sanity check”——这是工作流明确写出的检查动作。原子提交git add -A git commit -m fix: {concise description of what changed}提交信息使用 conventional commit 前缀fix:、feat:、docs:、chore:、refactor:视情况选用。状态记录如果.planning/STATE.md存在且其中已有 Quick Tasks Completed 表格追加一行带fast来源标记和当次日期表格不存在则静默跳过不新建。最终会看到形如以下的完成报告模板来自工作流文档✅ Done: {what was changed} Commit: {short hash} Files: {list of changed files}文档给出的成功判据是任务在当前上下文内完成无 subagent、产生带 conventional 信息的原子提交、STATE.md若存在已更新、整体操作墙钟时间 2 分钟以内。/gsd-quickGSD 保证与它的验证方式/gsd-quickcommands/gsd/quick.md、get-shit-done/workflows/quick.md处理的是“小型但非平凡”的临时任务保留 GSD 的核心保证原子提交、STATE.md 追踪。它与 fast 的关键差异派生gsd-plannerquick 模式gsd-executor子代理任务档案放在.planning/quick/YYMMDD-xxx-slug/下每次任务一个目录含 PLAN.md完成后有 SUMMARY.md独立于 ROADMAP.md 里的计划 phase完成后更新 STATE.md 的 Quick Tasks Completed 表格——注意它不写 ROADMAP.md因为 quick task 不属于计划 phasephase 执行途中也可以使用。前置条件有两个quick 工作流启动时就会检查gsd-sdk必须在 PATH 中否则报错并提示npm install -g get-shit-done-cc或运行/gsd:update项目必须有ROADMAP.md即已经跑过/gsd:new-project的活跃项目。文档原文“Quick mode requires an active project with ROADMAP.md. Run/gsd:new-projectfirst.” 注意它只检查 ROADMAP.md 存在不检查 phase 状态。默认行为是跳过research、discussion、plan-checker 和 verifier——文档建议“use when you know exactly what to do”。不确定时可以组合四个可叠加的 flag/gsd-quick # 基础 quick 任务 /gsd-quick --discuss --research # 讨论 研究 规划 /gsd-quick --validate # 只做 plan-checking最多 2 轮 执行后验证 /gsd-quick --full # 完整质量管线讨论 研究 计划检查 验证--validate和--full会额外产出验证文件${quick_id}-VERIFICATION.md其status取值决定了后续动作文档给出的对照表Status动作passed记为 Verified继续收尾human_needed展示需人工检查的条目记为 Needs Review继续gaps_found展示缺口摘要选择重跑 executor 修复或接受现状quick task 的验证方式还包括三个子命令用于审计累积的任务/gsd-quick list # 列出所有 quick task 及状态 /gsd-quick status my-task-slug # 查看某个 quick task 的状态 /gsd-quick resume my-task-slug # 按 slug 恢复中断的 quick tasklist的展示格式以下为文档示例实际内容以你项目为准Quick Tasks ──────────────────────────────────────────────────────────── slug date status backup-s3-policy 2026-04-10 in-progress auth-token-refresh-fix 2026-04-09 complete ✓ update-node-deps 2026-04-08 abandoned? (7 days, no summary) ──────────────────────────────────────────────────────────── 3 tasks (1 complete, 2 incomplete/in-progress)状态推导规则来自目录与文件的实际存在情况SUMMARY.md 存在且 frontmatterstatuscomplete为complete ✓SUMMARY.md 缺失且目录创建超过 7 天则标记为abandoned? (7 days, no summary)。怎么划这条线一个可操作的判断流程把两边文档的规则合起来判断顺序是任务能不能用一句话描述、3 处以内文件编辑、不碰新依赖和架构能且你知道确切怎么改 →/gsd-fast。任务需要研究实现方案、拆成多步、或执行后要有验证结论是 →/gsd-quick如果你对方案没把握加--research如果任务有值得先澄清的灰色地带加--discuss如果要质量兜底加--validate或直接--full。执行到一半发现改的文件超过了 3 个/gsd-fast会自己停下并把任务指向/gsd:quick——这是 fast 工作流内建的兜底而不是你需要手动判断的分支。还有一个边界情况值得注意/gsd-quick要求项目有ROADMAP.md而/gsd-fast的 STATE.md 记录步骤是“存在则更新、不存在则跳过”。所以在没有跑过 GSD 项目初始化的仓库里fast 依然可以完成“改完 原子提交”这一核心动作只是不会有状态记录quick 则会被前置检查拦下。相关机制与限制workflow_guard 钩子配置项hooks.workflow_guard默认false开启后一个 PreToolUse 钩子会在 Claude 试图在 GSD 工作流上下文之外直接编辑文件时发出警告并建议改用/gsd-quick或/gsd-fast见 docs/CONFIGURATION.md 与 docs/ARCHITECTURE.md。它只是建议性警告不阻断编辑。fast 的硬性禁令/gsd-fast明确 NOT 是/gsd-quick的替代品REQ-FAST-04 规定它不得用于需要研究、多步规划或验证的任务。把需要验证的任务交给 fast验证环节就是缺失的文档没有提供 fast 侧的补偿路径。quick 的 subagent 链quick 会真实派生gsd-planner、gsd-executor--validate/--full时还有gsd-plan-checker、gsd-verifier计划约束是“单个 plan、1–3 个聚焦任务、任务原子且自包含”——超出这个体量说明该任务属于 phase应该走/gsd-plan-phase而不是 quick。两者的状态落点相同fast 与 quick 完成的任务都写进 STATE.md 的 Quick Tasks Completed 表格fast 行带fast标记quick 行带 commit hash 与.planning/quick/目录链接所以用/gsd-quick list只能审计走 quick 通道的任务fast 的记录要回到 STATE.md 查看。按以上边界操作后验证落点是具体的fast 任务看✅ Done报告与 conventional 提交quick 任务看.planning/quick/下的 SUMMARY.md--validate时加看 VERIFICATION.md 的 status、STATE.md 新增行以及/gsd-quick list中的状态列。【免费下载链接】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），仅供参考
