Elephant goldfish

🐘🐟 大象金魚開發模式 (Elephant & Goldfish Pattern)

📌 Overview

本 Skill 實現了規範化 AI 軟體工程的「大象金魚模式」。 透過將任務嚴格拆分為 大象（Coordinator，具備全貌記憶與協調能力） 與 金魚（Coder/Reviewer/Tester，無上下文包袱、執行單一任務的無記憶 Sub-Agent），確保軟體開發的高品質與客觀驗證。

---

🔲 職責邊界

本 Skill 負責大象金魚機制本身，不涵蓋整個開發生命週期。 以下為原始方法論的五個階段，以及本 Skill 的涵蓋範圍：

階段	本 Skill	說明
① 定義需求	邊界外	人類職責
② 需求釐清	邊界外（定義契約）	各工具自行搭配，見 cuj-workflow.md 步驟 2 對照表
③ 產生 CUJ	✅ 核心	CUJ 範本 + validate_cuj.py 客觀驗證
④ 開發	✅ 核心	四角色分離 + 派發 prompt 範本
⑤ Post-mortem	邊界外	各工具原生機制（如 Claude Code 的 memory）

這樣切分是刻意的：一個 Skill 只做一件事。 需求釐清、學習沉澱都有成熟的獨立 skill 可搭配，重造沒有價值。

---

⚙️ 前置需求

項目	需求
執行 scripts/validate_cuj.py	Python 3.12+
執行 scripts/install.py	Python 3.12+
執行 Skill 自我測試	pytest

⚠️ 上述為 Skill 本身的執行需求，與使用本 Skill 的專案技術棧無關。

---

🎯 核心原則

1. 金魚測試標準：一個全新的子代理（金魚），僅憑 CUJ 文件，就能獨立完成 說明 → 實作 → 測試 全流程。
2. 角色嚴格分離：寫程式的人（Coder）不能批改自己的考卷（Tester/Reviewer）。
3. 規格 + 測試：CUJ 定義「要什麼」，測試證明「拿到了」。兩者缺一，CUJ 就退化成寫給人看的文件，而非金魚的可執行契約。
4. 信任 Script，不只信任 Markdown：使用獨立腳本（scripts/validate_cuj.py）進行客觀的自動化檢查。

---

🚀 流程與導引

當本 Skill 被觸發時，請依序執行以下步驟：

Step 1: 閱讀詳細規範 (按需讀取 Level 3 參考資料)

• references/role-separation.md — 四角色權責邊界、跨工具子代理對照表、Anti-Rationalization 表
• references/cuj-workflow.md — CUJ 驅動開發 8 大步驟與釐清階段契約
• references/dispatch-prompts.md — 三份派發 prompt 範本（派發前必讀）

Step 2: 創建 CUJ 文件

• 使用 assets/cuj-template.md 格式在專案 cuj/ 目錄下建立 CUJ 檔（如 cuj/cuj-001-login.md）。
• 參考 assets/cuj-001-user-login.md 了解合格 CUJ 的標準。

Step 3: 驗證 CUJ 文件品質

• 執行驗證腳本：

  python .agent-skills/elephant-goldfish/scripts/validate_cuj.py <cuj-filepath-or-dir>
  

• exit code 0 才可進入下一步；非 0 表示 CUJ 尚未達到金魚可用的標準。
• ⚠️ 摘要行的 跳過 不等於 通過，請確認 通過 的數字。

Step 4: 召喚金魚 Sub-Agents 執行開發與測試

派發前務必先讀 references/dispatch-prompts.md 的「❌ 不可包含」清單。

• 派發 Coder 進行程式碼實作。
• 派發獨立的 Tester 進行 pytest / 單元測試驗證。
• 派發獨立的 Reviewer 進行審查。

---

🛑 Anti-Rationalization & Red Flags

• ❌ 絕對禁止 Coordinator（主 Agent）親自編寫超過 10 行的改動或親自執行測試命令。
• ❌ 絕對禁止 將 Coder 的實作脈絡直接複製給 Tester，Tester 必須在乾淨上下文下依據 CUJ 驗收標準進行獨立測試。
• ❌ 絕對禁止 因為驗證腳本印出 ✅ 就認定通過 —— 請確認摘要行的 passed 數，skipped 不等於通過。