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-done（GSD）中做小改动时，有两个容易混淆的入口：/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"

省略任务描述时会交互式询问What's 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-quick：GSD 保证与它的验证方式

/gsd-quick（commands/gsd/quick.md、get-shit-done/workflows/quick.md）处理的是“小型但非平凡”的临时任务，保留 GSD 的核心保证：原子提交、STATE.md 追踪。它与 fast 的关键差异：

派生gsd-planner（quick 模式）+gsd-executor子代理；
任务档案放在.planning/quick/YYMMDD-xxx-slug/下（每次任务一个目录，含 PLAN.md，完成后有 SUMMARY.md），独立于 ROADMAP.md 里的计划 phase；
完成后更新 STATE.md 的 "Quick Tasks Completed" 表格——注意它不写 ROADMAP.md，因为 quick task 不属于计划 phase，phase 执行途中也可以使用。

前置条件有两个，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 task

list的展示格式（以下为文档示例，实际内容以你项目为准）：

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 存在且 frontmatterstatus=complete为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 则会被前置检查拦下。

get-shit-done 处理小改动时 /gsd-fast 与 /gsd-quick 的边界怎么划分