dev-session

开发会话

通过结构化进度文件、检查点提交和持久化经验，管理多会话开发工作。生成 SESSION.md 文件，使其在上下文压缩后仍能保留，并支持在不同会话间顺利交接。

操作模式

模式 1：开始会话

适用时机：开始多步骤工作时，用户说“开始会话”或“为 [功能] 开始新会话”时

1. 检查项目根目录中是否已有 SESSION.md
   • 如果有：读取它，并询问是要继续现有会话还是重新开始
   • 如果没有：根据模板创建（参见 references/session-template.md）
2. 预填字段：
   • 项目：从 CLAUDE.md 或目录名称获取
   • 分支：通过 git branch --show-current 获取
   • 最后更新：当前时间戳
   • 阶段：询问用户正在处理什么
3. 阅读项目的 CLAUDE.md，了解上下文
4. 提供简要摘要：“会话已开始。正在分支 [branch] 上处理 [phase]。”

模式 2：检查点

适用时机：用户说“检查点”、达到重要里程碑、进行高风险更改前、上下文变得庞大时

1. 更新 SESSION.md：
   • 将已完成事项添加到已完成内容
   • 使用精确位置（文件路径、行号）更新当前位置
   • 清除已解决的阻碍项，添加新阻碍项
   • 编写具体的恢复说明
2. 记录经验：
   • 如果在工作过程中发现了模式、注意事项或命令，将其添加到 CLAUDE.md
   • 每个概念一行——简洁，不冗长
3. Git 检查点：

   git add -A && git commit -m "WIP: [what was accomplished]"
   

4. 在 SESSION.md 的检查点下记录提交哈希
5. 确认：“已在 [hash] 创建检查点。SESSION.md 已更新。”

模式 3：恢复会话

适用时机：用户说“恢复”“从上次会话继续”“我们做到哪了”，或开始新的对话时

1. 阅读 SESSION.md——如果文件不存在，告知用户并提出开始新会话
2. 阅读项目的 CLAUDE.md，了解上下文
3. 检查自记录的检查点以来发生了哪些变化：

   git log --oneline [checkpoint-hash]..HEAD
   

4. 检查是否有未提交的更改：git status
5. 提供摘要：
   • 阶段：正在处理的内容
   • 位置：上次停下的位置
   • 此后更改：检查点之后的任何提交或修改
   • 阻碍项：尚未解决的问题
   • 建议的下一步：恢复说明中的第一项

模式 4：结束会话

适用时机：用户说“结束会话”“暂时到此为止”“保存进度”，或即将结束会话时

1. 执行完整的检查点（模式 2）
2. 检查 SESSION.md 是否完整：
   • 恢复说明是否足够具体，让新会话能够继续？
   • 当前位置是否具体（文件路径，而非含糊的描述）？
3. 如果阶段已完成：
   • 将阶段摘要精简为 2-3 行
   • 清除恢复说明，或注明“阶段已完成——可以开始下一阶段”
4. 确认：“会话已结束。下次请用 ‘resume session’ 恢复。”

适用场景

场景	使用此技能？
跨越 2 个或更多会话的多阶段功能	是
可能触发上下文压缩的工作	是
进行高风险或破坏性更改前	是（先创建检查点）
快速修复 Bug 或编辑单个文件	否
范围明确的单会话任务	否

SESSION.md 原则

• 跟踪进度，而非架构——SESSION.md 是工作日志，不是项目文档
• 具体胜过含糊——“在 src/auth.ts:42 继续，实现令牌刷新”胜过“继续处理身份验证”
• 精简已完成的工作——已完成阶段总结为 1-2 行
• 控制在 100 行以内——如果超出，就进一步精简

自主执行规则

• 直接执行：读取 SESSION.md、读取 CLAUDE.md、检查 git 状态和日志、提供摘要
• 简短确认：创建新的 SESSION.md、提交 WIP 检查点
• 先询问：覆盖现有 SESSION.md、删除会话数据

参考文件

时间	阅读内容
创建新的 SESSION.md 时	references/session-template.md
上下文压缩技巧、哪些内容会保留	references/compaction-survival.md