feat(contributors): add fishtvlvoe - 10 lessons on multi-agent delegation and SDD workflow

_data/contributors.yml

@@ -10,3 +10,12 @@
   uses_claude_for: [文章撰寫, 全端開發, 自動化腳本, SEO 優化, WordPress 管理, 靜態網站建置]
   lessons: 25
   topics: [token效率, 診斷流程, 自動化除錯, 覆蓋風險, 驗證流程, 資料庫操作, 平行操作, CSS對比度, Jekyll配置, 前端除錯]
+
+- username: fishtvlvoe
+  name: Fish（老魚）
+  role: 一人公司 / 獨立開發者
+  work: 開發 BuyGo 電商管理系統（WordPress 外掛 SaaS）
+  stack: [WordPress, PHP, Next.js, Supabase, Claude Code, 多模型協作框架]
+  uses_claude_for: [外掛開發, 多模型Agent協作, 自動化腳本, SDD規格驅動開發, 系統架構設計]
+  lessons: 10
+  topics: [工具降級策略, 任務回報流程, debug方法論, 推測標注, 操作確認, 代碼外包, 自動化原則, SDD流程, Spectra工作流, 多模型路由]

contributors/fishtvlvoe/001-fallback-before-giving-up.md

@@ -0,0 +1,40 @@
+---
+layout: default
+title: "工具不通先找替代，不說「沒辦法」"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/001-fallback-before-giving-up/
+---
+
+# 工具不通先找替代，不說「沒辦法」
+
+## 問題
+
+當某個 API key 過期、工具指令失敗、或服務暫時不可用，Claude 的第一反應常常是直接告訴用戶「X 不能用」，然後停下來等指示。
+
+這讓用戶必須自己去排查：key 在哪裡、有沒有備用方案、要怎麼繼續。本來 Claude 應該幫忙搞定的事，卻變成用戶的工作。
+
+## 原因
+
+Claude 的預設行為是「誠實回報障礙」，認為告知用戶是負責任的行為。但在工具豐富的開發環境（多個模型、多個 API provider、`.env` 有多個 key），其實有很多替代方案可以靜默嘗試。
+
+另一個常見問題：Claude 說某個工具「不存在」或「不能用」，但根本沒有執行 `which <tool>` 確認，只是憑記憶猜測。
+
+## 解決方案
+
+1. 說「X 不能用」之前，先執行 `which X` 確認
+2. 讀 `.env` 找替代 provider（例如有 OPENAI_KEY 壞了，找 ANTHROPIC_KEY 或 GEMINI_KEY）
+3. 靜默嘗試 B → C → D 方案，全部失敗才回報，並說明「試了哪些方案」
+4. 禁止中途打斷用戶要求確認
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 工具失敗處理
+
+- 說「X 不能用」前必須先 `which X` 確認
+- 工具失敗時靜默嘗試替代方案（B/C/D），全部失敗才回報
+- 回報時說明「我試了 A/B/C，都失敗了，原因是 X」
+- 禁止中途打斷用戶要求確認替代方案
+- 讀 .env 找備用 API key，不要假設只有一個 provider
+```

contributors/fishtvlvoe/002-report-without-being-asked.md

@@ -0,0 +1,51 @@
+---
+layout: default
+title: "任務完成主動報結果，不等被問"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/002-report-without-being-asked/
+---
+
+# 任務完成主動報結果，不等被問
+
+## 問題
+
+Claude 跑完測試、部署完成、或 commit 之後，沉默等待用戶問「結果怎樣？」
+
+用戶不知道是卡住了、還在跑、還是已經完成，產生不必要的焦慮，也打斷了用戶的節奏。
+
+## 原因
+
+Claude 可能認為「任務執行完畢」已經是明確的訊號，不需要多說。但用戶的注意力在其他地方，沒有主動回報等於沒有完成。
+
+更糟糕的情況：Claude 說「完成」但沒有附上任何可驗證的資訊（commit hash、測試結果數字、URL），用戶無法確認是真的完成還是表演完成。
+
+## 解決方案
+
+任何有明確產出的任務完成後，立刻回報：
+- 測試：分別報告單元測試和 e2e 測試的通過/失敗數
+- commit：給 hash
+- 部署：給 URL
+- 分析：給結論（不只說「分析完了」）
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 任務完成回報格式
+
+Phase 完成後直接說結果，不等問。格式：
+
+測試：
+✅ Unit Tests: 24/24 pass
+✅ E2E Tests: 8/8 pass
+
+版控：
+Commit: a3c2f1e（feat: 加入 X 功能）
+Branch: feature/xxx
+
+部署（如適用）：
+URL: https://staging.example.com
+環境: staging（非 production）
+
+不要說「完成了」然後就停，必須附可驗證的資訊。
+```

contributors/fishtvlvoe/003-diagnose-first-system.md

@@ -0,0 +1,49 @@
+---
+layout: default
+title: "先診斷再動手，不要猜"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/003-diagnose-first-system/
+---
+
+# 先診斷再動手，不要猜
+
+## 問題
+
+遇到 bug，Claude 直接猜一個「最可能的原因」然後動手改。改完不對，再猜一個，再改。這種「猜測式 debug」最糟糕的情況是連改 6 次都沒找到根因。
+
+每次嘗試都消耗 token、修改代碼、可能引入新 bug，最後用戶對整個問題更困惑。
+
+## 原因
+
+Claude 傾向給出快速答案，而不是系統性收集證據。「可能是 A」比「我需要先讀 3 個檔案才能判斷」感覺更有效率，但實際上相反。
+
+## 解決方案
+
+Bug 流程的正確順序：
+1. 蒐集線索（錯誤訊息、log、相關代碼）
+2. 列出 2-3 個可能原因（不要只猜一個）
+3. 工具逐一排除（用代碼事實，不用感覺）
+4. 確定根因後一次修復
+5. 自己驗證（不叫用戶試試看）
+6. 才告知結果
+
+如果修完還是不對，重新從步驟 1 開始，不要在錯誤方向繼續疊 patch。
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## Debug 流程（強制）
+
+Bug 流程：
+1. 蒐集線索 → 讀 error message、log、相關代碼
+2. 列原因 → 寫出 2-3 個假設，不只猜一個
+3. 工具排除 → 用 grep/read/bash 驗證每個假設
+4. 確定根因 → 只有確定了才動手
+5. 一次修復 → 不疊 patch
+6. 自驗 → 自己跑測試確認
+7. 才告知 → 附可驗證的結果
+
+禁止：連猜帶改超過 2 次不換策略
+禁止：下結論前不問「如果這是錯的，什麼證據能推翻？」
+```

contributors/fishtvlvoe/004-verify-before-speaking.md

@@ -0,0 +1,46 @@
+---
+layout: default
+title: "不確定的事自己查完再說，不叫用戶試試看"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/004-verify-before-speaking/
+---
+
+# 不確定的事自己查完再說，不叫用戶試試看
+
+## 問題
+
+Claude 不確定某個 API 的行為、某個功能是否存在、或某個設定是否有效，就說「你可以試試看 X」，把驗證工作推給用戶。
+
+用戶去試了，可能失敗，可能成功，但整個過程是在幫 Claude 做它自己應該做的事。
+
+## 原因
+
+說「試試看」比「我來查」感覺更尊重用戶的決定，但實際上是迴避不確定性。Claude 應該用工具自行驗證，不應該讓用戶成為測試工具。
+
+另一個情況：推測和事實混在一起說，用戶分不清哪些是確定的，哪些是猜的。
+
+## 解決方案
+
+不確定的事情有幾種正確處理方式：
+1. 查文件（用 gemini CLI 或 WebFetch）
+2. 讀現有代碼推論
+3. 寫測試驗證
+4. 如果以上都做不到，明確標註「這是推測，還沒驗證」
+
+禁止的行為：說「你試試看」然後等用戶回報。
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 不確定性處理
+
+- 不確定的事自己查完再說，禁止叫用戶「試試看」代勞驗證
+- 推測必須標註「這是推測，還沒驗證」
+- 已驗證的結論明確說「已確認：X」
+- 下結論前自問「如果這是錯的，什麼證據能推翻？」
+
+格式範例：
+推測（未驗證）: 可能是 timeout 設定問題
+已驗證: curl 測試確認回應時間 > 30s，需調整 timeout 到 60s
+```

contributors/fishtvlvoe/005-confirm-before-executing.md

@@ -0,0 +1,47 @@
+---
+layout: default
+title: "編輯和部署前確認路徑、branch、環境"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/005-confirm-before-executing/
+---
+
+# 編輯和部署前確認路徑、branch、環境
+
+## 問題
+
+Claude 直接開始編輯檔案或執行部署，沒有告訴用戶「我現在要改哪個檔案、在哪個 branch、部署到哪個環境」。
+
+用戶沒有機會說「不對，你搞錯了」，等到改完才發現改錯地方，或部署到了生產環境。
+
+## 原因
+
+Claude 認為自己的推斷是正確的，省略確認步驟讓流程更快。但在多 branch、多環境的開發流程中，一個錯誤的前提會造成無法估量的損失。
+
+## 解決方案
+
+任何涉及以下操作前，外顯告知並等待隱含確認（繼續對話就代表同意）：
+- 編輯檔案：告知路徑和改什麼
+- git 操作：告知 branch 和 commit 內容
+- 部署：告知環境（staging/production）
+
+明確危險的操作（push to production、刪除檔案、force push）需要明確的文字確認。
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 操作前確認（強制）
+
+編輯/部署前告知：
+- 檔案路徑：/Users/fishtv/Development/...
+- 目前 branch：feature/xxx（不是 main）
+- 部署環境：staging（非 production）
+- 變更範圍：N 個檔案，+X -Y 行
+
+需要明確文字確認才能執行的操作：
+- push 到 remote
+- 部署到 production
+- 刪除檔案
+- force push / reset --hard
+- 修改 .env 或設定檔
+```

contributors/fishtvlvoe/006-delegate-code-writing.md

@@ -0,0 +1,55 @@
+---
+layout: default
+title: "超過 5 行代碼就外包給外部 Agent"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/006-delegate-code-writing/
+---
+
+# 超過 5 行代碼就外包給外部 Agent
+
+## 問題
+
+Opus/Sonnet 在主對話親自寫大量代碼，消耗昂貴的 Anthropic token。
+
+寫一個 100 行的函數、重構一個模組、生成測試套件——這些全部由主對話執行，cost 高且效率低。
+
+## 原因
+
+Claude 沒有把「規劃」和「執行」分開。主對話（大腦）的工作是決策和整合，具體的代碼撰寫應該外包給成本更低的外部工具。
+
+在現代多模型協作環境中，有 Copilot CLI、Codex、cursor-agent 可以免費或低成本執行寫碼任務。
+
+## 解決方案
+
+收到寫碼任務，先問：「這要外包給哪個 Agent？」
+
+分工依據：
+- 核心業務邏輯 → Copilot CLI（免費）
+- 需要讀大量 codebase + 改代碼 → Kimi CLI（大 context）
+- 需要跑 shell / 測試驗證 → Codex CLI
+- UI 元件 / scaffold → cursor-agent（零 token）
+- 以上全失敗 → Sonnet 子代理（需說明原因）
+
+主對話只做：規劃、決策、整合結果、1-2 行 hotfix。
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 代碼外包規則（強制）
+
+超過 5 行程式碼 → 停，先問「哪個外部 Agent 最適合？」
+
+分工：
+- 業務邏輯/API/測試 → copilot -p "..." --yolo --model gpt-5.2
+- 需讀大量 codebase 再改 → kimi -p "..." --yolo --print -w <dir>
+- 需跑 shell/測試驗證 → codex exec "..."
+- UI/scaffold → cursor-agent
+- 以上全失敗 → Sonnet 子代理（說明原因）
+
+主對話禁止：
+- 親自寫超過 5 行代碼
+- 親自讀 50+ 行檔案
+- 親自做跨檔重構
+- 看到寫碼任務就反射性動手
+```

contributors/fishtvlvoe/007-automate-repetitive-tasks.md

@@ -0,0 +1,42 @@
+---
+layout: default
+title: "重複操作必須自動化，不手動重複"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/007-automate-repetitive-tasks/
+---
+
+# 重複操作必須自動化，不手動重複
+
+## 問題
+
+需要改 10 個檔案的同一個設定、同步 3 個環境的環境變數、或執行一系列固定步驟，Claude 一個一個手動操作，或者叫用戶自己去手動執行。
+
+這不只效率低，更容易漏掉某個地方，製造不一致。
+
+## 原因
+
+Claude 傾向「最直接的路徑」，直接改 → 下一個 → 繼續改。沒有停下來想「這個操作有沒有規律性？有沒有辦法一次搞定？」
+
+## 解決方案
+
+遇到任何「需要重複改同一件事」的操作，強制問：「這能寫成 script 一次搞定嗎？」
+
+常見可自動化的場景：
+- 批次更新多個檔案的同一段文字 → `sed` 或 Python 腳本
+- 同步環境變數到多個服務 → `vercel env` + `supabase secrets`
+- 重複執行固定指令序列 → Makefile 或 shell script
+- 環境變數 `.env` 改了 → 自動同步到 Vercel/Supabase，不叫用戶手動改
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 自動化原則（強制）
+
+任何「需要重複改同一件事」的操作，必須自動化完成，不問用戶：
+- 批次修改多個檔案 → 寫 script，一次執行
+- 環境變數同步 → 自己用 CLI 同步，不叫用戶手動改
+- 重複執行序列 → 包進 Makefile 或 shell function
+
+vercel env / supabase secrets 操作一律用 CLI，不開瀏覽器，不叫用戶手動執行。
+```

contributors/fishtvlvoe/008-label-assumptions.md

@@ -0,0 +1,48 @@
+---
+layout: default
+title: "推測必須標註「還沒驗證」"
+parent: fishtvlvoe
+grand_parent: 貢獻者
+permalink: /contributors/fishtvlvoe/008-label-assumptions/
+---
+
+# 推測必須標註「還沒驗證」
+
+## 問題
+
+Claude 說出的話混合了「已確認的事實」和「自己的推測」，用戶分不清楚哪些可以信任、哪些需要再驗證。
+
+用戶按照推測去執行，結果失敗，浪費時間，對 Claude 的信任也下降。
+
+## 原因
+
+Claude 在回答時傾向給出「完整」的答案，把推測包裝成確定的語氣，避免讓用戶覺得 Claude 不確定。但這種「假確定」比誠實說「這是推測」更危險。
+
+## 解決方案
+
+明確區分兩種陳述：
+- 推測：「我認為可能是 X，因為 Y」→ 必須標明「這是推測，還沒驗證」
+- 已驗證：「curl 測試確認是 X，已驗證」
+
+計畫和架構討論中，也要走「正推 + 逆推」雙向驗證：
+1. 正推：這樣做成功的路徑是什麼？
+2. 逆推：假設一定會失敗，原因是什麼？
+3. 把逆推發現的風險標注對策
+
+## 可複用的 CLAUDE.md 規則
+
+```markdown
+## 推測標注規則（強制）
+
+- 推測必須標註「這是推測，還沒驗證」
+- 已確認的結論標註「已驗證：X」
+- 下結論前自問「如果這是錯的，什麼證據能推翻？」
+
+計畫必須走雙向驗證（BGO 引擎）：
+1. 正推：成功路徑是什麼？
+2. 逆推：假設失敗，原因是什麼？
+3. 逆推風險寫進計畫，標對策或砍掉
+
+適用：技術架構、API 設計、功能規格
+不適用：1-2 行 hotfix、純格式調整
+```