Phase 2: [Name]

Phase 2: [Name]

【免费下载链接】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

Goal: [What this phase delivers]Depends on: Phase 1Requirements: [REQ-04, REQ-05]Success Criteria(what must be TRUE):

1. [Observable behavior from user perspective]
2. [Observable behavior from user perspective]Plans: [Number of plans]

Plans:

• 02-01: [Brief description]
• 02-02: [Brief description]

模板中 `Depends on: Phase 1` 这类写法正是本工作流要维护的核心字段。整数阶段（1、2、3）表示里程碑计划内的工作，小数阶段（2.1、2.2）表示紧急插入的工作（标记 `INSERTED`），依赖分析同样适用于两者。 ## 三、第 2 步：对没有显式文件清单的阶段推断文件修改域 大多数阶段在规划初期并没有 `files_modified` 显式清单。此时需要根据阶段的 scope/goal 描述推断其可能修改的文件，工作流给出了按领域划分的启发式规则： | 阶段类型 | 推断会修改的文件 | |---|---| | 数据库/Schema 阶段 | migration 文件、schema 定义、model 文件 | | API/后端阶段 | route 文件、controller 文件、service 文件、handler 文件 | | 前端/UI 阶段 | component 文件、page 文件、style 文件 | | 认证阶段 | middleware 文件、auth route 文件、session/token 文件 | | 配置/基础设施阶段 | config 文件、环境变量文件、CI/CD 文件 | | 测试阶段 | 测试文件、spec 文件、fixture 文件 | | 共享工具阶段 | lib/utils 文件、共享类型定义 | 完成推断后，将各阶段按推断出的文件域分组（database、API、frontend、auth、config、shared）。这一步的核心价值是建立**阶段 → 文件域**的映射，为下一步的文件重叠检测提供依据。分组越准确，后续检测出的依赖就越可信；因此当目标描述含糊时，宁可多读一些上下文（如阶段下的 Plans 列表）再下结论。 ## 四、第 3 步：三类依赖信号检测 对任意阶段对 (A, B)，工作流检查三类依赖信号： ### 1. 文件重叠检测（File Overlap Detection） 如果阶段 A 和 B 都会修改同一文件域或同一批具体文件，则两者必须串行执行——**提供基础（foundation）的阶段先跑**。这是最直接的冲突信号：例如两个阶段都触碰 `models/` 目录下的 schema 定义，那么先建 schema 的阶段必须先于消费 schema 的阶段。 ### 2. 语义依赖检测（Semantic Dependency Detection） 逐字阅读每个阶段的 scope/goal，查找以下语义模式： - 阶段 B 提到消费、使用或调用阶段 A 创建/实现的东西； - 阶段 B 引用了阶段 A 构建的 "API"、"schema"、"model"、"endpoint" 或 "interface"； - 阶段 B 明确写出 "after X is complete"、"once X is built"、"using the X from Phase N" 这类时间/引用措辞； - 阶段 B 扩展或修改阶段 A 已建立的代码。 这类信号不需要文件名相同，只要语义上存在"消费方—提供方"关系即可成立。 ### 3. 数据流检测（Data Flow Detection） 从数据流向的角度捕捉更隐蔽的依赖： - 阶段 A 创建数据结构/schema/类型 → 阶段 B 消费或转换它们； - 阶段 A 执行数据库 seed/migration → 阶段 B 从该数据库读取； - 阶段 A 暴露 API 契约 → 阶段 B 为该契约实现客户端。 数据流检测的本质是"谁产出数据、谁依赖数据"，即使两个阶段修改的文件完全不同，只要存在数据生产—消费链，就必须保证 A 先于 B。 ## 五、第 4 步：输出依赖建议表 对每一对阶段，工作流输出结构化的依赖分析表格：

Phase Dependency Analysis

Phase N: Scope: Likely touches:

Suggested dependencies: → Depends on: — reason: <overlap/semantic/data-flow explanation>

Current "Depends on": <existing value or "(none)">

对未检测出依赖的阶段对，明确输出："No dependency detected between Phase X and Phase Y."。这样既给出了建议，也保留了"独立阶段"的判断记录——**独立阶段恰恰是并行执行的最佳候选**，因此"无依赖"的结论和"有依赖"的结论同等重要。 ## 六、第 5 步：汇总建议的 ROADMAP 修改 将全部建议收敛为一份针对 `ROADMAP.md` `Depends on` 字段的差异清单：

Suggested ROADMAP.md updates: Phase 3: add "Depends on: 1, 2" (file overlap: database schema) Phase 5: add "Depends on: 3" (semantic: uses auth API from Phase 3) Phase 4: no change needed (independent scope)

这份汇总兼具两个用途：一是给用户一个全局视图，方便快速审阅；二是作为最终回写前的"干跑"（dry-run）结果，用户可以在真正改动文件之前先看到全部影响。 ## 七、第 6 步：确认并应用 工作流不会擅自修改路线图，而是向用户提问： > "Apply these `Depends on` suggestions to ROADMAP.md? (yes / no / edit)" 三种应答各有明确行为： - **yes** — 将所有建议的 `Depends on` 条目写入 `ROADMAP.md`，并逐一确认每次写入成功； - **no** — 仅以文本形式打印建议，由用户手动更新； - **edit** — 逐条呈现每个建议，用户对每条单独选择 yes / no / skip。 写入时有三个硬性约束（也是源码层面可验证的约定）： 1. 定位到对应阶段条目，新增或更新 `Depends on:` 字段； 2. 保留该阶段其余内容原样不动； 3. **不重排阶段顺序**。 应用完成后提示：`ROADMAP.md updated. Run `/gsd:manager` to execute phases in the correct order.`——即下一步交给 manager 按修正后的顺序执行。 ## 八、源码视角：`Depends on` 字段如何驱动并行调度 理解该工作流的最好方式，是看清它写入的字段在后端如何被解析和执行。GSD 中有三处与 `Depends on` 直接相关的实现，共同构成了"分析 → 写入 → 执行约束"的闭环。 ### 1. 依赖满足度计算（`deps_satisfied`） [`init-complex.ts`](https://link.gitcode.com/i/efd1e81c55b3075a65e73637a2047796) 中，manager 的初始化数据会为每个阶段计算依赖满足度： ```typescript const depNums = dependsOnStr.match(/\d+(?:\.\d+)*/g) || []; phase.deps_satisfied = depNums.every(n => completedNums.has(n)); phase.dep_phases = depNums; phase.deps_display = depNums.length > 0 ? depNums.join(',') : '—';

【免费下载链接】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