⚡

会话交接技能Skill handoff

这个技能用于创建结构化文档，确保在不同工作会话之间的连续性，适用于项目管理、团队协作和效率提升。关键词：会话交接、文档生成、连续工作、项目管理、协作工具。

其他 0 次安装 2 次浏览 更新于 3/13/2026

name: handoff description: 创建结构化会话交接文档以实现跨会话的连续性。使用场景包括结束工作会话、切换上下文或休息前。捕获决策、进度、代码更改和后续步骤，以便未来会话能够无缝接续，不会丢失上下文。

会话交接技能

创建结构化文档，实现克劳德（Claude）会话之间的无缝连续性。

使用时机

  • 结束一天的工作会话
  • 任务中途休息前
  • 暂时切换到不同项目
  • 希望为未来会话捕获状态时
  • 知道即将进行上下文重置前

交接流程

步骤 1：评估会话状态

快速评估：

  1. 我们处于哪个阶段？（探索、规划、实施、调试、评审）
  2. 当前任务是什么？（我们试图完成什么）
  3. 进度如何？（刚开始、中途、即将完成）

步骤 2：询问重要事项

询问用户：

“我将创建交接文档。您有什么特别希望我捕获的吗？（关键决策、代码片段、问题上下文、您可能会忘记的事项等）”

步骤 3：生成交接文档

创建结构化文档：

# 会话交接：[简要描述]

**日期：** [YYYY-MM-DD]
**项目：** [项目名称/路径]
**会话时长：** [近似值]

## 当前状态

**任务：** [我们正在做什么]
**阶段：** [探索/规划/实施/调试/评审]
**进度：** [进度位置 - 百分比或里程碑]

## 我们做了什么

[2-3 句话总结会话工作]

## 做出的决策

- **[决策]** — [理由]
- **[决策]** — [理由]

## 代码更改

**修改的文件：**

- `path/to/file.ts` — [做了什么及为什么]
- `path/to/other.ts` — [做了什么及为什么]

**关键代码上下文：**
[需要记住的关键片段或模式]

## 开放问题

- [ ] [需要解决的问题]
- [ ] [需要解决的问题]

## 阻碍/问题

- [问题] — [当前状态]

## 需要记住的上下文

[重要背景、约束、用户偏好、领域知识 - 需要时间重新建立的内容]

## 后续步骤

1. [ ] [下次会话的第一件事]
2. [ ] [第二件事]
3. [ ] [第三件事]

## 恢复时需要审查的文件

- `path/to/key/file.ts` — [为什么重要]

步骤 4：写入文件

写入：.claude/handoffs/[YYYY-MM-DD]-[简要描述].md

与用户确认位置：

“我将保存此文件到 .claude/handoffs/[文件名].md。需要不同位置吗？”

捕获内容

始终包括

  1. 带理由的决策 — “为什么”通常比“是什么”更有价值
  2. 代码更改 — 文件路径、更改内容、意图
  3. 当前进度 — 任务中停止的位置
  4. 后续步骤 — 清晰、可操作的项目以便恢复
  5. 用户上下文 — 他们分享的约束、偏好、领域知识

相关时包括

  • 遇到的错误 — 以及如何（或未）解决
  • 死胡同 — 尝试过但无效的方法（节省重新探索时间）
  • 关键文件 — 需要阅读以快速上手的文件
  • 外部依赖 — 涉及的 API、服务、工具

跳过

  • 冗长的工具输出（文件列表、grep 结果）
  • 达到结论的中间推理
  • 重复的类似操作
  • 从代码中显而易见的信息

格式指南

  • 要点列表 — 便于扫描而非叙述
  • 文件路径 — src/foo.ts:42 而非“那个函数”
  • 操作复选框 — - [ ] 用于后续步骤和开放问题
  • 具体内容 — “向 fetchUser() 添加重试逻辑”而非“做了改进”

质量检查

保存前，验证：

  1. 一个新克劳德（Claude）能否从此接手？ — 是否有足够的上下文继续？
  2. 决策是否可追溯？ — 为什么做出决策是否清晰？
  3. 后续步骤是否可操作？ — 是否知道首先要做什么？
  4. 代码工作是否清晰？ — 是否知道哪些文件重要？

使用交接文档

开始新会话时，用户可以：

  1. 在会话开始时分享交接文件
  2. 说“从此交接恢复：[粘贴或路径]”
  3. 如果支持，使用 @ 提及引用它

交接应让您无需冗长重新解释即可快速开始工作。

示例交接

# 会话交接：认证系统实施

**日期：** 2025-01-15
**项目：** /Users/robert/projects/my-api
**会话时长：** ~2 小时

## 当前状态

**任务：** 为 API 实施用户认证
**阶段：** 实施
**进度：** ~60% - 基本流程有效，需要刷新令牌

## 我们做了什么

构建了核心 JWT 认证流程，包括令牌生成、验证中间件和登录/注销端点。遇到了密钥轮换问题，通过移至基于配置的密钥路径解决。

## 做出的决策

- **使用 RS256 的 JWT** — 无状态认证，适用于分布式设置
- **Redis 用于刷新令牌** — 需要撤销能力
- **15 分钟访问令牌过期时间** — 平衡移动应用的安全性和用户体验

## 代码更改

**修改的文件：**

- `src/auth/jwt.ts` — 令牌生成和验证逻辑
- `src/middleware/auth.ts` — 请求认证中间件
- `src/routes/auth.ts` — 登录/注销端点
- `config/keys/` — RSA 密钥对存储

**关键代码上下文：**
令牌验证使用 RS256。密钥根据 NODE_ENV 从 `config/keys/` 加载。

## 开放问题

- [ ] 自动与选择加入的刷新令牌轮换？
- [ ] 登录尝试的速率限制？（用户提到 10k DAU）

## 需要记住的上下文

- 客户端是移动应用 - 令牌需要离线能力
- 用户有 10k 日活跃用户 - 规模重要
- 使用 PostgreSQL 存储用户
- 用户偏好明确错误消息而非通用消息

## 后续步骤

1. [ ] 实施 `/auth/refresh` 端点
2. [ ] 向 `/auth/login` 添加速率限制
3. [ ] 编写令牌过期边缘案例测试
4. [ ] 使用认证流程更新 API 文档

## 恢复时需要审查的文件

- `src/auth/jwt.ts` — 核心令牌逻辑
- `src/routes/auth.ts` — 当前端点实施

关键提醒

  • 生成前询问用户重要事项
  • 决策需要理由 — 捕获“为什么”
  • 文件路径锚定工作 — 始终包括它们
  • 后续步骤应立即可操作
  • 稍长但有用胜过短而模糊