---
name: 接班
description: 新 session 開場讀最新 handoff doc 接手上次 session 的工作。觸發情境：(1) 用戶說「接班」、「看 handoff 然後做」、「繼續做上次的」(2) 新 session 開場沒有上下文但明顯是接續之前工作 (3) 用戶說「/接班」。不適用於：當次 session 從零開始、用戶明確說「不要讀 handoff」。
---

# 接班 — 讀 handoff doc 繼續上次工作

## 概述

從 `docs/superpowers/handoff/` 讀最新（或指定 topic）的 handoff doc，理解上次 session 做到哪、下次要做什麼，然後開始執行 critical path。

**設計原則：** 讀完 doc 要跟用戶確認接續哪個 topic，不要悶頭就開始動工。

---

## 固定路徑

```
{repo-root}/docs/superpowers/handoff/YYYYMMDD-NN-<topic-slug>.md
```

---

## 執行流程

### 步驟 1：列出最近的 handoff doc

```bash
ls -t docs/superpowers/handoff/*.md 2>/dev/null | head -10
```

按 mtime 倒序列最近 10 份。若目錄不存在 → 告知用戶沒有 handoff doc。

### 步驟 2：決定要接哪一份

**場景 A**：用戶只說「接班」「/接班」→ 自動挑最新一份（`ls -t | head -1`）

**場景 B**：用戶說「接 Phase 3b」「接班 hub」→ `grep -l "<關鍵字>"` 篩選後挑最新一份

**場景 C**：列表多筆且無法判斷 → 列出檔名 + 一行摘要，讓用戶挑

### 步驟 3：讀 doc

`Read` 整份 doc 內容。**先看 in-flight 跟 mental notes**，這兩段是接手最關鍵的東西。

重點掃（依優先序）：
- **🔄 In-flight**：上次卡哪、不要重做的副作用、繼續從哪 — 這是最重要的，第一個動作通常從這裡接
- **🧠 Mental notes**：對話脈絡、user 偏好、已否決方案 — 內化進你的判斷，不要重新討論已定案的事
- **目標 / Next**：一句話下次要做什麼
- **已完成**：哪些不重做
- **Critical path / Gotchas**（full 版才有）：執行順序、踩過的坑
- **Secrets 位置**（full 版才有）：待會要用的帳密在哪

### 步驟 4：摘要給用戶 + 強制 self-check

依 doc 的模式（light / full）給對應摘要：

#### Light 模式摘要

```
讀到 handoff：{filename}

**目標**：{一句話}

**🔄 In-flight**：{有的話直接寫，沒就「無」}
**⏭ Next**：{1-2 步}
**🧠 Mental notes 已收到**：{挑 1-2 條最關鍵的回顯，證明有看到}

我打算這樣接：先做 {具體第一步}，用 {工具/方法}。對嗎？
```

#### Full 模式摘要

```
讀到 handoff：{filename}

**目標**：{一句話}

**接手狀態**：
- 已完成：{3-5 項最關鍵的}
- 🔄 In-flight：{半完成狀態，最重要看這段}
- 部署狀態：{關鍵服務的 up/down}

**這次要做**：
{critical path step 1}
{critical path step 2}
{critical path step 3}

**Gotchas 要注意**：{2-3 項最容易踩的}
**Mental notes**：{1-2 條 user 偏好 / 已否決方案}

我打算這樣接：先做 {具體第一步}，用 {工具/方法}。對嗎？
```

**強制 self-check 規則：**
- 一定要在最後問「我打算...對嗎？」 — 一句話、具體到動作 + 工具
- 不要寫長 plan，不要列 numbered steps
- user 一個 yes/no 就能往下走，避免方向跑偏

### 步驟 5：按 critical path 開始（用戶確認後）

依 handoff doc 的 critical path 執行：
- 通常第一步是「讀某些檔、grep 某個 symbol」→ 用 Read / Grep
- 複雜實作步驟 → spawn Plan agent 或 general-purpose agent
- 部署步驟 → 先 commit 再部署，守 CLAUDE.md 的規則

---

## 注意事項

1. **不要自動開始寫 code**：先讀 doc、確認方向、再動手
2. **Secrets 不在 doc 裡**：看到「在 Mac Mini `~/docker/xxx/.env`」→ 若要用，請用戶提供或 SSH 去拿
3. **Doc 可能過時**：若 doc 說 PR #132 未 merge，先 `gh pr view 132` 確認最新狀態
4. **多份 handoff 的處理**：同一個 topic 有多份時（如 `phase3b-01`, `phase3b-02`）→ 讀最新那份 + 掃前一份的差異
5. **Doc 引用其他檔**：doc 提到 `docs/superpowers/plans/xxx.md` → 也要讀，plan 是更細的計畫
6. **Doc 提到已完成的 PR**：接手前先確認 PR 狀態（merged / open），避免基於過期前提動工

---

## 範例互動

**用戶**："接班"

**Claude**：
```
讀到 handoff：20260420-01-phase3b-aibus-hub-handoff.md

**目標**：建 hub.aiaibus.com，功能跟 hub.yes-ceramics.com 一樣但走 MongoDB。

**接手狀態**：
- 已完成：Phase 2 mongo-db package + Phase 3a aibus-id adapter + id.aiaibus.com live
- 部署狀態：id.aiaibus.com ✅ live，hub.aiaibus.com ❌ 待建

**這次要做**：
1. Read aibus-hub 現況（getDb callers + firebase.js imports）
2. 寫 plan 參照 2026-04-19-phase3a-aibus-id-mongo-adapter.md 格式
3. Spawn agent 做 adapter
4. Dockerfile update（pattern 同 PR #131）
5. 部署 dev-hub container + Cloudflare tunnel rule
6. Smoke test

**Gotchas**：stacked PR no-op、Dockerfile workspace context、tunnel PUT 要 merge。

要直接按 critical path 開始嗎？
```

**用戶**："好"

**Claude**：開始 step 1 — Read aibus-hub getDb callers...
