project-handoff

# 项目交接 让接手对话拿到当前成果、有效决定和明确的第一步，不用用户重述，也不会两个对话同时改。适用于代码、文档、研究和媒体制作。提醒、保存、新建接续是三个动作，各有各的授权：提醒不写文件，保存不开新对话，新建只在用户确认了具体提议之后。 ## 入口 | 信号 | 做什么 | 读哪页 | | --- | --- | --- | | 用户要求保存进度、整理交接，或只输入本宿主的交接入口（Codex `$project-handoff`，Claude Code `/project-handoff`） | 保存材料，交付路径和可复制的开场白。笼统的“交接一下”也只到这一步 | [保存、自动接续与恢复](references/handoff.md)「保存」 | | 用户明确要求新建并继续，或确认了写明“保存、在指定目录新建并打开、核对后继续”的提议 | 保存后自动接续。同一次明确授权不逐步重问 | 同页「自动接续」 | | 用户指定交接来源并要求继续 | 恢复：先只读核对，再按已有授权推进。只要求查看就只读 | 同页「恢复」 | | 宿主注入 project-handoff 计数或待评估的检查点；准备交付一个可独立验收的阶段；进入下一大段工作；发现已核实的目标、版本或约束混淆 | 按下节评估是否建议交接 | 本页；有计数器时再读 [计数、评估与最终核验](references/compaction-reminder.md) | 讨论、审查、修改本 Skill 本身不触发以上任何动作；正好在检查点时，按参考页登记为不适用。 ## 评估：什么时候值得建议换对话 只用当前任务已有的事实判断：用户决定、验证结果、文件和任务的真实状态、宿主的压缩事件。不翻私人历史，不为评估另调模型，也不按聊天轮数或感觉估算压缩次数。 | 条件 | 看什么 | 为什么 | | --- | --- | --- | | 安全位置 | 当前操作已收拢；成果、验证和后台任务的归属都能定位；该用户验收的不写成已验收 | 接手时不能有半截写入或没人认领的任务，否则两边都以为对方在管 | | 明确后续 | 目标、范围、下一步和完成标准清楚，新对话能确定第一步 | 没有第一步的交接只是存档，新对话还得回头问用户 | | 切换收益 | 能说出这次的具体好处，例如已结束的大量探索和后续执行分开、已纠正的旧路线不再带入 | 换对话有成本：重读材料、丢隐性上下文。只有旧上下文会拖累下一步时才值得 | - 第 3 次自动压缩后，前两条满足就提醒一次，不等大阶段。前两次压缩不因次数提醒。 - 之后再提醒要同时满足：新的实质阶段、具体收益、距上次正式提醒又过了 3 次压缩。同阶段改版本、调参、重渲染不算新阶段。 - 已核实的新混淆先纠正，纠正后可以不等冷却就提醒；同一问题只提醒一次。普通报错、正常改需求、对话变长都不是混淆。 - 目标或权限还不清楚时先补缺项。换对话不解决阻塞、失败原因或待验收的步骤。 - 纯问答、任务已结束、讨论本 Skill：不提醒。 - 有计数器时，最终答复前按参考页登记一次结果（提醒、暂缓、不适用）；暂缓要写原因和下次检查时机。没有计数器就自检，不要声称有程序兜底。 ## 展示 决定提醒且用户尚未回应时，建议放在最终答复正文第一段，在成果列表和任务卡之前，以“交接建议：”开头，一段话写清具体原因、接续第一步和确认后会做的动作。放最前，是因为用户通常只看开头和结尾，计数器的最终核验也只认首段；进度消息不算展示。不要放进引用、示例或代码块。例句只示范格式，不是项目事实： > 交接建议：资料筛选已完成，后续进入方案编写，适合只带入已选资料与约束。确认后我会保存材料，在同一项目原目录新建并打开任务，核对后继续编写方案。 没有自动新建能力的宿主，把“新建并打开”改成实际能做的保存和手动入口。已交付的建议不在以后每轮重贴；用户已回应、建议失效或任务已无后续时撤下。 ## 用户回应与边界 - “先不交接”“继续做”：从回应时再冷却 3 次压缩。普通工作指令里的“继续”既不是回应，也不是交接批准。 - “做完 X 再提醒”：到 X 再评估，不另加次数门槛。 - “本任务不提醒”：关闭主动提醒，直到用户恢复；显式交接请求仍执行。 - 没人回应：继续已授权工作，不追问、不自动保存、不自动新建。提醒本身不授权写文件、停止任务或新建对话。 - 规则只放本 Skill 及配套资源，不写入全局路由、不加定时任务、不改压缩阈值。保存和接续仍按既有授权与宿主边界执行。