Back to writing

/ Skills

[Skills-06] Working Across Contexts: Handoffs, Teaching, and Writing Pipelines

Distilling handoff, teach, and seven experimental skills for persistent sessions, interviews, teaching, and writing.

1 minSkill · Context Engineering · Teaching · Writing

上下文窗口不是数据库。对话变长以后,继续堆 token 会让 Agent 逐渐丢失早期细节。本篇的九个 skill 探索如何把状态外化:两个稳定 productivity skill,以及七个 in-progress 实验。

覆盖清单:handoffteachclaude-handoffloop-mebatch-grill-mewriting-fragmentswriting-beatswriting-shapewizard

1. handoff:跨 session 的最小上下文包#

Handoff 将当前 conversation 压缩成临时目录中的 Markdown,供新 Agent 接手。它必须包含:目标、已确认决策、当前状态、未决问题、下一步,以及 suggested skills。

但它不复制已经存在的 spec、ADR、issue、commit 或 diff,只引用路径与 URL。否则 handoff 会立刻成为第二份过期事实来源。

还有两条安全规则:

  • 根据用户给出的“下一 session 要做什么”定向摘要,不做无差别聊天转录;
  • 删除 API key、password、PII 等敏感信息。

handoff 与内置 compact 不同:compact 在同一会话中压缩历史;handoff 用文件把工作分叉到一个新会话。需要保留原会话或让另一个 Agent 并行接手时,用 handoff。

2. teach:把目录变成有状态学习系统#

Teaching skill 不把“教我 X”回答成一篇长文,而是建立多 session workspace:

工件作用
MISSION.md为什么学习,所有课程用它判断相关性
RESOURCES.md高信任知识来源
learning-records/*.md非显然认识与学习状态
lessons/*.html一次只教一个紧凑技能
reference/*.html可反复查阅的速查表、术语表和算法
assets/*课程共享样式、quiz、diagram 等组件
NOTES.md教学偏好与工作笔记

教学策略区分 fluency strength 和 storage strength。眼前看懂不等于长期掌握,因此 lesson 使用 retrieval practice、spacing 和 interleaving 制造 desirable difficulty;知识讲解反而要减少不必要难度,避免消耗 working memory。

每节课短小、自包含、直接服务 mission,并包含反馈环、第一方资源和后续提问入口。可复用视觉与交互必须进入 assets,避免每课复制一份内联实现。

3. claude-handoff:交接后立即启动后台 Agent#

这是 handoff 的实验性 Claude Code 变体。它不仅生成摘要,还通过 claude --bg 启动一个新后台 session 立即继续工作。

它把“生成交接文件”和“唤起接手者”合成一步,适合可以明确自动延续的工作。但也扩大了副作用:需要确保新进程的 working directory、权限、目标和敏感信息都正确。因此通用版本保留为纯文件更安全,平台特定自动启动则留在 in-progress。

4. loop-mebatch-grill-me:两种访谈节奏实验#

loop-me 把用户想构建的 workflow 当成长期规格设计任务,在当前 workspace 中反复访谈并持久记录。它适合 workflow 本身很复杂、无法一轮说清的情况。

batch-grill-me 则改变 grilling 的“一次一个问题”:每一轮一次询问当前 decision tree 的整个 frontier,收到回答后重新计算下一轮。它以更少往返换取更高单轮认知负担。

两者代表两种优化方向:

grilling          -> 最低单次认知负担,往返多
batch-grill-me    -> 较少往返,一次处理多个无依赖决策
loop-me           -> 跨 session 持久推进同一个 workflow spec

批量提问只有在问题彼此独立、用户更在意吞吐时才合理。依赖链较深时,一次一个问题仍然更不容易返工。

5. 三阶段 writing pipeline:先挖矿,再建旅程,再成文#

三个 in-progress writing skill 刻意拆开探索与收敛。

5.1 writing-fragments:只收集原料#

通过访谈挖掘 heterogeneous fragments:论点、例子、记忆、反例、比喻、证据和未解决疑问。它们被追加到一个原料文件中,不急着排序,也不强迫形成 outline。

5.2 writing-beats:安排读者经历#

Beat 不是传统章节标题,而是读者旅程中的一次认知动作:建立术语、制造张力、给出反转、落地例子。skill 从一个 starting beat 开始,每次只写一个 beat,再根据它带来的新可能选择下一个,直到自然结束。

它强调 dependency order:一个 beat 不能依赖读者尚未获得的概念。

5.3 writing-shape:逐段决定文章形状#

Shape 接收原料文件,逐段决定保留、删减、改写与排序,并对格式选择给出理由。它不是一次生成全文,而是让结构在每段反馈后收敛。

三者组合成:

Explore: fragments(扩大原料空间)
  -> Journey: beats(选择认知路径)
  -> Exploit: shape(收敛为连贯文章)

这比“先让 Agent 列大纲,再一键扩写”更重,但能避免模板化文章把尚未想清的观点包装得很流畅。

6. wizard:把人工 SOP 编译成可恢复脚本#

Wizard 为第三方设置、一次性迁移或状态转换生成交互式 Bash。脚本逐步引导人打开 URL、执行外部操作、输入值,并写入 .env 或 GitHub Actions secret。

好的 wizard 需要:

  • 每一步说明人要做什么、Agent 能验证什么;
  • 对 required command、当前状态和输入格式做 preflight;
  • secret 不打印、不写进普通日志;
  • 重跑时识别已完成步骤,尽量 idempotent;
  • 失败时保留明确恢复点,而不是让用户从头猜。

它适合无法完全自动化、但步骤稳定且容易出错的流程。真正可以 API 自动完成的动作不应强行留给人。

7. 外化状态的共同原则#

九个 skill 虽然跨越交接、教学、写作和脚本,却都遵循同一个模式:把隐含在上下文中的状态变成命名工件,让下一次交互从工件继续,而不是依赖模型“记得”。

实验性 skill 的具体文件格式可能变化,但这条原则稳定:聊天负责推进,仓库或临时文件负责记忆。

参考#