get-shit-done 的 Continue-Here 模板跨会话无缝续作的状态交接机制实战【免费下载链接】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导读在 Claude Code 驱动的 spec-driven 开发流程中一个 phase 往往横跨多个会话而每次会话的上下文窗口都会清空。get-shit-doneGSD通过.continue-here.md状态交接文件解决从哪里继续的问题它在暂停时把当前位置、已完成/未完成任务、关键决策、阻塞项与心理上下文固化为一套结构化模板在恢复时由 resume 流程消费让全新的 Claude 实例无需阅读任何历史记录即可精准续作。本文以仓库内 continue-here.md 模板为骨架结合 pause-work / resume-project 工作流与 SDK 查询层的源码实现完整讲解该模板的字段语义、编写规范、生成与消费链路让你能直接套用此格式编写高质量交接文件。模板定位GSD 工件分类学中的暂停态核心工件在 GSD 的工件分类学artifact-types.md中HANDOFF.json / .continue-here.md与 ROADMAP、STATE、PLAN、SUMMARY 并列为核心工件Core Artifacts形态Shape结构化暂停状态 —— JSON 机器可读 Markdown 人可读生命周期Lifecycle暂停时创建 → 恢复时消费 → 下次暂停时替换属于一次性one-shot工件位置Location.planning/HANDOFF.json与.planning/phases/XX-name/.continue-here.md或 spike / deliberation 路径消费方Consumed byresume-project工作流。其中.continue-here.md承担人可读部分它的读者是下一个会话的 LLM Agent因此模板设计的核心原则是具体到让一个全新的 Claude 实例立即理解。文件位置约定写入.planning/phases/XX-name/.continue-here.md模板开篇明确其目标位置.planning/phases/XX-name/.continue-here.md即该文件不是放在仓库根目录而是放在当前正在进行的 phase 目录内部。此约定由 pause-work.md 工作流的上下文检测步骤detect step确定目标路径Phase 工作存在活跃 phase 目录 → 写入.planning/phases/XX-name/.continue-here.mdSpike 工作存在活跃 spike 目录且无活跃 phase→ 写入.planning/spikes/SPIKE-NNN/.continue-here.mdSketch 工作写入.planning/sketches/.continue-here.mdDeliberation 工作写入.planning/deliberations/.continue-here.mdResearch 工作写入.planning/.continue-here.md默认兜底无任何可检测上下文 → 写入.planning/.continue-here.md并在current_state中注明歧义。检测命令通过ls -lt按修改时间排序取最近修改的 PLAN.md / SPIKE.md 等文件来确定上下文类型phase$(( ls -lt .planning/phases/*/PLAN.md 2/dev/null || true ) | head -1 | grep -oP phases/\K[^/] || true) spike$(( ls -lt .planning/spikes/*/SPIKE.md .planning/spikes/*/DESIGN.md .planning/spikes/*/README.md 2/dev/null || true ) | head -1 | grep -oP spikes/\K[^/] || true)YAML Frontmatter机器可读的定位元数据.continue-here.md顶部必须包含 YAML frontmatter用于让恢复流程快速判断我在哪个 phase、哪个任务、进行到哪一步--- phase: XX-name task: 3 total_tasks: 7 status: in_progress last_updated: 2025-01-15T14:30:00Z ---各字段语义来自模板的yaml_fields区块字段含义取值说明phase当前阶段名使用目录名例如02-authenticationtask当前任务编号整数例如3total_tasks本 phase 的任务总数整数例如7status状态in_progress、blocked、almost_done三选一last_updated更新时间戳ISO 8601 格式例如2025-01-15T14:30:00Zlast_updated在真实工作流中并非手写而是由 SDK 查询命令生成见 pause-work.mdtimestamp$(gsd-sdk query current-timestamp full --raw)实战要点frontmatter 是恢复流程的第一层判断依据 —— 恢复时先读task/total_tasks判断进度比例读status判断是否受阻。status: blocked时恢复流程会优先把blockers区块中的内容推送给用户。八大内容区块人可读续作上下文的完整结构模板的 Markdown 正文由 8 个 XML 风格标签区块组成每个区块解决续作上下文的一个具体维度。以下按模板顺序逐一解析其写作要求1.current_state—— 精确定位回答我们究竟在哪里、即时上下文是什么。写作要求是具体到路径级别例如位于 Phase 302-authentication的第 3 个任务正在实现 JWT 刷新令牌端点POST /auth/refresh而不是笼统写正在做认证模块。2.completed_work—— 本会话已完成记录本会话实际完成的工作要求具体、可验证建议按任务编号列出- Task 1: [name] - Done - Task 2: [name] - Done - Task 3: [name] - In progress, [whats done on it]注意模板允许一个任务处于进行中并记录其已完成部分这与前文的status: in_progress形成呼应。pause-work 工作流还会额外检查 SUMMARY 文件是否存在占位内容grep -l To be filled\|placeholder\|TBD防止把假完成当作真完成写入交接。3.remaining_work—— 本 phase 剩余任务列出本 phase 剩余的全部任务及各自状态让恢复会话一眼看到全景- Task 3: [name] - [whats left to do] - Task 4: [name] - Not started - Task 5: [name] - Not started4.decisions_made—— 决策与理由WHY 优先这是模板反复强调的核心不仅要写做了什么决策更要写为什么否则恢复会话可能重新争论已被否定的方案- Decided to use [X] because [reason] - Chose [approach] over [alternative] because [reason]模板的guidelines区块专门指出Include WHY decisions were made, not just what包含决策的 WHY而不只是 WHAT。这是防止跨会话重复辩论同一问题的结构化手段。5.blockers—— 阻塞项与规避方案记录任何卡住或等待外部因素的事项并附带状态或 workaround- [Blocker 1]: [status/workaround]pause-work 工作流在收集状态时会额外细分human_actions_pending需人工干预的事项MCP 配置、API Key、审批、手动测试与blockers技术 / 人工 / 外部类型恢复时这些内容会被立即展示给用户。6.context—— 心理状态与思维脉络模板将其定义为 Mental state, vibe, anything that helps resume smoothly心理状态、氛围、任何有助于平滑恢复的内容。写作建议你在想什么计划是什么——这是精确地从上次停下的地方继续所需的软上下文。它和 frontmatter 的last_updated配合让恢复会话能还原当时的思考角度。7.next_action—— 恢复后第一个动作必须具体到可立即执行、无需再读任何其他文件模板原话should be actionable without reading anything elseStart with: [specific action]例如 Start with: 打开src/auth/refresh.ts实现第 42 行 TODO 处的刷新令牌校验逻辑然后运行npm test中auth.test.ts的相关用例。这是恢复流程 routing 的依据 —— 恢复后直接执行该动作实现零摩擦续作。8. 额外区块真实工作流扩展pause-work 工作流在模板 8 区块之外还会写入四个强化上下文区块BLOCKING CONSTRAINTS本会话通过实际失败发现的反模式约束带severityblocking/advisoryblocking级别的约束要求恢复会话在继续前必须显式确认理解由 discuss-phase / execute-phase 工作流解析并强制检查Required Reading按顺序列出恢复会话必须先阅读的文档含.planning/METHODOLOGY.md使恢复会话继承项目的方法论分析视角见 artifact-types.md 对 METHODOLOGY.md 消费方的说明Infrastructure State运行中的服务、外部状态、环境特殊性Pre-Execution Critique Required仅在设计与执行之间暂停时填写例如 spike 设计已完成但尚未运行用于把关批判未完成不得开始执行。编写指南Guidelines速记模板末尾的guidelines是写作纪律的浓缩四条缺一不可具体到新实例立即理解Be specific enough that a fresh Claude instance understands immediately——避免依赖任何会话内的隐性记忆决策必须带 WHY——不只是做了什么还有为什么阻断跨会话的重复辩论next_action必须独立可执行——不读其他任何文件也能直接开工文件是一次性的This file gets DELETED after resume - its not permanent storage——它不是长期存储恢复完成后即被删除因此内容应聚焦当前交接而非沉淀历史。第 4 点非常重要.continue-here.md是 checkpoint 性质的短期工件长期决策与项目状态应沉淀到 STATE.md / PROJECT.md / SUMMARY.md 等正式工件中。消费链路resume 流程如何读取并处理该文件恢复优先级HANDOFF.json .continue-here.md 未完成 PLANresume-project.md 的check_incomplete_work步骤定义了三级恢复优先级.planning/HANDOFF.json首选机器可读由/gsd:pause-work生成的 JSON解析status、phase、plan、task、total_tasks、next_action检查blockers与human_actions_pending并立即展示用context_notes还原思维模型成功恢复后删除 HANDOFF.json一次性工件.continue-here.md中间检查点phase / 非 phase / 遗留回退路径均会被发现读取后标记 Found mid-plan checkpointPLAN 而无 SUMMARY未完成执行标记 Found incomplete plan execution。发现命令使用find而非ls通配符链 —— 工作流中的注释专门解释了原因在 macOS 默认的 zsh NOMATCH 选项下一个不匹配的 glob 会在词展开阶段使整个命令静默失败而find不做 shell glob 展开在 bash 与 zsh 下都能容忍缺失目录find .planning -maxdepth 3 -name .continue-here*.md -print 2/dev/null || true find . -maxdepth 1 -name .continue-here*.md -print 2/dev/null || true恢复路径决策determine_next_action步骤按状态路由存在.continue-here.md→Fallback: 从 checkpoint 恢复备选放弃 checkpoint 从当前 plan 重新开始存在 HANDOFF.json →Primary: 从结构化交接恢复优先级最高含具体任务/阻塞上下文存在中断的 subagent → Primary: 用 Task 工具 resume 参数恢复该 agent。门禁语义.continue-here.md的存在是安全门禁值得注意的反直觉行为.continue-here.md的存在不仅用于恢复还被 SDK 查询层用作执行门禁blocker gate。在 check-gates.ts 中// Gate 1: .continue-here.md in project root const continueHerePath join(projectDir, .continue-here.md); ... gate: continue-here, file: .continue-here.md, anti_patterns: [continue-here.md present — another session may be in progress],即当项目根目录或.planning/下存在.continue-here.md时check gates查询会返回 blocker提示另一个会话可能正在进行中——防止并行会话互相踩踏。route-next-action.ts同样在.planning/.continue-here.md存在时返回Blocked: .planning/.continue-here.md exists。对应测试见 check-gates.test.ts 与 route-next-action.test.ts。从源码结构可以推断这一门禁设计把.continue-here.md从单纯的恢复提示升级为互斥锁——它既告诉下一个会话从哪里继续也阻止其他会话在当前交接未消费时启动新工作是跨会话并发安全的关键机制。端到端实战一次完整的暂停—恢复循环结合上述全部机制一次标准循环如下暂停时/gsd:pause-work见 pause-work.md检测上下文类型并确定目标路径phase / spike / sketch / deliberation / research / default收集完整状态当前位置、已完成、剩余、决策、阻塞项、待人工动作、后台进程、未提交文件、阻塞约束写入.planning/HANDOFF.json机器可读version: 1.0含completed_tasks、remaining_tasks、blockers、human_actions_pending、decisions、uncommitted_files、next_action、context_notes按本模板写入.continue-here.md人可读含上述 8 区块 扩展区块以 WIP 提交gsd-sdk query commit wip: [context-name] paused at [X]/[Y] --files [handoff-path] .planning/HANDOFF.json向用户确认交接位置并提示/gsd:resume-work。恢复时/gsd:resume-work见 resume-work.md加载 STATE.md / PROJECT.md 还原项目全景检查 HANDOFF.json 与.continue-here.md用find全路径发现标记未完成工作展示项目状态面板phase / plan / 进度条 / 未完成工作告警按优先级路由到具体动作执行next_action中的第一步恢复完成后删除交接文件更新 STATE.md 的 Session Continuity 区块。写作质量自检清单撰写.continue-here.md时可对照以下清单验收Frontmatter 五项字段齐全status取值为in_progress/blocked/almost_done之一last_updated为 ISO 时间戳current_state具体到 phase / 任务 / 文件路径级别completed_work与remaining_work按任务编号列出无笼统描述decisions_made每条都包含 WHYblockers标注状态或 workaroundcontext记录了思维脉络与计划next_action不依赖任何其他文件即可执行无阻塞约束时删除了 BLOCKING CONSTRAINTS 区块模板要求 If no constraints have been identified yet, remove this section.。遵循上述结构与纪律.continue-here.md就能真正成为 GSD 跨会话开发的无缝续接器暂停时它完整保存思维状态恢复时它精确还原并充当并发安全门禁让换个新会话继续从模糊的回忆变成确定性的流程。【免费下载链接】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 的 Continue-Here 模板：跨会话无缝续作的状态交接机制实战
get-shit-done 的 Continue-Here 模板跨会话无缝续作的状态交接机制实战【免费下载链接】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导读在 Claude Code 驱动的 spec-driven 开发流程中一个 phase 往往横跨多个会话而每次会话的上下文窗口都会清空。get-shit-doneGSD通过.continue-here.md状态交接文件解决从哪里继续的问题它在暂停时把当前位置、已完成/未完成任务、关键决策、阻塞项与心理上下文固化为一套结构化模板在恢复时由 resume 流程消费让全新的 Claude 实例无需阅读任何历史记录即可精准续作。本文以仓库内 continue-here.md 模板为骨架结合 pause-work / resume-project 工作流与 SDK 查询层的源码实现完整讲解该模板的字段语义、编写规范、生成与消费链路让你能直接套用此格式编写高质量交接文件。模板定位GSD 工件分类学中的暂停态核心工件在 GSD 的工件分类学artifact-types.md中HANDOFF.json / .continue-here.md与 ROADMAP、STATE、PLAN、SUMMARY 并列为核心工件Core Artifacts形态Shape结构化暂停状态 —— JSON 机器可读 Markdown 人可读生命周期Lifecycle暂停时创建 → 恢复时消费 → 下次暂停时替换属于一次性one-shot工件位置Location.planning/HANDOFF.json与.planning/phases/XX-name/.continue-here.md或 spike / deliberation 路径消费方Consumed byresume-project工作流。其中.continue-here.md承担人可读部分它的读者是下一个会话的 LLM Agent因此模板设计的核心原则是具体到让一个全新的 Claude 实例立即理解。文件位置约定写入.planning/phases/XX-name/.continue-here.md模板开篇明确其目标位置.planning/phases/XX-name/.continue-here.md即该文件不是放在仓库根目录而是放在当前正在进行的 phase 目录内部。此约定由 pause-work.md 工作流的上下文检测步骤detect step确定目标路径Phase 工作存在活跃 phase 目录 → 写入.planning/phases/XX-name/.continue-here.mdSpike 工作存在活跃 spike 目录且无活跃 phase→ 写入.planning/spikes/SPIKE-NNN/.continue-here.mdSketch 工作写入.planning/sketches/.continue-here.mdDeliberation 工作写入.planning/deliberations/.continue-here.mdResearch 工作写入.planning/.continue-here.md默认兜底无任何可检测上下文 → 写入.planning/.continue-here.md并在current_state中注明歧义。检测命令通过ls -lt按修改时间排序取最近修改的 PLAN.md / SPIKE.md 等文件来确定上下文类型phase$(( ls -lt .planning/phases/*/PLAN.md 2/dev/null || true ) | head -1 | grep -oP phases/\K[^/] || true) spike$(( ls -lt .planning/spikes/*/SPIKE.md .planning/spikes/*/DESIGN.md .planning/spikes/*/README.md 2/dev/null || true ) | head -1 | grep -oP spikes/\K[^/] || true)YAML Frontmatter机器可读的定位元数据.continue-here.md顶部必须包含 YAML frontmatter用于让恢复流程快速判断我在哪个 phase、哪个任务、进行到哪一步--- phase: XX-name task: 3 total_tasks: 7 status: in_progress last_updated: 2025-01-15T14:30:00Z ---各字段语义来自模板的yaml_fields区块字段含义取值说明phase当前阶段名使用目录名例如02-authenticationtask当前任务编号整数例如3total_tasks本 phase 的任务总数整数例如7status状态in_progress、blocked、almost_done三选一last_updated更新时间戳ISO 8601 格式例如2025-01-15T14:30:00Zlast_updated在真实工作流中并非手写而是由 SDK 查询命令生成见 pause-work.mdtimestamp$(gsd-sdk query current-timestamp full --raw)实战要点frontmatter 是恢复流程的第一层判断依据 —— 恢复时先读task/total_tasks判断进度比例读status判断是否受阻。status: blocked时恢复流程会优先把blockers区块中的内容推送给用户。八大内容区块人可读续作上下文的完整结构模板的 Markdown 正文由 8 个 XML 风格标签区块组成每个区块解决续作上下文的一个具体维度。以下按模板顺序逐一解析其写作要求1.current_state—— 精确定位回答我们究竟在哪里、即时上下文是什么。写作要求是具体到路径级别例如位于 Phase 302-authentication的第 3 个任务正在实现 JWT 刷新令牌端点POST /auth/refresh而不是笼统写正在做认证模块。2.completed_work—— 本会话已完成记录本会话实际完成的工作要求具体、可验证建议按任务编号列出- Task 1: [name] - Done - Task 2: [name] - Done - Task 3: [name] - In progress, [whats done on it]注意模板允许一个任务处于进行中并记录其已完成部分这与前文的status: in_progress形成呼应。pause-work 工作流还会额外检查 SUMMARY 文件是否存在占位内容grep -l To be filled\|placeholder\|TBD防止把假完成当作真完成写入交接。3.remaining_work—— 本 phase 剩余任务列出本 phase 剩余的全部任务及各自状态让恢复会话一眼看到全景- Task 3: [name] - [whats left to do] - Task 4: [name] - Not started - Task 5: [name] - Not started4.decisions_made—— 决策与理由WHY 优先这是模板反复强调的核心不仅要写做了什么决策更要写为什么否则恢复会话可能重新争论已被否定的方案- Decided to use [X] because [reason] - Chose [approach] over [alternative] because [reason]模板的guidelines区块专门指出Include WHY decisions were made, not just what包含决策的 WHY而不只是 WHAT。这是防止跨会话重复辩论同一问题的结构化手段。5.blockers—— 阻塞项与规避方案记录任何卡住或等待外部因素的事项并附带状态或 workaround- [Blocker 1]: [status/workaround]pause-work 工作流在收集状态时会额外细分human_actions_pending需人工干预的事项MCP 配置、API Key、审批、手动测试与blockers技术 / 人工 / 外部类型恢复时这些内容会被立即展示给用户。6.context—— 心理状态与思维脉络模板将其定义为 Mental state, vibe, anything that helps resume smoothly心理状态、氛围、任何有助于平滑恢复的内容。写作建议你在想什么计划是什么——这是精确地从上次停下的地方继续所需的软上下文。它和 frontmatter 的last_updated配合让恢复会话能还原当时的思考角度。7.next_action—— 恢复后第一个动作必须具体到可立即执行、无需再读任何其他文件模板原话should be actionable without reading anything elseStart with: [specific action]例如 Start with: 打开src/auth/refresh.ts实现第 42 行 TODO 处的刷新令牌校验逻辑然后运行npm test中auth.test.ts的相关用例。这是恢复流程 routing 的依据 —— 恢复后直接执行该动作实现零摩擦续作。8. 额外区块真实工作流扩展pause-work 工作流在模板 8 区块之外还会写入四个强化上下文区块BLOCKING CONSTRAINTS本会话通过实际失败发现的反模式约束带severityblocking/advisoryblocking级别的约束要求恢复会话在继续前必须显式确认理解由 discuss-phase / execute-phase 工作流解析并强制检查Required Reading按顺序列出恢复会话必须先阅读的文档含.planning/METHODOLOGY.md使恢复会话继承项目的方法论分析视角见 artifact-types.md 对 METHODOLOGY.md 消费方的说明Infrastructure State运行中的服务、外部状态、环境特殊性Pre-Execution Critique Required仅在设计与执行之间暂停时填写例如 spike 设计已完成但尚未运行用于把关批判未完成不得开始执行。编写指南Guidelines速记模板末尾的guidelines是写作纪律的浓缩四条缺一不可具体到新实例立即理解Be specific enough that a fresh Claude instance understands immediately——避免依赖任何会话内的隐性记忆决策必须带 WHY——不只是做了什么还有为什么阻断跨会话的重复辩论next_action必须独立可执行——不读其他任何文件也能直接开工文件是一次性的This file gets DELETED after resume - its not permanent storage——它不是长期存储恢复完成后即被删除因此内容应聚焦当前交接而非沉淀历史。第 4 点非常重要.continue-here.md是 checkpoint 性质的短期工件长期决策与项目状态应沉淀到 STATE.md / PROJECT.md / SUMMARY.md 等正式工件中。消费链路resume 流程如何读取并处理该文件恢复优先级HANDOFF.json .continue-here.md 未完成 PLANresume-project.md 的check_incomplete_work步骤定义了三级恢复优先级.planning/HANDOFF.json首选机器可读由/gsd:pause-work生成的 JSON解析status、phase、plan、task、total_tasks、next_action检查blockers与human_actions_pending并立即展示用context_notes还原思维模型成功恢复后删除 HANDOFF.json一次性工件.continue-here.md中间检查点phase / 非 phase / 遗留回退路径均会被发现读取后标记 Found mid-plan checkpointPLAN 而无 SUMMARY未完成执行标记 Found incomplete plan execution。发现命令使用find而非ls通配符链 —— 工作流中的注释专门解释了原因在 macOS 默认的 zsh NOMATCH 选项下一个不匹配的 glob 会在词展开阶段使整个命令静默失败而find不做 shell glob 展开在 bash 与 zsh 下都能容忍缺失目录find .planning -maxdepth 3 -name .continue-here*.md -print 2/dev/null || true find . -maxdepth 1 -name .continue-here*.md -print 2/dev/null || true恢复路径决策determine_next_action步骤按状态路由存在.continue-here.md→Fallback: 从 checkpoint 恢复备选放弃 checkpoint 从当前 plan 重新开始存在 HANDOFF.json →Primary: 从结构化交接恢复优先级最高含具体任务/阻塞上下文存在中断的 subagent → Primary: 用 Task 工具 resume 参数恢复该 agent。门禁语义.continue-here.md的存在是安全门禁值得注意的反直觉行为.continue-here.md的存在不仅用于恢复还被 SDK 查询层用作执行门禁blocker gate。在 check-gates.ts 中// Gate 1: .continue-here.md in project root const continueHerePath join(projectDir, .continue-here.md); ... gate: continue-here, file: .continue-here.md, anti_patterns: [continue-here.md present — another session may be in progress],即当项目根目录或.planning/下存在.continue-here.md时check gates查询会返回 blocker提示另一个会话可能正在进行中——防止并行会话互相踩踏。route-next-action.ts同样在.planning/.continue-here.md存在时返回Blocked: .planning/.continue-here.md exists。对应测试见 check-gates.test.ts 与 route-next-action.test.ts。从源码结构可以推断这一门禁设计把.continue-here.md从单纯的恢复提示升级为互斥锁——它既告诉下一个会话从哪里继续也阻止其他会话在当前交接未消费时启动新工作是跨会话并发安全的关键机制。端到端实战一次完整的暂停—恢复循环结合上述全部机制一次标准循环如下暂停时/gsd:pause-work见 pause-work.md检测上下文类型并确定目标路径phase / spike / sketch / deliberation / research / default收集完整状态当前位置、已完成、剩余、决策、阻塞项、待人工动作、后台进程、未提交文件、阻塞约束写入.planning/HANDOFF.json机器可读version: 1.0含completed_tasks、remaining_tasks、blockers、human_actions_pending、decisions、uncommitted_files、next_action、context_notes按本模板写入.continue-here.md人可读含上述 8 区块 扩展区块以 WIP 提交gsd-sdk query commit wip: [context-name] paused at [X]/[Y] --files [handoff-path] .planning/HANDOFF.json向用户确认交接位置并提示/gsd:resume-work。恢复时/gsd:resume-work见 resume-work.md加载 STATE.md / PROJECT.md 还原项目全景检查 HANDOFF.json 与.continue-here.md用find全路径发现标记未完成工作展示项目状态面板phase / plan / 进度条 / 未完成工作告警按优先级路由到具体动作执行next_action中的第一步恢复完成后删除交接文件更新 STATE.md 的 Session Continuity 区块。写作质量自检清单撰写.continue-here.md时可对照以下清单验收Frontmatter 五项字段齐全status取值为in_progress/blocked/almost_done之一last_updated为 ISO 时间戳current_state具体到 phase / 任务 / 文件路径级别completed_work与remaining_work按任务编号列出无笼统描述decisions_made每条都包含 WHYblockers标注状态或 workaroundcontext记录了思维脉络与计划next_action不依赖任何其他文件即可执行无阻塞约束时删除了 BLOCKING CONSTRAINTS 区块模板要求 If no constraints have been identified yet, remove this section.。遵循上述结构与纪律.continue-here.md就能真正成为 GSD 跨会话开发的无缝续接器暂停时它完整保存思维状态恢复时它精确还原并充当并发安全门禁让换个新会话继续从模糊的回忆变成确定性的流程。【免费下载链接】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），仅供参考