/ Skills
[Skills-06] 跨上下文工作：Handoff、Teaching 与 Writing Pipelines
提炼 handoff、teach 以及 7 个实验性 skill：如何跨会话保留状态、组织持续教学、批量访谈和分阶段写作。
上下文窗口不是数据库。对话变长以后，继续堆 token 会让 Agent 逐渐丢失早期细节。本篇的九个 skill 探索如何把状态外化：两个稳定 productivity skill，以及七个 in-progress 实验。
覆盖清单：handoff、teach、claude-handoff、loop-me、batch-grill-me、writing-fragments、writing-beats、writing-shape、wizard。
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-me 与 batch-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 的具体文件格式可能变化，但这条原则稳定：聊天负责推进，仓库或临时文件负责记忆。