名称: 交接描述: “向PM提交完成报告以及代理间交接。实现平滑过渡。当用户提到’/handoff’、完成报告、交接给Cursor/OpenCode、自动修复或向PM报告时使用。请勿用于：随意完成声明、进度聊天、非正式状态更新。” description-en: “Completion report to PM and agent handoff. Smooth transition achieved. Use when user mentions ‘/handoff’, completion report, handoff to Cursor/OpenCode, auto-fix, or reporting to PM. Do NOT load for: casual completion statements, progress chat, informal status updates.” description-ja: “PMへの完了報告やエージェント間バトンタッチ。スムーズな引き継ぎを実現。Use when user mentions ‘/handoff’, completion report, handoff to Cursor/OpenCode, auto-fix, or reporting to PM. Do NOT load for: casual completion statements, progress chat, informal status updates.” 允许工具: [“读取”, “写入”, “编辑”, “Bash”, “Grep”, “Glob”] 参数提示: “[cursor|opencode|auto-fix]”

交接技能

管理PM与实现者之间的交接和工作流程迁移的技能。

功能详情

功能	详情
PM→实现者	参见 references/handoff-to-impl.md
实现者→PM	参见 references/handoff-to-pm.md
审阅指摘自动修复	参见 references/auto-fixing.md
提交执行	参见 references/execute-commit.md

快速参考

“向Cursor写入完成报告” → /handoff cursor
“交接给OpenCode” → /handoff opencode
“自动修复审阅指摘” → /handoff auto-fix
“包括变更内容和测试结果” → 包含git差异和测试结果

前提条件

此命令仅在harness-review批准后运行

条件	必需	检查方法
harness-review 完成	是	审阅结果为批准
无关键/高优先级问题	是	所有已修复
实现完成	是	Plans.md任务已完成

为什么交接需要审阅批准:

否则PM会收到未经审阅的变更
质量无法保证
破坏 /work 工作流程（实现 → 审阅 → 修复 → 批准 → 交接）

用法

/handoff cursor     # 交接给Cursor
/handoff opencode   # 交接给OpenCode

执行流程

步骤 1: 识别已完成任务

检查Plans.md复选框
总结已完成工作

步骤 2: 更新Plans.md

# 之前
- [ ] 任务名称 `pm:依頼中`

# 之后
- [x] 任务名称 `cc:完了` (YYYY-MM-DD)

步骤 3: 收集变更

git status -sb
git diff --stat

步骤 4: 检查CI/CD（如果适用）

gh run list --limit 3

步骤 4.5: 统一内存最终确定（必需）

完成报告前，向共同内存确定最终状态：

harness_mem_record_checkpoint(session_id, title, content, tags?, privacy_tags?)
harness_mem_finalize_session(session_id, summary_mode="standard")

这使得Claude Code / Codex / OpenCode可以从任何地方恢复同一会话。 session_id 通过 $CLAUDE_SESSION_ID → .claude/state/session.json 中的 .session_id 顺序获取。 harness_mem_sessions_list(project, limit=1) 的第一个使用仅限于只读（恢复确认），交接时的 record_checkpoint / finalize_session 如果没有明确 session_id 则视为失败。如果 harness_mem_finalize_session 失败，则不确认交接。

步骤 5: 生成报告

输出格式

## 完成报告

### 摘要
- (1-3行描述完成的工作)

### 已完成任务
- **任务名称**: [任务描述]

### 变更文件
| 文件 | 变更 |
|------|---------|
| `路径/到/文件1` | [摘要] |
| `路径/到/文件2` | [摘要] |

### 验证结果
- [x] 构建成功
- [x] 测试通过
- [x] 手动验证完成

### 风险/备注
- (如有)

### 后续操作（为PM）
1. [ ] [PM接下来应做的]
2. [ ] [可选项目]

/work 集成流程

/work 执行
    ↓
阶段 1: 并行实现
    ↓
阶段 2: harness-review 循环
    ├── 不通过（关键/高优先级） → 修复 → 重新审阅
    └── 通过（批准） → 阶段 3
    ↓
阶段 3: 自动提交（如果配置）
    ↓
阶段 4: 此技能运行 ← 首次交接发生

/work 在阶段4自动调用此技能。手动运行时，始终在harness-review批准后进行。

handoffSkill handoff