Fleet Epic Split（出題器 A）

把一顆已簽核的目標拆成互相獨立、各自可 merge 的原子 fleet:pending 單。 你只起草提案，撕成 ready 是操作者的事。本 skill 於 #599 吸收了已退役的 plan-decompose：輸入形狀放寬、去重程序、建單前確認表、交叉引用、provenance 回連。慣例見 repo 自身的 CLAUDE.md／AGENTS.md（本 repo：.claude/CLAUDE.md）。

輸入（四選一；開工時先固定 provenance）

provenance 是 ⑦ 回報與每張單 Relation/footer 的回連目標——輸入沒記，後面就斷了。

開工前

• repo 根有 FLEET_PAUSE → idle 退出。
• 目標已有簽核（fleet:goal issue、operator 簽過的 epic、或操作者當面指示）。

七步（順序不可跳；每步有可核對的產出）

① recon（只准調查）→ 產出：帶 file:line 證據的現況報告

讀 repo 現況與輸入，產出報告：輸入要的東西，哪些已經做完（既有程式、 測試、輸入裡的 [x] 標記與實際碼是否相符——標了不算數，要碼在），哪些還沒。 禁止在這一段提解法或寫計畫。已完成的部分不生單。

② decompose（拆原子單）→ 產出：候選清單，每張標獨立性判定

把「輸入 − 已完成」的差距拆成原子單。每張必過獨立性三問：

1. 單獨 merge 會不會弄壞 main？
2. 跟別張單改同一批檔案嗎？
3. 不看其他單，能不能直接開工？ 兩張搶同一檔 → 合併成一張，或標 獨立性: blocked by #N 明示依賴。 禁止：出「重構整個 X」這種巨單；出一個 session 做不完的單（做不完就再拆）。 每輪上限 30 張——超過就分輪，這一輪只取 30 張走完全程。

③ dedupe（去重）→ 產出：每張候選一行的 dedupe 紀錄

四道程序都要跑，並紀錄查了什麼、結果如何：

1. 文件內 #N 引用 — 輸入裡已指名的 issue 號 → 該項 skip（已存在 #N），不生單。
2. edda ask "<domain>" — 命中已裁決範圍 → 不生單（紀錄命中的決策 key）。
3. edda search query "<keyword>" — 帳本／文件的既有軌跡。
4. open-issue 模糊比對 — gh issue list --state open --limit 200 --json number,title 對標題模糊比對；疑似重複在確認表標 possible duplicate? #N 交操作者裁。 每張候選一行：<候選> | queries: … | verdict: new / duplicate of #N / merge with 候選k。 沒有目標 repo／帳本可查的環境（例如純文字的隔離 dry run）：程序 2–4 記 unavailable（無 repo/ledger 環境），確認表的 dedupe 欄標 unverified， 補查交給操作者在裁決時做。

④ 確認表（建單前必經）→ 產出：一張確認表

操作者沒看過這張表，不准建任何 issue。 一張擬建單一列：

表後附 skip 清單（重複項 → 指向的既有 issue）。等操作者回 yes / adjust / cancel； adjust 就改表重出。dry run（操作者要求只看不建）：停在這一步——印確認表 ＋每張擬建單的完整 body，不執行任何 gh issue create。

⑤ create（全部 fleet:pending）→ 產出：issue 號清單

每張 body 逐節照下方「Body 契約」填寫後： gh issue create --title "<動詞開頭>" --body-file <tmp> --label fleet:pending 標題動詞開頭；body 內不帶 closing keyword。不使用 ready-bar 以外的任何 body 格式（舊並行格式已隨 plan-decompose 退役）。

⑥ 交叉引用 → 產出：comment 的連結

• batch 內依賴：gh issue comment <N> --body "Blocked by #M. Related: #K"—— blocked-by 與 related 都要落成 comment，不能只寫在 body 裡。
• skip 但相關的既有 issue：到該 issue 留一則 comment（指回 provenance 與新單號）。

⑦ report（provenance 回連）→ 產出：回報清單

issue 號＋標題＋獨立性＋surface 一覽。每張單的 Relation to existing issues 節與結尾 footer 都回連 provenance（epic issue 號／--doc path:line／決策 key）； 回報本文本身也附 provenance 連結。

Body 契約（唯一定義處）

唯一定義在 issue-intake/templates.md—— 本檔不複製全文；寫單前先讀該檔，逐節照填。讀不到該檔的環境（隔離／純文字）： 仍須按下列固定的節順序逐節產出——節名與順序如下，內容自填，缺一節不准發。 節順序固定：

What happened → Why it matters → Suspected surface → Predicted surface → doneWhen → Wiring audit（四問槽）→ Relation to existing issues

• Predicted surface = 這張單會寫的 paths＋symbols——parallel-wave Layer 1 拿它做並行判定；列不出來 = 範圍還太糊，回 ② 重拆。
• Wiring audit 槽：引用或新增 code 的單，每個 component 一行四問 （writer／reader／failure signal／layer reach），file:line 本 session 驗過。
• 缺任何一節不准發。

界線

你不撕 ready、不寫實作碼、不 merge、不在確認表之前建單。你的產出是「待簽的 提案」，下游有測試閘門兜底，但錯的方向沒有閘門攔得住——所以寧可少拆、 標清依賴，也不硬湊數量。