tingyulu /new-mission — 任務簡報
新任務開工前的固定流程：先問對問題、再給計畫、審過、使用者點頭、才動手。順便產出一份能重複使用的任務 prompt；執行結束後，交一份對照計畫的收尾報告。
🤖 R2-D2 時刻：R2 把死星藍圖投影出來，反抗軍圍著全像圖把攻擊路線看完、確認那條溝渠可以飛，X-wing 才升空。沒有人在看完藍圖之前就起飛。
為什麼需要
Claude 接到任務的預設行為是直接開始做。做到一半才發現三件事，每一件都要重來：
- 這件事已經有人在做，或已經有一張卡、一份檔案、一個負責人。另起爐灶的成本不是重工，是兩份互相矛盾的真相。
- 範圍理解錯了。使用者的一句話裡有三種讀法，Claude 挑了最順手的那種，做完才被退。指示越短、解讀空間越大，而 Claude 通常不會察覺自己選了哪一種解讀。
- 產出落在沒人找得到的地方。分析做了、品質也夠，但只活在對話裡；三個月後要用的人不知道去哪裡找。
這三件事，多數在動手前問一句就能擋掉。這支 skill 把「問哪幾句」「問完做什麼」「什麼時候才准動手」釘成固定順序。
什麼時候不要用
做錯的代價小於問一輪的代價，就直接做。判準：一兩步、可逆、做壞了重來只花幾分鐘的事不用跑這支。三步以上、會寫進共用檔案、會發訊息給別人、會改規則的，跑。
動作
0. 開場分流，然後先查、不空問
⏰ 開場第一行先報時間：不管接下來是分流、是先查、還是直接給計畫，回覆的第一行固定是
⏰ <YYYY-MM-DD（週幾）HH:MM> <IANA 時區> —— 例 ⏰ 2026-03-09（一）10:12 Europe/Berlin
時區不可省。人與機器不在同一個時區、或使用者正在外地時，一個沒有時區的時間讀不出來是哪裡的幾點。印的是這台機器的時區，不要假裝知道使用者人在哪。
從機器取，不要憑印象拼。零依賴取法（macOS／Linux 通用，不需 python）：
set -- $(date '+%Y-%m-%d %u %H:%M') case $2 in 1) w=一;; 2) w=二;; 3) w=三;; 4) w=四;; 5) w=五;; 6) w=六;; 7) w=日;; *) w=;; esac tz=${TZ:-$(readlink -f /etc/localtime 2>/dev/null || readlink /etc/localtime 2>/dev/null)} tz=${tz#:}; tz=${tz##*/zoneinfo/} [ -f "/usr/share/zoneinfo/$tz" ] || [ -f "/var/db/timezone/zoneinfo/$tz" ] || tz="$(date +%Z)（非 IANA 名稱）" [ -n "$1" ] && [ -n "$w" ] && printf '⏰ %s（%s）%s %s\n' "$1" "$w" "$3" "$tz" || echo '時間取不到完整值'三個地方別省：① 星期用
%u（1–7）對照表——date '+%A'給的是 locale 決定的Tuesday／星期二，都不是規格要的「（二）」。② 一次date取齊所有欄位，分開呼叫會在跨午夜時湊出「新日期＋舊星期」這種看不出破綻的錯。③ 最後那行的驗證是整段的重點：把切出來的名字拿回時區資料庫對，對不上就退成%Z縮寫並標「非 IANA」。所有「看起來合格、其實是錯的」路徑都在這裡被擋下——多層符號連結的中繼目標、連結指向非時區檔、$TZ裝的是PST8PDT／:Asia/Taipei這類 POSIX 寫法。🚫 寧可標「非 IANA」，也不要印一個猜出來的名字。回覆語言不是中文時，週幾寫該語言的慣用形式即可（
⏰ 2026-03-09（Mon）10:12 Europe/Berlin）；不可省的是時區，不是格式的中文外觀。跑不了 shell 的環境（網頁版、無終端機）：用當回合系統給的時刻，自己補上時區標籤；連完整值都拿不到就直接寫「時間取不到完整值」，🚫 不要包裝成一個看起來合格的時間行。
先分流：觸發時使用者還沒說任務是什麼（只打了觸發詞）→ 第一則訊息只問下面這個，不掃環境、不預先查——查證要有目標才有意義，空手先掃一輪是最貴的猜謎：
這次要開什麼任務？
- 直接回一句話任務描述
- 從待辦挑——我列重要的給你選
回 2 才去翻這個專案看得到的待辦／交接紀錄（有任務系統的見進階節），挑最重要的至多五件編號列出，使用者回數字就接那件當任務描述。觸發時已帶任務說明的，跳過此問直接往下。
然後先查：問使用者之前先花一輪查能查的：這個目錄、相關專案、待辦系統、最近的交接紀錄。範圍盒：最多一輪、以任務描述的關鍵詞為索引，引結論與出處、不貼全文——查證是為了少問一題，不是展示讀了多少。查到的東西拿去確認，不是拿去問。 「我查到這件事 X 已經有一張卡在做，你要接續還是另開？」比「這件事之前有人做過嗎？」省使用者一半的力氣，而且不會讓他覺得你什麼都沒讀。
1. 問，一次一題，最多五題
每題只在自己查不到的時候問。答案含糊就追一次，不追第二次（追問算同一題，不另佔名額）；三題內收斂最好。預設一次一題；使用者明說「一次問完」時才集中列出（仍最多五題，含糊仍只追一次）。
能給編號候選就給：第 0 步查到的東西直接生成選項（「落點：1＝掛既有的 X／2＝開新檔／3＝對話交付」），使用者回數字即可，打字量最小；生不出合理候選才開放式問。任一題使用者回「跳過」或「都可以」→ 採用最合理的預設值，並把該預設寫進第 2 步的【假設】格——少答一題不等於少一條風險，風險改由假設清單浮上檯面。
- 要什麼：「做完之後，你手上多了什麼？」一句話講不清楚的，通常是兩件事，先拆。
- 不要什麼：「哪些不算在這次範圍裡？」邊界比目標更常被猜錯。
- 既有：把第 0 步查到的拿出來確認：「已經有 X，接續還是另開？」查不到就明說「我查了 A、B、C 都沒有」，讓使用者知道掃過哪裡。
- 落點：「產出放哪、給誰看？」問這題的判準：三個月後有人要找這份東西，他會去哪裡找？那裡有嗎？ 候選裡永遠給一個具體檔案路徑檔位（如「2＝落檔
<工作目錄>/mission-reports/<日期>-<任務>.md」）；列「對話交付」時旁邊明標「（對話結束即消失）」。這題的「跳過」預設＝落檔到上述路徑，不是對話交付——落地優先於蒸發。 - 完成判準：「做到什麼算完成？怎麼驗？」這題的答案會原封不動進計畫，執行完拿它對照。
⚠️ 使用者說「我記得之前有立過 X」：先查證再回答。查不到就說查不到，不要順著講。他的記憶可能是對的（那是真缺口，要新立）也可能是錯的（那就省一件事），兩種都比順著講好。
2. 第一版計畫，不實作
固定骨架，每格都要填，填不出來的寫「未知，需確認」而不是留白：
【目標】一句話
【範圍】內：…／外：…
【既有】接續 X／另開，理由
【步驟】每一步配一個驗證方式（怎麼知道這步真的做完了）
【假設】每一條假設都是一個要被使用者看見的風險
【產出】形式／落點；收尾報告放哪也在這格先寫明（沒指定就寫預設 `<工作目錄>/mission-reports/…`；無檔案系統的純聊天環境才寫「對話交付」）
【完成判準】照第 1 步第 5 題的答案
🚫 這一步不動手。不建檔、不改檔、不發訊息、不寫進共用系統。計畫本身可以落在暫存區。
比例原則（與第 7 步同一條）：貼近「什麼時候不要用」下限的小任務，計畫每格壓成一行、第 3 步的自審與審稿表一條一行。格不刪、行要短，一屏讀得完。⚠️ 第 5 步的優化 prompt 不在壓縮範圍——它的用途是複製貼上重用，永遠用模板區塊完整呈現；壓成一行使用者會認不出那是一份 prompt，等於廢掉功能（行為實測踩過）。
3. 送審
計畫先過一輪審，再給使用者。零依賴版是自審；有外部審稿工具的接在進階節。
自審五問，逐題回答、一題一到兩句：
- 這個計畫解的是使用者問的那件事，還是我順手想做的事？
- 每一步的驗證方式寫了嗎？「做完」是誰說了算？
- 哪一步做錯的代價最高？計畫裡有沒有把它放在前面或設停損？
- 假設清單裡，哪一條錯了整個計畫要重來？
- 這個計畫有沒有繞過使用者剛剛講的某個「不要」？
（這五問審的是計畫；收工後審結果的另一組五問見 damage-report——一頭一尾，兩組不重複。）
審稿意見的處理紀律：診斷可以收，處方要自己判。審稿者抓到問題常常是對的，但它給的改法是通用平均值，未必合這件事。逐條標「採納／不採納＋理由」，不採納的也要留下，讓使用者看得到你拒絕了什麼。
4. 給使用者審，等明確的「做」
呈現三樣：整合後的計畫、審稿意見處理表、下一節的優化 prompt。結尾固定給編號選項，然後停：
- 開始執行 2. 要改（回我改哪裡） 3. 先擱置
🔴 沒有明確確認不動手。 「看起來可以」「應該沒問題」不算確認；「回 1」或「做」「開始」「go」這類明確的字才算，且是對目前這份計畫的直接回覆——引用、反問、或討論規則時提到這些字眼都不算。沒等到就不動，即使計畫看起來很安全。
使用者改了計畫的某一段：回報改動點，不是只給新版。「我把第三步移到第一步、把 X 從範圍外移進範圍內」這一句讓他一眼能否決；重寫過的整份計畫他要重讀才能發現你理解對不對。
5. 輸出優化後的任務 prompt
用第 1 到 4 步收集到的東西填這個模板。它的用途是下次同一件事、或這件事中斷後重開，貼上去就能從對的地方開始，不用再問一輪：
【任務】<第 1 題的答案，一句話>
【範圍】內：<…>／外：<第 2 題>
【既有】<接續哪張卡／哪份檔，或「查過 A、B、C 皆無，全新」>
【產出】形式：<…>／落點：<第 4 題>
【完成判準】<第 5 題，原話>
【已確認的假設】<第 2 步假設清單裡使用者點頭的那些>
【不要做的事】<使用者在過程中說過的每一個「不要」>
【驗證要求】每一步做完要能指出證據在哪；憑印象的標「未驗證」；掃不到的明說「掃不到」，不靜默跳過
【收尾】做完交收尾報告（見第 7 步）：計畫／執行過程／成果對照／誠實帳／落點五格，明講什麼沒做、什麼沒驗、什麼是猜的
📝 這份 prompt 在第 4 步跟計畫一起呈現（預覽）；拿到「做」之後才隨計畫存進使用者指定的落點——簡報階段不把計畫或 prompt 寫進使用者的落點／共用系統（第 2 步的暫存區草稿、進階節的送審暫存檔不算落地）。
6. 確認後執行
拿到明確的「做」才開始。執行中遇到會影響範圍、風險或完成判準的計畫外狀況（新發現、新阻礙、範圍要變），停下來回報，不自作主張擴大或縮小。每完成一步，當下記一行「做了什麼、證據在哪」——第 7 步的【執行過程】從這份記錄長出來，不是靠回憶補。
7. 收尾報告
執行結束後——做完、做一半停掉、失敗收場都算——交一份完整報告，不是一句「做完了」。固定骨架，對照第 2 步的計畫逐格填；沒有內容的格寫「無」，不刪格：
【計畫】使用者核可的最終版；中途改過的列改動點，不重貼全文。第 5 步的優化 prompt **全文**附在本格末——prompt 是這件事可重跑的濃縮版，少了它報告就當不了下次的起點；照第 2 步的規矩不壓行
【執行過程】逐步對照計畫：每步一行「做了什麼 → 證據在哪」（指令輸出、檔案路徑、連結）；計畫外狀況單獨列：發生什麼、當時怎麼裁決、有沒有停下來回報
【成果】完成判準逐條對照：過的附證據，沒過的講差在哪
【誠實帳】沒做：略過或降級的步驟＋原因／沒驗：做了但沒驗證的＋驗證等級（看起來對 ≠ 驗過 ≠ 實際跑過）／猜的：哪些結論是推論不是證據
【落點】產出實際放在哪；與計畫落點不一致要明講原因
報告放哪，照第 2 步【產出】格寫明的收尾報告落點走：計畫核可了落點就落檔；落點是既有載體（卡片、討論串）就附加上去；計畫沒指定、但環境有檔案系統（裝得了本 skill 的環境都有）→ 落預設路徑 <工作目錄>/mission-reports/<日期>-<任務>.md 並在報告裡寫明；只有無檔案系統的純聊天環境（lite 簡版的情境）才在對話交付並明說「報告未落檔」——這不算降級失敗。
比例原則：貼近「什麼時候不要用」下限的小任務，五格各壓成一行照樣交齊；有沒過的完成判準、或出過計畫外狀況的，不准壓。
（收工前另有一組自審五問，見 damage-report——有裝的環境可先跑五問、拿結果餵【誠實帳】；沒裝也沒關係，五格自足，缺了姊妹 skill 不降級。）
🚦 鐵則
- 🔴 沒有明確的「做」不動手。計畫再安全也一樣，這是整支 skill 存在的理由。
- ⏰ 開場第一行報時間，含 IANA 時區；從機器取，不憑印象拼，取不到就照實說取不到。
- 🚫 不空問。能查的先查，查到的拿去確認，查不到的明說掃過哪裡。唯一例外＝空手觸發：先問任務是什麼，再開始查。
- 📝 一次一題，最多五題。含糊追一次，不追第二次；能給編號候選就給，讓使用者回數字。
- ⚠️ 計畫裡的每一條假設都要被使用者看見。藏在心裡的假設，錯了沒人知道。
- 📝 審稿的診斷可收、處方自己判。逐條標採納與否，不採納的留理由。
- 📝 改了計畫就回報改動點，不只給新版。指示越短，這句越必要。
- ✅ 完成判準在動手前就寫好，執行完拿它對照，不是做完才定義什麼叫完成。
- 📝 優化 prompt 要落在使用者指定的地方（拿到「做」之後落檔），不是只留在對話裡。
- 📝 收尾交報告，不是一句「做完了」——計畫、執行過程、成果、誠實帳、落點五格齊；小任務壓成五行也要齊。落地優先於蒸發：有檔案系統就不讓報告只活在對話裡。
進階：接上你自己的審稿工具
檔案版的自審五問是零依賴的最小公倍數，不是天花板。有跨模型審稿工具的，在第 3 步把計畫送出去審，拿回來的意見照同一套「診斷可收、處方自己判」處理。若環境裡有本包的 ai-review：把計畫存成暫存檔，用完整路徑呼叫（別打裸命令名）<ai-review skill 目錄>/scripts/ai-review.sh <計畫檔> --rubric research --context "<這個任務要解什麼>"，回 skipped_*／failed_* 就照舊自審並明講「本次僅自審」。
⚠️ 送審前先想資料界線：計畫裡常帶著人名、客戶名、內部路徑、卡號。送給外部模型前去識別化（換成〔角色〕〔專案〕這類佔位符），路徑與檔名也算資料，別以為只送內容就安全。送了什麼在回報裡明講。
有任務系統的（待辦、看板、卡片），第 0 步的「先查」與空手觸發的「從待辦挑」就查那裡；第 5 步的 prompt 落點也可以直接掛在那張卡上，下次接手的人打開那張卡，全文就在。