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-doneGoal: [What this phase delivers]Depends on: Phase 1Requirements: [REQ-04, REQ-05]Success Criteria(what must be TRUE):[Observable behavior from user perspective][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 AnalysisPhase N: Scope: Likely touches:Suggested dependencies: → Depends on: — reason: overlap/semantic/data-flow explanationCurrent 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考