Menu
檢查並修復 .spec/{slug}/plan.md 的程式碼錨點漂移 —— 機械型自動修、語意型逐條請使用者確認，通過後重新蓋章 verified_at_commit。當使用者提到 /plan-drift、「檢查文件漂移」、「plan.md 錨點失效」時觸發此 Skill。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
CREW 環境健診 —— 一次性檢查 CREW 所有必要與選配依賴（Node/Git/Notion MCP/Agent Teams/瀏覽器 MCP/config/專案註冊/CLAUDE.md），列出綠黃紅燈與修法。當使用者提到 /crew-doctor、「CREW 環境健診」、「CREW 為什麼不能用」時觸發此 Skill。
瀏覽與探索已有的 .spec/ 規劃文件 —— 深度閱讀、跨任務比較、模式搜尋。當使用者提到 /plan-browse、「瀏覽 .spec 規劃」、「看之前的規劃設計」時觸發此 Skill。
從 .spec/{slug}/plan.md 以 Agent Teams leader-delegate 模式產生程式碼，含退出驗證與錨點有效性檢查，Leader 只協調不寫 code。當使用者提到 /plan-build、「從 spec 產生程式碼」、「plan-build 產碼」時觸發此 Skill。
結案前先跑文件漂移硬關卡（FAIL 擋、WARN 需明示放行），通過後蓋章 verified_at_commit、提交 Git、批次同步 plan.md 與 deploy.sql 到 Notion。當使用者提到 /plan-close、「feature 結案」、「同步 spec 到 Notion 並結案」時觸發此 Skill。
智慧推薦 CREW 當前任務下一步 —— 呼叫 crew-state.py 讀 state.json 算出下一個 /plan-* 指令並轉成人話。當使用者提到 /plan-next、「CREW 下一步指令」、「這個 spec 接下來做什麼」時觸發此 Skill。
CREW 規劃 —— spec / db / arch 三個 pass 把決策與驗收條件寫進 .spec/{slug}/plan.md，DB 設計另產 deploy.sql（零 Notion 呼叫）。當使用者提到 /plan、「CREW 完整規劃」、「一次跑完 spec/db/arch」時觸發此 Skill。
| name | plan-drift |
| description | 檢查並修復 .spec/{slug}/plan.md 的程式碼錨點漂移 —— 機械型自動修、語意型逐條請使用者確認，通過後重新蓋章 verified_at_commit。當使用者提到 /plan-drift、「檢查文件漂移」、「plan.md 錨點失效」時觸發此 Skill。 |
| argument-hint | [<slug>] [--all] [--fix] |
plan.md 只寫「為什麼」，「是什麼」一律用錨點（@code:path#symbol、@sql:deploy.sql#table）指向程式碼。錨點會隨程式碼變動失效，本 skill 是失效後的修復入口：偵測交給 script，判斷交給使用者，本 skill 只負責串起來。
紀律護欄：
../../references/discipline-preamble.md（通用紀律）。
/plan-drift # 檢查當前活躍任務
/plan-drift <slug> # 檢查指定任務
/plan-drift --all # 檢查專案內所有任務
/plan-drift --fix # 檢查並直接套用機械型自動修
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check-spec-drift.py" --spec .spec/<slug>/plan.md --format json
# --all 模式：
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check-spec-drift.py" --all --format json
走哪個步驟看 JSON 內容，不是看 exit code（INFO 級的 D3 行號位移不影響 exit code，只看 exit 0 會漏掉該修的東西）：
autofixable: true 的項目 → 步驟 2autofixable: false 的 D1–D6 項目 → 步驟 3exit code 決定的是「能不能蓋章」，這點不要自行改判：
| exit | 意義 | 蓋章 |
|---|---|---|
| 0 | 無 FAIL、無 WARN（可能仍有 INFO 待 --fix） | 可以 |
| 1 | 有 FAIL；或 WARN 被 --strict／該份 drift_policy: strict 升級 | 不可 |
| 2 | 只有 WARN | 需使用者逐筆明示放行 |
| 3 | 環境問題（非 git 工作區、verified_at_commit 不在歷史、檔案讀不到） | 不可 |
level：一個 FAIL 都沒有就是 WARN 被升級（--strict 或 drift_policy: strict），照步驟 3 處理語意型即可，不要去找不存在的 FAIL。JSON 陣列每筆含 code／level／spec／line／anchor／detail／fix／autofixable。level 為 ENV（code = E1）的項目一律歸「無法檢查」；它可能與 FAIL 並存（此時 exit 為 1），所以每次都要掃有無 ENV 項目，不能只看 exit code。
判準只有一個：autofixable 為 true（目前是 D1 偵測到 git -M 改名、D3 行號位移）。不要用自己記的碼表判斷。
cp .spec/<slug>/plan.md /tmp/plan-before-fix.md
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check-spec-drift.py" --spec .spec/<slug>/plan.md --fix
diff /tmp/plan-before-fix.md .spec/<slug>/plan.md
用上面的 diff 取回實際改動（不要用 git diff：.spec/ 預設被 gitignore、plan.md 到 /plan-close 才 git add -f，git diff 會是空的而讓你誤判沒修到）。逐條回報「錨點 X：舊路徑 → 新路徑」「行號提示 L88 → L102」。沒出現在 diff 輸出裡的就不准說已修好。
autofixable 為 false 的全部歸這裡（D2 符號不在檔內、D4 hash 不符、D5 @sql: 表對不上、D6 文件落後程式碼、D7 缺錨點／缺蓋章）。對每一筆：
detail 列出的變更檔案），確認符號是改名、刪除、還是整個決策已作廢🔴 [D2] .spec/login-lock/plan.md:23 `@code:src/.../LoginAttemptService.java#recordFailure`
檔內找不到 recordFailure。實際看到 recordAttempt(boolean success)（:91）—— 像是改名。
建議：把錨點改指 #recordAttempt
[1] 照建議改錨點 [2] 這個決策已作廢 → 改寫「決策紀錄」那一條 [3] 略過（本次不處理）
符號消失常代表決策變了。 此時該動的是「決策紀錄」章節（用 D-n [階段] 取代 D-m：… supersede，不刪舊條目），不是把指標硬改成能通過檢查 —— 硬改指標會讓文件變成「永遠通過但沒人信」的裝飾。這條沒有使用者確認一律不做。
若使用者判定某筆是誤報，可請他選擇逃生閥（由使用者決定，不要自己塞）：
<!-- drift-ignore: D2 reason=已改用新介面 -->（reason 必填）drift_policy: off（代價：該份文件此後完全不檢查）條件：重跑檢查得到 exit 0，或 exit 2 且每筆 WARN 都經使用者明示放行。exit 1 或有 ENV 項目 → 不蓋章。
git rev-parse --short HEAD
用 Edit 更新 .spec/<slug>/plan.md frontmatter 兩個欄位（只改這兩行）：
verified_at_commit: 3f2a91c
verified_at: 2026-07-28
日期用 date +%F 的實際輸出，不要憑印象填。
🔍 漂移檢查：login-lock（.spec/login-lock/plan.md）
🔧 已自動修（機械型）2 筆
• L23 錨點路徑 LoginAttemptService.java → service/LoginAttemptService.java（git 改名）
• L31 行號提示 L88 → L102
📝 已確認修正（語意型）1 筆
• L45 D-3 標記為由 D-7 取代（決策已變：改走 Redis 計數）
⏭️ 使用者放行的 WARN 1 筆
• [D6] 錨點檔案自 3f2a91c 後有變更 —— 使用者確認變更不影響決策
✅ 重跑檢查 exit 0 → 已蓋章 verified_at_commit: a91c3f2
--all 模式逐任務印上述摘要，並在最後給總計；每份任務的蓋章各自獨立判定。
drift_policy: off 的任務是「沒檢查」：script 會在總結明示未檢查份數，回報時不得寫成「全部通過」。verified_at_commit 只有本 skill 與 /plan-close 能寫，且必須在檢查真的乾淨之後。剛改完程式碼就蓋章等於自己給自己蓋合格章。--fix 只動 plan.md：它不會改程式碼。若使用者要的是「把程式碼改回文件寫的樣子」，那是 /plan-build 的工作，先問清楚。.spec/*/plan.md：script 回 exit 0 並印「找不到任何 plan.md」→ 回報無可檢查對象，提示 /plan-start.spec/ 被 gitignore 且 plan.md 未進 git：D6 會靜默（無從比對時間先後），這是刻意設計，不是漏檢