get-shit-done/gsd mvp-phase完全指南从用户故事、SPIDR 拆分到垂直切片规划全流程解析【免费下载链接】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导读/gsd mvp-phase是 TÂCHES 出品的 spec-driven 开发系统 get-shit-doneGSD中把既有阶段转换为MVP垂直切片模式的交互式命令入口。本文以仓库内get-shit-done/workflows/mvp-phase.md工作流为骨架完整拆解其九步执行链——阶段参数解析与状态守卫、三段式用户故事采集与集中式校验、SPIDR 五轴拆分检查、ROADMAP.md 目标改写与**Mode:** mvp注入、写入校验、以及最终委托给/gsd plan-phase的自动衔接。读完你将掌握如何用一条命令让某个阶段以用户故事为纲、按功能切片而非技术分层进行规划如何识别过大的用户故事并借助 SPIDR 拆成多个阶段以及 GSD 的 MVP_MODE 解析链CLI 标志 → ROADMAP 模式字段 → 配置 → 默认关闭在底层是如何被gsd-sdk的查询动词统一实现的。一、命令定位mvp-phase 在 GSD 体系中的角色在 get-shit-done 的整体流程中阶段phase是 ROADMAP.md 中的规划单元。默认的plan-phase会按水平分层先 schema、再 API、后 UI组织任务而 MVP 模式要求按垂直功能切片组织任务——每个任务都必须让真实用户能多完成一步完整操作。/gsd mvp-phase正是把某个阶段从普通阶段改造成MVP 阶段的用户入口。命令的官方定义见 commands/gsd/mvp-phase.md名称gsd:mvp-phase参数提示phase-number允许的工具Read、Write、Bash、Glob、Grep、Agent、AskUserQuestion依赖的命令new-project、phase、plan-phase一句话目标以用户故事规划一个阶段——先做As a / I want to / So that三问再跑 SPIDR 拆分检查若故事过大则按 Spike/Paths/Interfaces/Data/Rules 五轴拆成多个阶段然后把**Mode:** mvp与新格式的**Goal:**写入该阶段在 ROADMAP.md 中的区块最后委托/gsd plan-phase N完成规划。两个关键定位说明它不创建阶段只转换阶段。目标阶段必须已存在于 ROADMAP.md 中由/gsd new-project、/gsd add-phase或/gsd insert-phase创建。它负责的是改模式新阶段的创建SPIDR 拆分后的剩余切片会被延后并作为/gsd add-phase建议呈现给用户以保留用户对阶段编号的控制权。它是 MVP 功能族的第一阶段入口。按命令文档的说法Phase 1 of the vertical-mvp-slice PRD shipped the planner-side machinery; this command is the user entry point for it.——规划侧机制planner 的 MVP 模式已由 PRD 第一阶段交付本命令负责把用户带到那条规划路径上。概念索引 get-shit-done/references/mvp-concepts.md 将本工作流的职责精确定位为Per-phase mode authoring按阶段写入模式——在采集用户故事后向 ROADMAP.md 写入**Mode:** mvp。同一索引还指出项目级模式决策由gsd-roadmapper在项目初始化时基于PROJECT_MODE一次性做出而按阶段的开启/关闭则在之后通过/gsd:mvp-phase或/gsd-edit-phase完成——这正是本工作流所处的位置。二、前置概念用户故事模板、SPIDR 与 MVP 解析链在进入九步流程之前先建立三个工作流反复引用的核心概念。它们分别由三份参考文档定义是 mvp-phase 的灵魂。2.1 用户故事规范格式User Story Templateget-shit-done/references/user-story-template.md 定义了 MVP 模式下用户故事的唯一规范格式As a [user role], I want to [capability], so that [outcome].三个槽位各有明确的问题与示例槽位引导问题示例[user role]Who is the actor?new user、admin、signed-in customer、API consumer[capability]What can they do?register and log in、upload a CSV、see my dashboard[outcome]Why does it matter?I can access my account、I can bulk-import contacts、I can see at a glance what needs attention三条结构性规则写入 ROADMAP.md 时必须遵守**Goal:**必须保持单行故事内部不允许换行故事超过约 120 字符时应通过 SPIDR 拆分为多个阶段**Mode:** mvp紧跟**Goal:**之后插入若已存在**Mode:**则替换而非重复。该故事最终会落到两处ROADMAP.md 的**Goal:**行使用散文形式关键词不加粗以及 PLAN.md 中## Phase Goal之下的首段内容此时使用加粗关键词形式**As a** new user, **I want to** register and log in, **so that** I can access my dashboard.——加粗格式仅用于 PLAN.md 输出。2.2 SPIDR 故事拆分规则get-shit-done/references/spidr-splitting.md 定义了一套完整交互式流程按 PRD 决策 Q3SPIDR 不是轻量检查而是全交互流程其思想源自 Mike Cohn 的用户故事拆分方法。四个触发信号任一命中即触发复合能力Compound capabilities故事用 and 连接了两个及以上独立用户动作如 registerandlog inandreset their password每个 and 都是候选拆分点多参与者Multi-actor故事出现多个[user role]如 As a user or admin...长度Length单行组装后超过约 120 字符能力含糊Vague capability能力部分是名词短语而非动词-名词对如 I want to use the dashboard——未指明对 dashboard 的哪种交互。若四者皆未命中完全跳过 SPIDR直接进入 ROADMAP 写入。五个拆分轴每轴一个问题一次只应用一个轴轴定向问题拆分逻辑SpikeIs there an unknown that needs research before this can be implemented?拆出研究阶段无验收标准只有足够了解以规划其余部分剩余故事成为后续阶段PathsDoes this feature have a happy path and one or more error/edge paths?幸福路径进第一阶段边缘路径进后续阶段先幸福路径证明切片可用再渐进边缘InterfacesDoes this feature need to work on more than one interface (web, mobile, API, CLI)?按接口拆分面向用户的 Web 优先集成驱动的 API 优先Mobile 除非是主平台否则殿后DataDoes this feature touch multiple data scopes (one user vs. many, single team vs. multi-tenant, small CSV vs. large dataset)?按数据范围拆分最小范围优先单用户、单团队、小数据再逐步扩大RulesDoes this feature have multiple business rules that could be added incrementally?按规则复杂度拆分最小可行规则先行复杂策略后置必须拒绝的反模式按技术层拆分Phase 1: schema. Phase 2: API. Phase 3: UI.——这是水平规划在用户看到原始故事之前预拆分永远先展示用户提供的故事只有命中尺寸信号才提议拆分一次拆多个轴SPIDR 一次一个轴若故事需要沿两轴拆先拆路径再重新评估拆分后的小故事。2.3 MVP_MODE 解析链单一真相plan-phase工作流通过集中式查询动词phase.mvp-mode解析 MVP 模式优先级先命中者胜CLI 标志--mvp→ ROADMAP.md 的 **Mode:** mvp → workflow.mvp_mode 配置 → false其底层实现位于 sdk/src/query/mvp.ts 的phaseMvpMode处理器详情见后文源码级佐证一节。这条链正是 mvp-phase 在第 7 步委托 plan-phase 后plan-phase 能自动检测到**Mode:** mvp的机制基础。三、九步工作流逐段拆解以下严格遵循 get-shit-done/workflows/mvp-phase.md 的流程结构逐段给出规则、代码与交互细节。第 1 步解析并校验阶段参数从$ARGUMENTS中提取阶段编号支持整数或小数如2.1可选标志--force允许对in_progress/completed状态阶段操作。若没有参数打印错误并退出ERROR: Phase number required Usage: /gsd mvp-phase phase-number Example: /gsd mvp-phase 1 Example: /gsd mvp-phase 2.1随后按 get-shit-done/references/phase-argument-parsing.md 的规则归一化阶段号整数阶段零填充为两位保留小数后缀8 → 082.1 → 02.1。该参考文档同时给出两种实现方式推荐用gsd-sdk query find-phase ${PHASE}一步完成归一化与校验返回found、directory、phase_number、phase_name、plans、summaries等字段或沿用传统的 bash 正则归一化逻辑if [[ $PHASE ~ ^[0-9]$ ]]; then # Integer: 8 → 08 PHASE$(printf %02d $PHASE) elif [[ $PHASE ~ ^([0-9])\.([0-9])$ ]]; then # Decimal: 2.1 → 02.1 PHASE$(printf %02d.%s ${BASH_REMATCH[1]} ${BASH_REMATCH[2]}) fi第 2 步验证阶段存在并检查状态工作流通过gsd-sdk query roadmap.get-phase读取阶段信息并用roadmap.analyze获取磁盘上的实际状态二者结合推导STATUSPHASE_INFO$(gsd-sdk query roadmap.get-phase ${PHASE}) PHASE_FOUND$(echo $PHASE_INFO | jq -r .found) PHASE_NAME$(echo $PHASE_INFO | jq -r .phase_name) PHASE_GOAL$(echo $PHASE_INFO | jq -r .goal) PHASE_MODE$(echo $PHASE_INFO | jq -r .mode // ) PHASE_COMPLETE$(echo $PHASE_INFO | jq -r .roadmap_complete // false) ANALYZE$(gsd-sdk query roadmap.analyze) if [[ $ANALYZE file:* ]]; then ANALYZE$(cat ${ANALYZE#file:}); fi DISK_STATUS$(echo $ANALYZE | jq -r --arg p $PHASE .phases[] | select((.phase_number|tostring)$p) | .disk_status | head -1) if [[ $DISK_STATUS complete || $PHASE_COMPLETE true ]]; then STATUScompleted elif [[ $DISK_STATUS planned || $DISK_STATUS partial ]]; then STATUSin_progress else STATUSnot_started fi若PHASE_FOUND为false报错并退出同时建议先用/gsd add-phase或/gsd insert-phase创建该阶段本命令不创建阶段。状态守卫Status guard若阶段处于in_progress已有计划但未完成或completed除非$ARGUMENTS中含--force否则拒绝操作ERROR: Phase ${PHASE} is currently ${STATUS}. Converting an active or completed phase to MVP mode mid-flight will invalidate any existing plans and summaries. To proceed anyway: /gsd mvp-phase ${PHASE} --force已处 MVP 模式的守卫Already-MVP guard若PHASE_MODE已是mvp则提示用户并询问是否重新采集用户故事Phase ${PHASE} is already in MVP mode with goal: «${PHASE_GOAL}». Re-run user-story prompts and SPIDR check?通过AskUserQuestion提供 [Re-prompt / Abort] 两个选项Abort 则干净退出Re-prompt 则继续。运行时兼容提示工作流头部标注了运行时说明runtime_note——在 VS Code 的 Copilot 中凡工作流调用AskUserQuestion处一律改用vscode_askquestions二者等价若设置了TEXT_MODEtrue$ARGUMENTS含--text或 init JSON 中text_mode为 true则每个AskUserQuestion都退化为纯文本编号列表 用户输入编号的交互方式这是 Claude Code 远程会话/rc模式下 TUI 菜单不可用时的必要回退。第 3 步用户故事三连问与集中式校验依次发起三个自由文本的AskUserQuestion调用Prompt 1 — As a:As a [user role]?示例new user、admin、signed-in customer、API consumerPrompt 2 — I want to:I want to [capability]?示例register and log in、upload a CSV、see my dashboardPrompt 3 — So that:So that [outcome]?示例I can access my account、I can bulk-import contacts、I can see at a glance what needs attention三答齐全后按规范句组装USER_STORYAs a ${ROLE}, I want to ${CAPABILITY}, so that ${OUTCOME}.任何一答为空或纯空白即报错并仅重问该字段绝不允许以残缺故事继续。随后通过集中式 User Story 校验器做格式验证。校验器持有规范正则/^As a ., I want to ., so that .\.$/并能给出逐项错误指引USER_STORY_RESULT$(gsd-sdk query user-story.validate --story $USER_STORY) if [ $(echo $USER_STORY_RESULT | jq -r .valid) ! true ]; then echo $USER_STORY_RESULT | jq -r .errors[] 2 # Re-prompt the offending field(s) per surfaced errors, then re-run validation. # Do not abort the workflow on first invalid draft. RE_PROMPT_USER_STORYtrue fi这条校验的意义在于它保证最终写入 ROADMAP.md 的目标与验证器gsd-verifier稍后施加的同一条守卫一致——同一正则被verify-work.md中的阶段目标守卫消费两边共用一套规则杜绝写进去的格式验证器不认的漂移。若RE_PROMPT_USER_STORYtrue只重跑出错字段对应的提示、重建USER_STORY再校验一次后方可继续。第 4 步SPIDR 拆分检查按 get-shit-done/references/spidr-splitting.md 执行触发评估对照四个尺寸信号复合能力、多参与者、长度 120 字符、能力含糊检查组装好的USER_STORY。四者全未命中 → 完全跳过 SPIDR直接进入第 5 步。若 SPIDR 触发依次执行a)向用户复述故事并解释触发原因Your story: «${USER_STORY}»This story has [signal description, e.g., two compound capabilities joined by and]. Splitting it into multiple phases will produce a cleaner Walking Skeleton and reduce the risk of mid-phase scope creep.Want to walk through SPIDR splitting?AskUserQuestion提供 [Yes, walk through SPIDR / No, proceed with the story as-is]选 No 则跳过 SPIDR 进入第 5 步。b)询问最合适的拆分轴Which axis best fits how to split this story?AskUserQuestion提供五个选项Spike / Paths / Interfaces / Data / Rules每个选项以其定向问题作为描述文字让用户看问题选轴。c)沿所选轴只问一个定向问题而非五问全问。例如选中 Paths 时Does this feature have a happy path and one or more error/edge paths?自由文本回答工作流解析出拆分。d)产出拆分提案Proposed split (Paths axis):Phase ${PHASE} (this one):Happy path — ${HAPPY_STORY}Phase ${PHASE1} (new):Edge case — ${EDGE_STORY}Accept this split?AskUserQuestion提供 [Accept / Modify / Reject]AcceptUSER_STORY变为首个拆分的故事示例中的${HAPPY_STORY}其余拆分以一组/gsd add-phase调用列表的形式呈现给用户、供命令结束后手动执行——绝不自动创建新阶段保留用户对编号的控制Modify再重问一次拆分然后接受或拒绝RejectUSER_STORY还原为原始故事不拆分继续。第 5 步更新 ROADMAP.md读取ROADMAP.md定位Phase ${PHASE}区块执行两处编辑编辑 1 — 更新 Goal 行**Goal:** ${OLD_GOAL_TEXT}→**Goal:** ${USER_STORY}编辑 2 — 插入 Mode 行若区块中已存在**Mode:**重跑或替换场景则更新为**Mode:** mvp若不存在则在**Goal:**之后紧接一行插入**Mode:** mvp。用户故事落盘后的效果对照 user-story-template.md 中的示例### Phase 1: User Auth MVP **Goal:** As a new user, I want to register and log in, so that I can access my dashboard. **Mode:** mvp向用户展示 unified diff将被修改的行并询问Apply these changes to ROADMAP.md?AskUserQuestion提供 [Apply / Cancel]Cancel 则不做任何写入直接退出Apply 则以原子方式read-edit-write写回更新后的ROADMAP.md。第 6 步验证写入写入后立即用--pick只取两个字段回读校验NEW_MODE$(gsd-sdk query roadmap.get-phase ${PHASE} --pick mode) NEW_GOAL$(gsd-sdk query roadmap.get-phase ${PHASE} --pick goal)两条断言缺一不可NEW_MODE必须等于mvpNEW_GOAL必须等于组装好的用户故事任一断言失败都要把差异呈现给用户并退出——绝不在半写状态下继续委托 plan-phase。第 7 步委托给 /gsd plan-phase以无标志方式调用/gsd plan-phase ${PHASE}。此时 plan-phase 内的 MVP_MODE 解析链CLI 标志 → ROADMAP 模式 → 配置 → false会命中新写入的**Mode:** mvp行自动以垂直切片模式执行规划。plan-phase的--mvp标志说明见 commands/gsd/plan-phase.md与工作流中的解析代码见 get-shit-done/workflows/plan-phase.md共同印证了这条链MVP_MODE$(gsd-sdk query phase.mvp-mode ${PHASE} $MVP_FLAG_ARG --pick active)Walking Skeleton 门同样来自 plan-phase 第 2 步会在MVP_MODEtrue且${PHASE} 01且此前没有任何阶段摘要全新项目时自动触发WALKING_SKELETONfalse if [ $MVP_MODE true ] [ $padded_phase 01 ]; then PRIOR_SUMMARIES$(gsd-sdk query phases.list --pick summaries_total 2/dev/null || echo 0) if [ $PRIOR_SUMMARIES 0 ]; then WALKING_SKELETONtrue; fi fiWalking Skeleton 模式下planner 必须额外产出SKELETON.md模板见 get-shit-done/references/planner-mvp-mode.md其中记录了框架、数据库、部署目标、认证方案、目录布局等后续阶段依赖的架构决策被视为契约而非草稿。第 8 步呈现延迟拆分的阶段如有若第 4 步产生了拆分追加一段面向用户的收尾消息SPIDR split deferred phases.Your original story was split. The first slice is now planned via plan-phase. To create the remaining slice(s) as new phases, run:/gsd add-phase— for the next slice: «${SPLIT_2_STORY}»/gsd add-phase— for the next slice: «${SPLIT_3_STORY}»Each will be added to the end of the current milestone. You can then run/gsd mvp-phase new-phase-numberon each to plan them as MVP slices.注意这里只呈现后续命令绝不代为执行。第 9 步退出工作流结束。该阶段已处于 MVP 模式产出规划好的 PLAN.md并视情况向用户呈现延后的后续阶段。四、源码级佐证SDK 查询层如何支撑这三条契约工作流中反复调用的gsd-sdk query动词并非黑盒。MVP 功能族的三个集中式接缝集中式接缝指取代多个工作流中重复内联实现的单一权威实现统一定义在 sdk/src/query/mvp.ts 中其模块头注释明确交代了设计动机这三个动词取代了此前散落在plan-phase.md、execute-phase.md、verify-work.md、progress.md中的近重复 bash 逻辑工作流只需调用动词并读取布尔值。4.1phase.mvp-mode优先级链解析器实现sdk/src/query/mvp.ts严格按文档所述优先级执行--cli-flag参数存在 →activetrue, sourcecli_flag由调用方断言用户传了--mvp否则读 ROADMAP 模式roadmapGetPhase返回的mode字段被trim().toLowerCase()归一化后与mvp比较 → 命中则sourceroadmap否则读配置config.workflow.mvp_mode的布尔值 → 命中则sourceconfig兜底sourcenoneactivefalse。返回结果同时暴露source、roadmap_mode、config_mvp_mode、cli_flag_present供诊断使用例如gsd-sdk query phase.mvp-mode 1 # roadmap config check gsd-sdk query phase.mvp-mode 1 --cli-flag # caller saw --mvp on CLI4.2user-story.validate规范正则与逐槽位错误指引实现sdk/src/query/mvp.ts导出可被单测直接断言的规范正则export const USER_STORY_REGEX /^As a (?role.?), I want to (?capability.?), so that (?outcome.?)\.$/;校验失败时逐条给出针对性错误Must begin with As a .、Must contain , I want to .、Must contain , so that .、Must end with a period.全部不命中才回退到Does not match canonical User Story shape.。校验通过时返回三个槽位的解析结果slots: { role, capability, outcome }。这正对应工作流第 3 步按错误指引重问出错的字段的实现基础。4.3task.is-behavior-addingMVPTDD 门的三重谓词旁证虽不在 mvp-phase 工作流内部但它与user-story.validate同属一个查询文件构成 MVP 功能族的闭环它判定某个 PLAN.md 任务是否增加用户可见行为——要求tddtruefrontmatter、非空的behavior块、以及files中含至少一个非测试源码文件排除*.md、*.json、*.test.*、*.spec.*与各类配置文件。它在执行侧gsd-executor 的 MVPTDD Gate消费而 mvp-phase 负责在规划侧铺好故事与模式。4.4 ROADMAP 解析器中的 mode 字段roadmap.get-phase之所以能返回mode是因为 SDK 的 ROADMAP 解析器在提取阶段区块时同时解析了**Mode:**字段见 sdk/src/query/roadmap.ts 与 sdk/src/query/roadmap.tsconst modeMatch section.match(/\*\*Mode(?::\*\*|\*\*:)\s*([^\n])/i); const mode modeMatch ? modeMatch[1].trim().toLowerCase() : null;mode字段的类型定义也明确标注Phase-level mode flag from**Mode:** mvpin ROADMAP.md. Read by thephase.mvp-moderesolver and downstream MVP-aware workflows.——即 mvp-phase 第 6 步的写入校验--pick mode与 plan-phase 的解析链读的是同一个来源。4.5 测试证据对应测试 sdk/src/query/mvp.test.ts 覆盖了这些契约可作为可复现的验证依据mode 字段回归测试验证roadmap.get-phase能从阶段区块提取**Mode:** mvpexpect(data.mode).toBe(mvp)、缺失时返回null、未知模式按小写保留spike以向前兼容phase.mvp-mode优先级测试CLI 标志胜过 roadmap 与 configroadmap**Mode:** mvp在无 CLI 标志时激活roadmap 模式在比较前归一化MVP带空白仍激活user-story.validate与正则直接断言USER_STORY_REGEX的匹配行为。仓库级集成测试还包括 tests/mvp-phase-command.test.cjs、tests/mvp-phase-integration.test.cjs、tests/mvp-phase-spidr.test.cjs 以及 tests/plan-phase-mvp-flag.test.cjsplan-phase 的 MVP_MODE 解析链——mvp-concepts.md的 Tests 一节提供了完整的测试映射。五、与上下游的衔接一次 mvp-phase 调用发生了什么把九步流程放进 GSD 更大的规划管线中一次完整的/gsd mvp-phase 1调用实际是ROADMAP.md 中已存在 Phase 1由 new-project / add-phase / insert-phase 创建 │ ▼ /gsd mvp-phase 1 ├─ 1. 解析并归一化阶段号1 → 01 ├─ 2. 状态守卫拒绝 in_progress / completed除非 --force拒绝重复 MVP 转换除非 Re-prompt ├─ 3. 采集三段式用户故事 → user-story.validate 集中校验同一正则稍后会被 verifier 复用 ├─ 4. SPIDR 检查四个尺寸信号 → 五轴交互拆分 → 提案 Accept/Modify/Reject ├─ 5. 原子改写 ROADMAP.md**Goal:** 用户故事**Mode:** mvp 紧随其后 ├─ 6. --pick mode / goal 回读断言 ├─ 7. 委托 /gsd plan-phase 01无标志 │ └─ phase.mvp-mode 解析链命中 roadmap 来源 → 垂直切片模式 │ └─ 若为全新项目的 Phase 01 → Walking Skeleton 门触发 → 额外产出 SKELETON.md ├─ 8. 呈现 SPIDR 延后的 /gsd add-phase 建议不自动执行 └─ 9. 退出阶段进入 MVP 模式PLAN.md 已规划两条关键设计原则贯穿始终用户控制权优先阶段状态守卫、ROADMAP diff 确认Apply/Cancel、SPIDR 拆分确认Accept/Modify/Reject、新阶段创建延后只呈现/gsd add-phase建议不代跑——每个可能产生副作用的环节都以AskUserQuestion把决定权交还用户单一真相、零漂移用户故事正则、MVP 模式解析、行为任务谓词全部收敛到sdk/src/query/mvp.ts的集中式动词工作流只调用动词读结果verify-work.md的 verifier 与mvp-phase的交互校验共用同一正则杜绝两处实现不一致。六、实践要点与常见问题速查什么时候用--force仅当你确实想中途把已开始或已完成的阶段改造成 MVP 模式、并愿意接受既有 PLAN.md 与 SUMMARY 失效时。普通场景应先规划好阶段顺序再对未开始的阶段执行 mvp-phase。故事太大怎么办交给 SPIDR先看四个触发信号是否命中命中后让用户选轴Spike/Paths/Interfaces/Data/Rules一次只沿一轴问一个问题。切勿按技术层schema/API/UI拆分那正是 SPIDR 明令拒绝的反模式。拆出来的新阶段什么时候创建在 mvp-phase 结束后手动执行工作流提示的/gsd add-phase再对新阶段号逐个跑/gsd mvp-phase new-phase-number以保留对编号的完全控制。如何验证模式真的生效直接查询gsd-sdk query roadmap.get-phase 1 --pick mode # 期望输出 mvp gsd-sdk query phase.mvp-mode 1 --pick active # 期望输出 true gsd-sdk query phase.mvp-mode 1 --pick source # 期望输出 roadmap相关文档导航命令定义 commands/gsd/mvp-phase.md规划侧规则 get-shit-done/references/planner-mvp-mode.md概念索引与文件地图 get-shit-done/references/mvp-concepts.mdplan-phase 完整工作流 get-shit-done/workflows/plan-phase.md查询层实现与测试 sdk/src/query/mvp.ts、sdk/src/query/mvp.test.ts。【免费下载链接】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），仅供参考