💡 核心理念：
BMAD 不只是一套工具，而是一種「人類與 AI 協作」的思維模式。
它讓 AI 成為團隊中的專業成員，而非單純的程式碼產生器。

✨ 規模-領域自適應智能
   └─ 自動判斷專案複雜度、領域與類型，選擇適當的流程深度
   
✨ 專業化代理團隊
   └─ 12+ 個核心代理，各司其職，協同合作
   
✨ Skills 架構（IDE 原生整合）
   └─ 每個代理、工作流程、任務都是一個 IDE Skill，直接輸入名稱即可調用
   
✨ IDE 無縫整合
   └─ 支援 Claude Code、Cursor、Codex CLI、Kiro、VS Code 等
   
✨ AI 智慧引導
   └─ `bmad-help` 從安裝到完成全程引導
   
✨ Party Mode
   └─ 將多個代理帶入同一對話，協作求解
   
✨ 完全模組化
   └─ 透過 BMad Builder 自訂代理、工作流程、模組，支援 npm 發佈

📊 Analysis 階段核心活動
│
├── 1. 腦力激盪（Brainstorm Project）
│   ├── 探索專案點子
│   ├── 定義產品願景
│   └── 初步可行性評估
│
├── 2. 研究探索（Research）
│   ├── 領域研究
│   ├── 市場研究
│   └── 技術研究
│
├── 3. 建立產品簡介（Create Brief）
│   ├── 撰寫 Product Brief
│   ├── 定義問題陳述
│   └── 設定成功標準
│
└── 4. 記錄現有專案（Document Project）
    ├── 記錄專案上下文
    ├── 整理現有架構
    └── 標示改進機會

� Planning 階段核心活動
│
├── 1. 建立 PRD（Create PRD）
│   ├── 功能需求定義
│   ├── 使用者故事撰寫
│   └── 驗收標準設定
│
├── 2. 驗證 PRD（Validate PRD）
│   ├── 需求完整性檢查
│   ├── 一致性驗證
│   └── 利害關係人確認
│
├── 3. UX 設計（Create UX Design）
│   ├── 使用者流程設計
│   ├── 介面原型
│   └── 互動設計
│
└── 4. Quick Spec（Quick Flow 專用）
    ├── 簡化技術規格
    ├── 快速需求定義
    └── 直接進入開發

🏗️ Solutioning 階段核心活動
│
├── 1. 架構設計（Create Architecture）
│   ├── 架構風格選擇
│   ├── 技術棧決策
│   └── 模組劃分與介面設計
│
├── 2. Epic 與 Story 建立（Create Epics and Stories）
│   ├── PRD 拆分為 Epic
│   ├── Epic 拆分為 Story
│   └── 依賴關係分析
│
├── 3. 實作準備度檢查（Implementation Readiness）
│   ├── 規劃一致性驗證
│   ├── 技術可行性確認
│   └── Story 完整性檢查
│
└── 4. 架構決策記錄
    ├── ADR 文件建立
    ├── 技術方案比較
    └── 非功能需求處理

⚡ Implementation 階段核心活動
│
├── 1. Sprint 規劃與管理
│   ├── Sprint Planning（初始化追蹤）
│   ├── Story 檔案建立
│   └── 優先順序排定
│
├── 2. Story 開發
│   ├── Dev Story（逐一實作）
│   ├── 程式碼撰寫
│   └── Code Review
│
├── 3. 測試與品質
│   ├── QA 自動化測試
│   ├── 持續整合驗證
│   └── 品質標準檢查
│
└── 4. 範圍管理
    ├── Correct Course（範圍變更處理）
    ├── Story 調整與重排
    └── 迭代回饋收集

# 步驟 1：確認 Node.js 版本
node --version  # 需要 v20 以上

# 步驟 2：進入專案目錄
cd your-project

# 步驟 3：執行安裝
npx bmad-method install

# 安裝過程會引導你選擇：
# 1. 目標 IDE（Claude Code / Cursor / Codex CLI / Kiro 等）
# 2. 要安裝的模組（BMM、BMB、CIS、GDS、TEA）
# 3. 配置選項

📁 your-project/
├── 📂 _bmad/                          # BMAD 核心資料夾
│   ├── 📂 agents/                     # AI 代理定義檔
│   ├── 📂 workflows/                  # 工作流程定義
│   ├── 📂 checklists/                 # 檢查清單
│   ├── 📂 templates/                  # 文件範本
│   ├── 📂 tasks/                      # 獨立任務定義
│   ├── 📂 tools/                      # 工具定義
│   └── 📄 project-context.md          # 專案上下文（自動產生或手動建立）
├── 📂 _bmad-output/                   # BMAD 產出物資料夾
│   ├── 📂 planning-artifacts/         # 規劃階段產出
│   │   ├── 📄 product-brief.md        # 產品簡介
│   │   ├── 📄 prd.md                  # 產品需求文件
│   │   ├── 📄 ux-design.md            # UX 設計
│   │   └── 📄 architecture.md         # 架構設計文件
│   └── 📂 implementation-artifacts/   # 實作階段產出
│       ├── 📄 epic-*.md               # Epic 與 Story 檔案
│       ├── 📄 sprint-backlog.md       # Sprint 追蹤
│       └── 📄 story-*.md              # 個別 Story 檔案
├── 📂 .claude/skills/                 # Skills 檔案（Claude Code 範例）
│   ├── 📂 bmad-help/
│   │   └── 📄 SKILL.md
│   ├── 📂 bmad-create-prd/
│   │   └── 📄 SKILL.md
│   ├── 📂 bmad-dev/
│   │   └── 📄 SKILL.md
│   └── ...
└── 📄 （你的專案檔案）

bmad-help

# bmad-help 會：
# 1. 檢視你的專案狀態（已有哪些產出物）
# 2. 推薦適合的下一步行動
# 3. 根據已安裝的模組顯示可用選項
# 4. 理解自然語言提問，解答任何 BMAD 相關問題

💡 何時使用 Skill vs Trigger？

使用 Skill 當...
├── 你知道要執行哪個工作流程
├── 你想直接啟動某個代理
└── 你不在任何代理對話中

使用 Agent Menu Trigger 當...
├── 你已經在與某個代理對話
├── 你想在同一對話中切換任務
└── 你想保持代理角色持續性

💡 Skills 的核心概念：

Skill ≠ Slash Command

在 v6 之前，BMAD 使用 slash commands（如 /bmad-bmm-create-prd）。
v6 開始，所有互動都透過 Skills 進行：
- 不需要 "/" 前綴
- 不需要 "bmm" 中綴
- 直接輸入 skill 名稱即可（如 bmad-create-prd）

📂 .claude/skills/          # Claude Code 範例
├── 📂 bmad-help/
│   └── 📄 SKILL.md         # "載入 _bmad/tasks/bmad-help.md 並執行"
├── 📂 bmad-dev/
│   └── 📄 SKILL.md         # "載入 _bmad/agents/developer.md 並維持角色"
├── 📂 bmad-create-prd/
│   └── 📄 SKILL.md         # "載入 _bmad/workflows/create-prd.yml 並執行"
├── 📂 bmad-shard-doc/
│   └── 📄 SKILL.md         # "載入 _bmad/tasks/shard-doc.md 並執行"
└── ...

使用者輸入：bmad-pm              ← 載入 PM Agent (John)

John 回應：
  我是 John，你的產品經理。以下是我可以協助你的工作：
  
  CP - Create PRD（建立產品需求文件）
  VP - Validate PRD（驗證 PRD）
  EP - Edit PRD（編輯 PRD）
  CE - Create Epics and Stories（建立 Epic 與 Story）
  IR - Implementation Readiness（實作準備度檢查）
  CC - Correct Course（範圍變更處理）
  
  請問需要我執行哪項工作？

使用者輸入：CP                   ← 觸發 Create PRD 工作流程

John 開始：好的，讓我們開始建立 PRD...

使用者輸入：bmad-tech-writer      ← 載入 Tech Writer Agent (Paige)
使用者輸入：WD 撰寫一份 Docker 部署指南
使用者輸入：MG 建立一個顯示認證流程的序列圖
使用者輸入：EC 解釋模組系統如何運作

📁 _bmad/
└── 📄 project-context.md    # 專案上下文概覽

# 方式一：自動產生
bmad-generate-project-context

# 方式二：手動建立
在 _bmad/ 目錄下建立 project-context.md

# 方式三：Document Project 工作流程
使用 Analyst (Mary) 的 DP trigger 記錄現有專案

📦 bmad-method（BMM 核心模組）
├── 📂 agents/          ← 9 個核心代理定義
│   ├── analyst.md          # Mary — 分析師
│   ├── pm.md               # John — 產品經理
│   ├── architect.md        # Winston — 架構師
│   ├── developer.md        # Amelia — 開發者
│   ├── ux-designer.md      # Sally — UX 設計師
│   ├── scrum-master.md     # Bob — Scrum Master
│   ├── tech-writer.md      # Paige — 技術文件撰寫者
│   ├── qa.md               # Quinn — QA 工程師
│   └── master.md           # Barry — Quick-Flow Solo Dev
├── 📂 workflows/       ← 34+ 個工作流程定義
│   ├── create-prd.yml
│   ├── create-architecture.yml
│   ├── create-epics-and-stories.yml
│   ├── dev-story.yml
│   ├── code-review.yml
│   └── ...
├── 📂 checklists/      ← 驗證檢查清單
├── 📂 templates/       ← 文件範本
├── 📂 tasks/           ← 獨立任務定義
└── 📂 tools/           ← 工具定義

📦 bmad-builder（BMB 建造者模組）
├── 🤖 Agent Builder     ← 建立自定義代理
├── 🔄 Workflow Builder  ← 建立自定義工作流程
└── 📦 Module Builder    ← 打包為可分享的模組

使用者：bmad-agent-builder

Builder：好的，讓我們建立一個新的代理。請告訴我：
1. 代理名稱？
2. 角色描述？
3. 專長領域？
4. 核心工作流程？

使用者：
1. Security Reviewer
2. 負責審查系統安全設計
3. OWASP、資安合規、滲透測試
4. Security-Review、Threat-Modeling

Builder：正在建立代理定義檔...
✅ agents/security-reviewer.md 已建立
✅ workflows/security-review.yml 已建立
✅ workflows/threat-modeling.yml 已建立
✅ skills/bmad-security-reviewer/ 已建立

# 安裝 CIS 模組
npx bmad-creative-intelligence-suite install

# 安裝 GDS 模組
npx bmad-game-dev-studio install

# 安裝 TEA 模組
npx bmad-method-test-architecture-enterprise install

🚦 升級信號

以下情況建議從 Quick Flow 升級為完整 BMad Method：

🔴 必須升級：
├── 需要修改 3+ 個模組
├── 涉及資料庫 schema 變更
├── 需要多人協作
└── 有安全/合規要求

🟡 建議升級：
├── 工作量超過 1 天
├── 需求不夠明確
├── 涉及外部系統整合
└── 需要 UX 設計

🟢 繼續 Quick Flow：
├── Bug 修復
├── 文案修改
├── 簡單功能添加
└── 技術方案已明確

# Step 1：載入 Scrum Master，進行 Sprint 規劃
bmad-sm
使用者：SP
Bob：根據 Epic 優先級，建議的 Sprint Backlog 如下：
  Story CC-001: 基本資料填寫表單 (3 pts)
  Story CC-002: 上傳身分證照片 (2 pts)
  Story CC-003: eKYC 身分驗證整合 (5 pts)
  
使用者：確認，開始 CC-001

# Step 2：切換到 Developer，開始 Story 開發
bmad-dev
使用者：DS（Dev Story 工作流程）
Amelia：好的，我來規劃 CC-001 的實作方案...
  ├── 建立 React 表單元件
  ├── 實作表單驗證邏輯
  ├── 建立 API 端點
  └── 撰寫單元測試

使用者：開始實作
Amelia：[產出程式碼]

# Step 3：測試
bmad-qa
Quinn：讓我為 CC-001 建立測試計畫...
  ├── 表單欄位驗證測試
  ├── API 端點測試
  └── 整合測試

# Step 4：程式碼審查
bmad-dev
使用者：CR（Code Review）
Amelia：審查結果：
  ✅ 程式碼結構良好
  ⚠️ 建議：新增 XSS 防護
  ✅ 測試覆蓋率：85%
  
# Step 5：完成 Story，回到 Sprint
bmad-sm
使用者：更新 CC-001 為完成
Bob：CC-001 已標記完成。Sprint 進度：1/3 Stories 完成。
  下一個建議：CC-002（上傳身分證照片）

bmad-sm
使用者：SS（Sprint Status）

Bob：📊 Sprint 5 狀態報告
━━━━━━━━━━━━━━━━━━━━━━━━
進度：4/8 Stories 完成 (50%)
速率：12 pts 已完成 / 24 pts 規劃
剩餘天數：5 天

Story 狀態：
✅ CC-001 基本資料表單 (3 pts) — 完成
✅ CC-002 上傳身分證 (2 pts) — 完成
✅ CC-003 eKYC 整合 (5 pts) — 完成
✅ CC-004 查詢進度 (2 pts) — 完成
🔄 CC-005 聯徵查詢 (5 pts) — 進行中
📋 CC-006 信用評分 (3 pts) — 待辦
📋 CC-007 核准通知 (2 pts) — 待辦
📋 CC-008 婉拒通知 (2 pts) — 待辦

⚠️ 風險：CC-005 聯徵整合遇到 API 延遲問題
建議：考慮將 CC-007 和 CC-008 合併處理

bmad-sm
使用者：ER（Epic Retrospective）

Bob：📋 Epic CC 回顧報告
━━━━━━━━━━━━━━━━━━━━━━━━

🟢 做得好的：
├── PRD 定義明確，減少返工
├── 架構設計選型正確
└── Dev Loop 執行順暢

🔴 需要改進的：
├── 聯徵 API 整合測試不足
├── UX 審核太晚介入
└── 部分 Story 估算偏低

📊 數據摘要：
├── 計畫 Story Points：24
├── 實際 Story Points：28 (+17%)
├── Sprint 數量：4
└── Bug 數量：3（已修復）

💡 行動項目：
├── 建立外部 API 整合測試規範
├── UX 審核前移至 Solutioning 階段
└── 改善估算校準流程

bmad-pm
使用者：CC（Correct Course）

John：📋 範圍變更評估
━━━━━━━━━━━━━━━━━━━━━━━━
請描述變更需求。

使用者：業務單位要求新增「共同申請人」功能

John：讓我評估此變更的影響...

📋 變更影響分析：

影響範圍：
├── PRD：需新增 Section 4.5
├── 架構：資料模型需變更
├── Epic CC：需新增 3 個 Story
└── 測試：需更新整合測試

工作量估算：
├── 分析/規劃：0.5 天
├── 架構調整：1 天
├── 開發實作：3 天
├── 測試驗證：1 天
└── 總計：5.5 天

建議選項：
A. 加入當前 Sprint（延後 CC-007, CC-008）
B. 排入下一個 Sprint
C. 建立獨立 Epic 處理

請選擇或提供替代方案。

bmad-generate-project-context

AI：正在掃描專案結構...

📄 project-context.md 已產生

包含內容：
├── 📂 專案結構摘要（18 個主要目錄、142 個檔案）
├── 🛠️ 技術棧（React 18、Spring Boot 3.2、PostgreSQL 15）
├── 📡 API 端點摘要（32 個端點、5 個控制器）
├── 📊 資料模型摘要（12 個實體、8 個關係）
├── 🔧 建構指令（Maven build、Docker compose）
├── 📝 團隊約定（命名慣例、程式碼風格）
└── 📋 現有文件索引

🤔 如何選擇適合的流程？

執行 bmad-help，讓 BMAD 自動分析你的專案目標！

或者參考以下指引：

📌 選擇 Quick Flow 當...
   ├── 修復明確的 Bug
   ├── 新增簡單功能（< 1 天工作量）
   └── 技術方案已經明確

📌 選擇 BMad Method 當...
   ├── 開發新產品或新模組
   ├── 需要跨團隊協作
   └── 需求尚需釐清

📌 選擇 Enterprise 當...
   ├── 金融、醫療等合規產業
   ├── 影響範圍廣（> 10 個系統）
   └── 需要正式審查流程

📋 Enterprise Quality Gates

Gate 1：Analysis → Planning
├── Product Brief 已獲利害關係人核准
├── 研究報告已完成
└── 風險初步評估已完成

Gate 2：Planning → Solutioning
├── PRD 已通過驗證（VP）
├── 合規需求已確認
├── UX 設計已核准
└── 預算已獲批准

Gate 3：Solutioning → Implementation
├── 架構設計已通過技術審查
├── 安全設計已通過資安審查
├── 實作準備度檢查已通過（IR）
└── Epic/Story 拆分已確認

Gate 4：Implementation → 上線
├── 所有 Story 已完成
├── 測試覆蓋率達標
├── Code Review 全數通過
├── 合規審查已通過
├── 資安審查已通過
├── 效能測試已通過
└── DR 演練已完成

📁 BMAD 專案產出物結構
│
├── 📂 _bmad/                          # BMAD 核心設定（安裝時產生）
│   ├── 📂 agents/                     # AI 代理定義
│   ├── 📂 workflows/                  # 工作流程定義
│   ├── 📂 checklists/                 # 檢查清單
│   ├── 📂 templates/                  # 文件範本
│   ├── 📂 tasks/                      # 獨立任務
│   ├── 📂 tools/                      # 工具定義
│   └── 📄 project-context.md          # 專案上下文
│
├── 📂 _bmad-output/                   # BMAD 產出物
│   ├── 📂 planning-artifacts/         # 規劃階段產出
│   │   ├── 📄 product-brief.md        # 產品簡介（Analysis）
│   │   ├── 📄 prd.md                  # 產品需求文件（Planning）
│   │   ├── 📄 ux-design.md            # UX 設計（Planning）
│   │   └── 📄 architecture.md         # 架構設計（Solutioning）
│   └── 📂 implementation-artifacts/   # 實作階段產出
│       ├── 📄 epic-1.md               # Epic 與 Story（Solutioning）
│       ├── 📄 sprint-backlog.md       # Sprint 追蹤（Implementation）
│       └── 📄 story-*.md              # 個別 Story 檔案
│
└── 📂 src/                            # 程式碼（Implementation）

📌 Analysis 階段新手步驟

步驟 1：收集初始資訊
├── 與 PM/業務單位訪談
├── 收集現有文件（需求單、會議紀錄）
└── 了解背景脈絡

步驟 2：與 Analyst Agent (Mary) 互動
├── 使用 `BP`（Brainstorm Project）腦力激盪
├── 使用 `RS`（Research）進行研究
└── 回答 AI 的澄清問題

步驟 3：產出 Product Brief
├── 使用 `CB`（Create Brief）建立產品簡介
├── 定義「現況」與「期望」的差距
└── 獲得利害關係人認可

步驟 4：記錄專案上下文（Brownfield 專案）
├── 使用 `DP`（Document Project）記錄現有系統
├── 整理現有架構與限制
└── 確認改進機會

💡 與 Analyst Agent (Mary) 協作技巧

1. **使用 `BP` 啟動腦力激盪**
   - 描述專案點子
   - 讓 Mary 協助探索可能性
   - 討論可行性與風險

2. **使用 `RS` 進行深入研究**
   - 指定研究領域（市場、技術、競品）
   - 讓 AI 協助整理研究結果

3. **使用 `CB` 建立產品簡介**
   - 提供背景資訊
   - 讓 AI 產生結構化的 Product Brief
   - 確認並調整內容

4. **迭代優化**
   - 第一版不完美是正常的
   - 多次互動直到滿意

📌 Planning 階段新手步驟

步驟 1：建立 PRD
├── 使用 `bmad-create-prd` 讓 PM (John) 協助
├── 定義功能需求與使用者故事
├── 設定驗收標準
└── 確認優先級排序

步驟 2：驗證 PRD
├── 使用 `VP`（Validate PRD）檢查完整性
├── 確認需求之間無衝突
└── 獲得利害關係人確認

步驟 3：UX 設計（選用）
├── 使用 `bmad-create-ux-design` 讓 UX Designer (Sally) 協助
├── 設計使用者流程
└── 建立介面原型

步驟 4：確認輸出
├── PRD 已經通過驗證
├── 所有需求已明確定義
└── 準備進入 Solutioning 階段

💡 與 PM Agent (John) 協作技巧（Planning 階段）

1. **使用 `bmad-create-prd` 建立 PRD**
   - 提供 Product Brief 作為輸入
   - 讓 PM (John) 協助撰寫完整 PRD
   - 逐步確認功能需求

2. **使用 `VP` 驗證 PRD**
   - 檢查需求完整性
   - 驗證一致性與可行性

3. **使用 UX Designer (Sally) 設計介面**
   - 描述使用者情境
   - 讓 AI 建議 UX 設計
   - 討論使用者流程

4. **迭代優化**
   - 對 PRD 不滿意時使用 `EP`（Edit PRD）修改
   - 確保所有需求都有明確的驗收標準

📌 Solutioning 階段新手步驟

步驟 1：評估架構風格
├── 單體 vs 微服務
├── 同步 vs 非同步
├── 評估團隊能力
└── 考慮維運成本

步驟 2：設計系統架構
├── 繪製架構圖
├── 定義各層職責
├── 規劃部署架構
└── 設計監控策略

步驟 3：進行技術選型
├── 列出候選技術
├── 建立評估矩陣
├── POC 驗證（必要時）
└── 記錄決策理由

步驟 4：設計介面
├── 定義 API 端點
├── 設計請求/回應格式
├── 定義錯誤處理
└── 撰寫 API 文件

步驟 5：處理非功能需求
├── 效能目標與策略
├── 安全設計
├── 可擴展性設計
└── 災難復原計畫

💡 與 Architect Agent 協作技巧

1. **請 AI 提供架構建議**
   - 描述系統需求與限制
   - 請 AI 建議多個架構方案
   - 比較各方案優缺點

2. **請 AI 協助技術選型**
   - 列出評估項目
   - 請 AI 分析各選項
   - 產出決策矩陣

3. **請 AI 審查架構設計**
   - 提供架構圖與說明
   - 請 AI 找出潛在問題
   - 針對問題調整設計

4. **請 AI 協助 API 設計**
   - 描述功能需求
   - 請 AI 建議 API 端點
   - 請 AI 產生 OpenAPI 規格

📌 Implementation 階段新手步驟

步驟 1：拆分 User Stories
├── 依據 PRD 列出所有 Story
├── 估算每個 Story 的工作量
├── 排定優先順序
└── 分配到 Sprint

步驟 2：開發實作
├── 撰寫程式碼
├── 撰寫單元測試
├── 程式碼審查
└── 合併到主分支

步驟 3：測試驗證
├── 執行整合測試
├── 執行 E2E 測試
├── 效能測試
└── 安全測試

步驟 4：部署上線
├── 準備部署腳本
├── 設定環境變數
├── 執行部署
└── 驗證部署結果

步驟 5：交付驗收
├── 準備驗收文件
├── 執行 UAT
├── 教育訓練
└── 正式上線

💡 與 Developer Agent 協作技巧

1. **請 AI 協助拆分 Story**
   - 提供 PRD 內容
   - 請 AI 建議 Story 拆分
   - 討論估算工作量

2. **請 AI 協助撰寫程式碼**
   - 提供 Story 需求與技術規格
   - 請 AI 產生程式碼框架
   - 逐步完善細節

3. **請 AI 撰寫測試**
   - 提供程式碼
   - 請 AI 產生測試案例
   - 確保涵蓋邊界條件

4. **請 AI 審查程式碼**
   - 提供程式碼
   - 請 AI 找出潛在問題
   - 建議改進方案

5. **請 AI 協助寫文件**
   - 提供程式碼與 API
   - 請 AI 產生文件
   - 調整格式與內容

# Prompt：問題定義與需求探索

## 角色
你是一位資深的業務分析師（Analyst Agent），專精於金融業系統分析。

## 背景
[請在此描述專案背景]

例如：
我們是一家商業銀行，目前的信用卡線上申請流程存在以下問題：
- 申請完成率只有 35%
- 客戶抱怨流程太複雜
- 平均申請時間需要 15 分鐘

## 任務
請協助我：
1. 釐清問題的根本原因
2. 定義明確的問題陳述
3. 識別關鍵利害關係人
4. 建議可量測的成功標準

## 輸出格式
請以 Markdown 格式輸出，包含：
- 問題陳述（Problem Statement）
- 根因分析（Root Cause Analysis）
- 利害關係人清單
- 成功標準建議

# Prompt：利害關係人分析

## 角色
你是一位資深的業務分析師，專精於利害關係人管理。

## 專案背景
[描述專案背景]

## 任務
請協助我建立完整的利害關係人分析，包含：
1. 識別所有可能的利害關係人
2. 分析每位利害關係人的：
   - 影響力（高/中/低）
   - 利益程度（高/中/低）
   - 主要關注點
   - 期望與需求
3. 建立利害關係人矩陣
4. 建議溝通策略

## 輸出格式
請以表格方式呈現利害關係人矩陣，並附上溝通策略建議。

# Prompt：需求訪談問題清單

## 角色
你是一位經驗豐富的系統分析師，專精於需求訪談。

## 訪談對象
[描述訪談對象的角色]

例如：
- 業務單位主管
- 第一線客服人員
- IT 部門代表

## 專案背景
[描述專案背景]

## 任務
請產生一份訪談問題清單，問題應該：
1. 能夠挖掘真正的需求（不只是表面需求）
2. 包含開放式與封閉式問題
3. 涵蓋功能需求與非功能需求
4. 針對不同角色客製化

## 輸出格式
請依照訪談對象分組，每組 8-10 個問題，並說明每個問題的目的。

# Prompt：業務流程建模

## 角色
你是一位資深的系統分析師，專精於業務流程分析與建模。

## 業務流程描述
[描述業務流程]

例如：
信用卡申請流程：
1. 客戶在網站填寫基本資料（姓名、身分證字號、聯絡方式）
2. 上傳身分證正反面照片
3. 系統呼叫 eKYC 服務進行身分驗證
4. 若驗證失敗，客戶可選擇人工審核或放棄
5. 驗證成功後，填寫財力證明資料
6. 系統呼叫聯徵中心取得信用分數
7. 根據信用分數決定核准或婉拒
8. 發送通知給客戶

## 任務
請協助我：
1. 繪製業務流程圖（使用 Mermaid 語法）
2. 標示決策點與分支
3. 標示系統邊界（哪些是內部系統、哪些是外部系統）
4. 列出可能的例外流程

## 輸出格式
1. Mermaid 流程圖
2. 流程說明表格
3. 例外處理清單

# Prompt：資料模型設計

## 角色
你是一位資深的資料架構師，專精於關聯式資料庫設計。

## 業務情境
[描述業務情境與需要儲存的資料]

例如：
需要設計一個信用卡申請系統的資料模型，需要儲存：
- 申請人基本資料
- 申請單資訊
- 身分驗證結果
- 信用評分結果
- 審核紀錄

## 任務
請協助我設計資料模型：
1. 識別主要實體（Entity）
2. 定義每個實體的屬性
3. 建立實體之間的關係
4. 產出 ERD（使用 Mermaid erDiagram）
5. 建立資料字典

## 設計考量
- 符合第三正規化（3NF）
- 考慮查詢效能
- 支援未來擴展
- 符合個資保護要求

## 輸出格式
1. Mermaid ERD 圖
2. 資料字典表格
3. 設計決策說明

# Prompt：業務規則定義

## 角色
你是一位資深的業務分析師，專精於業務規則分析與文件化。

## 業務情境
[描述業務情境]

例如：
信用卡申請審核規則：
- 申請人年齡需滿 20 歲
- 需有穩定收入來源
- 信用評分需達 600 分以上
- 若有不良信用紀錄需人工審核

## 任務
請協助我整理並文件化所有業務規則：
1. 識別所有業務規則
2. 將規則分類（驗證規則、計算規則、流程規則）
3. 定義規則的輸入、輸出、邏輯
4. 標示規則的例外處理

## 輸出格式
請以表格方式呈現，包含：
- 規則 ID
- 規則名稱
- 分類
- 規則描述
- 輸入/輸出
- 例外處理

# Prompt：系統架構設計

## 角色
你是一位資深的系統架構師（Architect Agent），擁有 15 年金融業系統架構經驗。

## 專案背景
[描述專案背景與需求]

## 非功能需求
- 效能：API 回應時間 < 500ms（P99）
- 可用性：99.9%
- 安全性：符合金管會資安規範
- 可擴展性：支援 100 TPS 成長到 1000 TPS

## 限制條件
- 公司技術棧：Java Spring Boot、PostgreSQL、Redis
- 部署環境：Kubernetes on AWS
- 團隊規模：5 位後端工程師

## 任務
請協助我設計系統架構：
1. 評估架構風格（單體 vs 微服務）
2. 設計整體架構圖
3. 定義各元件職責
4. 規劃部署架構
5. 設計監控與告警策略

## 輸出格式
1. 架構風格評估與建議
2. Mermaid 架構圖
3. 元件說明表
4. 部署架構圖
5. ADR（架構決策記錄）

# Prompt：API 設計

## 角色
你是一位資深的 API 架構師，專精於 RESTful API 設計。

## 功能需求
[描述需要的 API 功能]

例如：
信用卡申請 API 需支援：
1. 建立新申請
2. 查詢申請狀態
3. 上傳文件
4. 取消申請
5. 取得申請清單（分頁）

## 設計原則
- 遵循 RESTful 設計原則
- 使用統一的回應格式
- 包含適當的錯誤處理
- 支援版本控制

## 任務
請設計完整的 API：
1. 定義資源與端點
2. 設計請求/回應格式
3. 定義 HTTP 狀態碼使用
4. 設計錯誤回應格式
5. 產出 OpenAPI 3.0 規格（YAML）

## 輸出格式
1. API 端點清單表
2. 請求/回應範例
3. 錯誤碼定義
4. OpenAPI 規格片段

# Prompt：安全架構設計

## 角色
你是一位資深的資安架構師，專精於金融業系統安全設計，熟悉 OWASP、ISO 27001、金管會資安規範。

## 系統背景
[描述系統與其處理的資料類型]

例如：
信用卡申請系統，處理以下敏感資料：
- 個人身分資料（姓名、身分證字號）
- 財務資料（收入、信用分數）
- 生物特徵（身分證照片）

## 安全需求
- 符合個人資料保護法
- 符合金管會資安規範
- 防範 OWASP Top 10 威脅

## 任務
請設計完整的安全架構：
1. 識別主要威脅與風險
2. 設計認證與授權機制
3. 設計資料保護策略（傳輸中/靜態）
4. 設計日誌與稽核機制
5. 建議安全測試項目

## 輸出格式
1. 威脅模型分析
2. 安全架構圖
3. 安全控制措施清單
4. 安全測試檢查清單

# Prompt：User Story 拆分

## 角色
你是一位資深的 Scrum Master，專精於敏捷開發與 User Story 撰寫。

## 功能需求
[描述功能需求，可附上 PRD 片段]

例如：
信用卡申請功能需求：
- 申請人可以線上填寫申請表
- 系統驗證申請人身分
- 系統評估信用分數
- 申請人可以查詢進度
- 核准後自動發卡

## 任務
請協助我拆分 User Stories：
1. 使用標準格式：「作為 [角色]，我想要 [功能]，以便 [價值]」
2. 每個 Story 定義驗收標準（Acceptance Criteria）
3. 估算 Story Points（使用費氏數列：1, 2, 3, 5, 8, 13）
4. 標示 Story 之間的依賴關係
5. 建議 Sprint 規劃

## 拆分原則
- 每個 Story 應可在 2 天內完成
- Story 應該是垂直切片（包含前後端）
- Story 應該可以獨立交付價值

## 輸出格式
請以表格呈現，包含：Story ID、描述、驗收標準、Story Points、依賴關係

# Prompt：程式碼審查

## 角色
你是一位資深的 Java 開發者（Developer Agent），專精於 Spring Boot 開發，熟悉 SOLID 原則與設計模式。

## 程式碼
```java
[貼上待審查的程式碼]

**預期產出**：
- 問題清單與嚴重程度
- 改善建議
- 修改後程式碼

---

#### Prompt 3：單元測試撰寫

**用途**：請 AI 協助撰寫單元測試

```markdown
# Prompt：單元測試撰寫

## 角色
你是一位資深的測試架構師（Test Architect Agent），專精於 Java 測試，熟悉 JUnit 5、Mockito、AssertJ。

## 待測程式碼
```java
[貼上待測試的程式碼]

**預期產出**：
- 完整的測試類別
- 測試案例說明
- 覆蓋率分析

---

### 5.5 銀行與大型系統專用 Prompt 實戰對話

> 🏦 **本節特別針對銀行、保險、證券等金融業，以及大型企業系統開發情境**
> 
> 以下提供的 Prompt 範例都是在實務專案中經過驗證的，可直接複製使用。

#### 🏦 對話範例 1：法遵需求分析

**情境說明**：
> 📌 **此情境常見於銀行或大型系統**
> 
> 金融機構在開發任何系統前，必須確保符合金管會、個資法、反洗錢等法規要求。
> 這個對話展示如何請 AI 協助分析法遵需求。

**完整對話流程**：

```markdown
👤 使用者：
@Analyst Agent

我們要開發一個「線上貸款申請系統」，請協助我分析需要符合哪些法規要求。

系統背景：
- 台灣商業銀行
- 消費者貸款（信貸、車貸、房貸）
- 線上申請、線上對保
- 預計處理個人敏感資料

請列出所有相關法規與合規要求。

---

🤖 AI（Analyst Agent）回應：

## 線上貸款申請系統法規分析報告

### 一、主要適用法規

| 法規名稱 | 主管機關 | 與系統相關性 |
|----------|----------|--------------|
| 銀行法 | 金管會 | 貸款業務基本規範 |
| 個人資料保護法 | 國發會 | 客戶資料蒐集、處理、利用 |
| 電子簽章法 | 經濟部 | 線上對保法律效力 |
| 金融機構防制洗錢辦法 | 金管會 | KYC、AML 要求 |
| 金融消費者保護法 | 金管會 | 資訊揭露、公平待客 |
| 銀行業作業委託他人處理內部作業制度及程序辦法 | 金管會 | 如有委外需求 |

### 二、系統設計合規要點

#### 1. 個資保護（個資法）
- [ ] 蒐集前需取得當事人同意
- [ ] 明確告知蒐集目的、利用範圍
- [ ] 提供當事人查詢、更正、刪除權利
- [ ] 資料傳輸需加密（TLS 1.2+）
- [ ] 資料儲存需加密（AES-256）
- [ ] 存取需有稽核軌跡

#### 2. 反洗錢（AML/KYC）
- [ ] 身分驗證需符合「金融機構執行客戶盡職審查作業」規範
- [ ] 需與聯徵中心介接
- [ ] 需檢核制裁名單
- [ ] 可疑交易需通報

#### 3. 電子簽章
- [ ] 線上對保需使用合格電子簽章
- [ ] 需保留簽署時間戳記
- [ ] 文件需長期保存（依民法規定）

### 三、建議後續行動

1. **與法遵部門確認**：上述清單需經法遵部門審核
2. **安排資安審查**：系統設計需經資安部門審查
3. **準備稽核文件**：需準備系統安全說明書供金管會備查

需要我針對其中任何一項深入說明嗎？

---

👤 使用者：
請針對「個資保護」產出具體的系統設計要求，包含技術規格。

---

🤖 AI（Analyst Agent）回應：

## 個資保護系統設計規格

### 1. 資料分類與保護等級

| 資料類別 | 範例 | 保護等級 | 加密要求 |
|----------|------|----------|----------|
| 一般識別資料 | 姓名、電話 | 中 | 傳輸加密 |
| 特種個資 | 身分證字號 | 高 | 傳輸+儲存加密 |
| 財務資料 | 收入、資產 | 高 | 傳輸+儲存加密 |
| 生物特徵 | 身分證照片 | 最高 | 傳輸+儲存加密+存取控制 |

### 2. 技術規格要求

#### 傳輸安全
```yaml
# TLS 設定要求
minimum_tls_version: "1.2"
preferred_tls_version: "1.3"
cipher_suites:
  - TLS_AES_256_GCM_SHA384
  - TLS_CHACHA20_POLY1305_SHA256
certificate_requirements:
  - 需使用 EV SSL 憑證
  - 需啟用 HSTS
  - 需啟用 Certificate Transparency

# 資料庫加密設定
encryption_algorithm: "AES-256-GCM"
key_management: "AWS KMS / Azure Key Vault"
key_rotation_period: "90 days"

# RBAC 設定
authentication:
  - 多因素認證（MFA）必要
  - Session timeout: 15 分鐘
authorization:
  - 最小權限原則
  - 需 Maker-Checker 雙重確認
audit:
  - 所有存取需記錄
  - 日誌保留 7 年

□ 我已閱讀並同意「個人資料蒐集、處理及利用告知事項」
□ 我同意貴行於審核本申請案件期間，向聯徵中心查詢本人信用資料
□ 我同意貴行於本貸款存續期間，將本人資料提供予保證機構

---

#### 🏦 對話範例 2：核心銀行系統整合

**情境說明**：
> 📌 **此情境常見於銀行或大型系統**
> 
> 銀行系統開發通常需要與核心銀行系統（Core Banking）整合。
> 這個對話展示如何請 AI 協助設計整合架構。

**完整對話流程**：

```markdown
👤 使用者：
@Architect Agent

我們的線上貸款系統需要與以下系統整合：
1. 核心銀行系統（IBM AS/400）
2. 聯徵中心（JCIC）
3. 內部徵審系統
4. 通知系統（簡訊、Email、Push）

請協助設計整合架構，需考慮：
- 核心銀行系統是批次作業為主
- 聯徵中心有 TPS 限制（每秒 10 筆）
- 需支援非同步處理
- 需有重試與補償機制

---

🤖 AI（Architect Agent）回應：

## 系統整合架構設計

### 整體架構圖

```mermaid
graph TB
    subgraph "前端層"
        WEB[Web 應用]
        APP[行動 App]
    end
    
    subgraph "API 閘道層"
        GW[API Gateway<br/>Kong / AWS API Gateway]
        RL[Rate Limiter]
    end
    
    subgraph "應用服務層"
        LOAN[貸款申請服務]
        CREDIT[徵信服務]
        NOTIFY[通知服務]
    end
    
    subgraph "整合層"
        ESB[企業服務匯流排<br/>MuleSoft / IBM MQ]
        ADAPTER_CORE[核心銀行轉接器]
        ADAPTER_JCIC[聯徵轉接器]
    end
    
    subgraph "訊息佇列"
        MQ_CORE[核心銀行佇列]
        MQ_JCIC[聯徵佇列]
        MQ_NOTIFY[通知佇列]
        MQ_DLQ[死信佇列]
    end
    
    subgraph "外部系統"
        CORE[核心銀行<br/>AS/400]
        JCIC[聯徵中心]
        SMS[簡訊服務]
        EMAIL[Email 服務]
    end
    
    WEB --> GW
    APP --> GW
    GW --> RL
    RL --> LOAN
    LOAN --> CREDIT
    LOAN --> NOTIFY
    
    CREDIT --> ESB
    ESB --> ADAPTER_CORE
    ESB --> ADAPTER_JCIC
    
    ADAPTER_CORE --> MQ_CORE
    ADAPTER_JCIC --> MQ_JCIC
    NOTIFY --> MQ_NOTIFY
    
    MQ_CORE --> CORE
    MQ_JCIC --> JCIC
    MQ_NOTIFY --> SMS
    MQ_NOTIFY --> EMAIL
    
    MQ_CORE -.->|失敗| MQ_DLQ
    MQ_JCIC -.->|失敗| MQ_DLQ

┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐
│  貸款   │     │   MQ    │     │ 轉接器  │     │  Core   │
│  服務   │────>│  Queue  │────>│ Adapter │────>│ Banking │
└─────────┘     └─────────┘     └─────────┘     └─────────┘
     │                                               │
     │<──────────── Correlation ID ──────────────────│

// 聯徵查詢服務設計
@Service
public class JcicQueryService {
    
    @RateLimiter(name = "jcic", fallbackMethod = "queueQuery")
    public Mono<CreditReport> queryCredit(String idNumber) {
        // 即時查詢（TPS 限制內）
        return jcicClient.query(idNumber);
    }
    
    public Mono<CreditReport> queueQuery(String idNumber, Exception ex) {
        // 超過 TPS 限制，放入佇列稍後處理
        return messageQueue.send(new JcicQueryRequest(idNumber))
            .then(Mono.empty());
    }
}

# Resilience4j 設定
resilience4j:
  retry:
    instances:
      jcic:
        maxAttempts: 3
        waitDuration: 5s
        retryExceptions:
          - java.io.IOException
          - java.net.SocketTimeoutException
  circuitbreaker:
    instances:
      core-banking:
        failureRateThreshold: 50
        waitDurationInOpenState: 60s
        slidingWindowSize: 10

---

#### 🏦 對話範例 3：合規稽核追蹤設計

**情境說明**：
> 📌 **此情境常見於銀行或大型系統**
> 
> 金融系統必須保留完整的稽核軌跡（Audit Trail），以因應內外部稽核。
> 這個對話展示如何設計符合稽核要求的系統。

**完整對話流程**：

```markdown
👤 使用者：
@Architect Agent

我們的貸款系統需要符合金管會的稽核要求，請協助設計稽核追蹤機制。

稽核要求：
1. 所有敏感操作需記錄（查詢、修改、刪除）
2. 日誌需保留 7 年
3. 日誌需防止竄改
4. 需支援依時間、使用者、操作類型查詢
5. 需定期產出稽核報表

---

🤖 AI（Architect Agent）回應：

## 稽核追蹤系統設計

### 1. 稽核日誌資料結構

```json
{
  "auditId": "uuid",
  "timestamp": "2025-01-15T10:30:00.000Z",
  "eventType": "DATA_ACCESS",
  "eventCategory": "LOAN_APPLICATION",
  "action": "QUERY",
  "result": "SUCCESS",
  "actor": {
    "userId": "EMP001",
    "userName": "王小明",
    "department": "消金部",
    "role": "LOAN_OFFICER",
    "ipAddress": "192.168.1.100",
    "sessionId": "sess-abc123"
  },
  "target": {
    "entityType": "LOAN_APPLICATION",
    "entityId": "LA-2025-00001",
    "customerId": "C-123456"
  },
  "dataAccessed": {
    "fields": ["name", "idNumber", "income"],
    "sensitiveFields": ["idNumber"],
    "recordCount": 1
  },
  "context": {
    "businessReason": "貸款審核",
    "approvalRequired": false,
    "clientApplication": "LOAN_PORTAL_WEB"
  },
  "integrity": {
    "hash": "sha256:abc123...",
    "previousHash": "sha256:xyz789...",
    "signature": "RSA:..."
  }
}

@Service
public class AuditIntegrityService {
    
    public AuditLog createAuditLog(AuditEvent event) {
        // 取得前一筆日誌的雜湊值
        String previousHash = getLastAuditHash();
        
        // 計算當前日誌雜湊（包含前一筆雜湊）
        String content = serialize(event) + previousHash;
        String currentHash = sha256(content);
        
        // 使用 HSM 進行數位簽章
        String signature = hsm.sign(currentHash);
        
        return AuditLog.builder()
            .event(event)
            .previousHash(previousHash)
            .currentHash(currentHash)
            .signature(signature)
            .build();
    }
    
    public boolean verifyIntegrity(List<AuditLog> logs) {
        // 驗證雜湊鏈結完整性
        for (int i = 1; i < logs.size(); i++) {
            if (!logs.get(i).getPreviousHash()
                    .equals(logs.get(i-1).getCurrentHash())) {
                return false; // 發現竄改
            }
        }
        return true;
    }
}

-- 敏感資料存取統計報表
SELECT 
    DATE(timestamp) as access_date,
    actor_department,
    COUNT(*) as total_access,
    COUNT(DISTINCT target_customer_id) as unique_customers,
    SUM(CASE WHEN data_accessed_sensitive_fields IS NOT NULL 
        THEN 1 ELSE 0 END) as sensitive_access_count
FROM audit_logs
WHERE event_type = 'DATA_ACCESS'
  AND timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY DATE(timestamp), actor_department
ORDER BY access_date DESC, total_access DESC;

---

#### 🏦 對話範例 4：災難復原設計

**情境說明**：
> 📌 **此情境常見於銀行或大型系統**
> 
> 金融機構必須具備完善的災難復原（DR）計畫，確保業務連續性。
> 這個對話展示如何請 AI 協助設計 DR 架構。

**完整對話流程**：

```markdown
👤 使用者：
@Architect Agent

我們的貸款系統需要設計災難復原架構，請協助規劃。

業務要求：
- RTO（Recovery Time Objective）：4 小時
- RPO（Recovery Point Objective）：1 小時
- 需支援跨機房容災
- 預算有限，希望成本最佳化

目前環境：
- 主機房：台北
- 備援機房：高雄
- 使用 Kubernetes 部署
- 資料庫：PostgreSQL

---

🤖 AI（Architect Agent）回應：

## 災難復原架構設計

### 1. DR 策略選擇

根據 RTO 4hr / RPO 1hr 的要求，建議採用 **Warm Standby** 策略：

| 策略 | RTO | RPO | 成本 | 建議 |
|------|-----|-----|------|------|
| Backup & Restore | 24+ hr | 24 hr | 低 | ❌ 不符合 |
| Pilot Light | 4-8 hr | 1 hr | 中低 | ⚠️ 邊緣 |
| **Warm Standby** | 1-4 hr | 15 min | 中 | ✅ 建議 |
| Hot Standby | < 1 hr | 近零 | 高 | ❌ 成本過高 |

### 2. 架構設計

```mermaid
graph TB
    subgraph "台北主機房（Active）"
        LB1[Load Balancer]
        K8S1[Kubernetes Cluster<br/>3 Worker Nodes]
        DB1[(PostgreSQL<br/>Primary)]
        CACHE1[(Redis<br/>Primary)]
    end
    
    subgraph "高雄備援機房（Warm Standby）"
        LB2[Load Balancer<br/>Standby]
        K8S2[Kubernetes Cluster<br/>1 Worker Node]
        DB2[(PostgreSQL<br/>Standby)]
        CACHE2[(Redis<br/>Replica)]
    end
    
    subgraph "DNS & 流量管理"
        DNS[Route 53 / Azure Traffic Manager]
    end
    
    DNS --> LB1
    DNS -.->|Failover| LB2
    
    DB1 -->|Streaming Replication| DB2
    CACHE1 -->|Async Replication| CACHE2

# postgresql.conf (Primary)
wal_level = replica
max_wal_senders = 3
synchronous_commit = on
synchronous_standby_names = 'standby1'

# recovery.conf (Standby)
standby_mode = on
primary_conninfo = 'host=primary-db port=5432 user=replicator'
trigger_file = '/tmp/postgresql.trigger'
recovery_target_timeline = 'latest'

-- 在 Standby 上執行，監控複寫延遲
SELECT 
    pg_last_wal_receive_lsn() as received,
    pg_last_wal_replay_lsn() as replayed,
    pg_last_wal_receive_lsn() - pg_last_wal_replay_lsn() as lag_bytes,
    EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) as lag_seconds;

## DR 演練檢查清單

### 演練前準備
- [ ] 通知相關單位演練時間
- [ ] 確認備援站點資源就緒
- [ ] 準備回滾計畫

### 演練步驟
- [ ] 模擬主站點故障
- [ ] 執行切換程序
- [ ] 驗證服務可用性
- [ ] 驗證資料完整性
- [ ] 測試關鍵業務流程

### 演練後作業
- [ ] 切回主站點
- [ ] 記錄演練結果
- [ ] 檢討改進事項

---

#### 🏦 對話範例 5：效能調校諮詢

**情境說明**：
> 📌 **此情境常見於銀行或大型系統**
> 
> 系統上線後可能面臨效能問題，這個對話展示如何請 AI 協助分析與調校。

**完整對話流程**：

```markdown
👤 使用者：
@Developer Agent

我們的貸款申請 API 在尖峰時段回應時間從 200ms 上升到 3 秒，請協助分析可能原因並建議調校方案。

系統資訊：
- Spring Boot 3.2
- PostgreSQL 15
- Redis 7
- 尖峰時段：100 TPS
- 主要瓶頸：貸款申請查詢 API

問題 API：
GET /api/v1/loans/{loanId}

---

🤖 AI（Developer Agent）回應：

## 效能分析與調校建議

### 1. 可能的效能瓶頸

```mermaid
flowchart LR
    REQ[請求] --> APP[應用層]
    APP --> CACHE{Cache<br/>命中?}
    CACHE -->|是| RESP[回應]
    CACHE -->|否| DB[資料庫]
    DB --> RESP
    
    style CACHE fill:#ff9,stroke:#333
    style DB fill:#f99,stroke:#333

-- 查看慢查詢
SELECT 
    query,
    calls,
    total_time / 1000 as total_seconds,
    mean_time as avg_ms,
    rows
FROM pg_stat_statements
WHERE query LIKE '%loan%'
ORDER BY mean_time DESC
LIMIT 10;

# Redis CLI
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

# 計算命中率
# hit_rate = keyspace_hits / (keyspace_hits + keyspace_misses)
# 建議 > 90%

// 啟用 HikariCP 監控
@Bean
public HikariDataSource dataSource() {
    HikariConfig config = new HikariConfig();
    config.setMetricRegistry(metricRegistry);
    config.setMaximumPoolSize(20);
    config.setMinimumIdle(5);
    config.setConnectionTimeout(30000);
    config.setLeakDetectionThreshold(60000);
    return new HikariDataSource(config);
}

// 修改前：N+1 問題
@Query("SELECT l FROM Loan l WHERE l.id = :id")
Loan findById(String id);
// 然後在程式中逐一載入關聯

// 修改後：使用 JOIN FETCH
@Query("SELECT l FROM Loan l " +
       "LEFT JOIN FETCH l.customer " +
       "LEFT JOIN FETCH l.documents " +
       "WHERE l.id = :id")
Loan findByIdWithDetails(String id);

-- 複合索引優化查詢
CREATE INDEX idx_loan_status_created 
ON loans(status, created_at DESC);

CREATE INDEX idx_loan_customer_id 
ON loans(customer_id);

@Service
public class LoanCacheService {
    
    private final LoadingCache<String, LoanDTO> localCache;
    private final RedisTemplate<String, LoanDTO> redisTemplate;
    
    public LoanCacheService() {
        // L1: 本地快取（Caffeine）
        this.localCache = Caffeine.newBuilder()
            .maximumSize(1000)
            .expireAfterWrite(1, TimeUnit.MINUTES)
            .build(this::loadFromRedis);
    }
    
    public LoanDTO getLoan(String loanId) {
        // L1 快取查詢
        return localCache.get(loanId);
    }
    
    private LoanDTO loadFromRedis(String loanId) {
        // L2: Redis 快取
        LoanDTO dto = redisTemplate.opsForValue()
            .get("loan:" + loanId);
        
        if (dto == null) {
            // L3: 資料庫
            dto = loanRepository.findByIdWithDetails(loanId);
            redisTemplate.opsForValue()
                .set("loan:" + loanId, dto, 10, TimeUnit.MINUTES);
        }
        return dto;
    }
}

# application.yml
spring:
  datasource:
    hikari:
      maximum-pool-size: 30      # 原本 20，增加至 30
      minimum-idle: 10           # 原本 5，增加至 10
      connection-timeout: 20000  # 20 秒
      idle-timeout: 300000       # 5 分鐘
      max-lifetime: 1800000      # 30 分鐘
      leak-detection-threshold: 60000

// 使用 Micrometer 添加監控
@Timed(value = "loan.api.get", histogram = true)
public LoanDTO getLoan(String loanId) {
    // ...
}

---

### 5.6 BMAD v6 Skills 實戰 Prompt 範例

> 💡 **本節展示 v6 Skills 架構下的實戰對話**，聚焦在 Skills、Agent Menu Trigger、Dev Loop 的實際使用方式。

#### 實戰範例 1：從 bmad-help 開始一個新專案

```text
使用者：bmad-help

AI：🤖 BMAD 智慧引導助手
━━━━━━━━━━━━━━━━━━━━━━━━

歡迎使用 BMAD-METHOD！我會協助你選擇最適合的工作流程。

請告訴我你想做什麼？

A. 🚀 建立新產品/專案
B. 🔧 修復 Bug 或增加小功能
C. 📝 繼續進行中的專案
D. 📚 了解 BMAD 功能
E. 🏢 企業級合規專案

使用者：A

AI：好的！讓我幫你評估適合的流程軌道。

這個專案的規模大約是？
1. 小型（< 1 天工作量）→ Quick Flow
2. 中型（1-2 週）→ BMad Method  
3. 大型（> 2 週）→ BMad Method / Enterprise

使用者：2

AI：了解。這是一個中型專案，建議使用 BMad Method。

建議的啟動順序：
┌─────────────────────────────────────────────┐
│ 1. bmad-analyst    → 分析階段（Mary 協助）    │
│ 2. bmad-create-prd → 建立 PRD（John 協助）    │
│ 3. bmad-architect  → 架構設計（Winston 協助）  │
│ 4. bmad-create-epics-and-stories → 工作拆分   │
│ 5. bmad-dev-story  → 開始開發（Amelia 協助）   │
└─────────────────────────────────────────────┘

要開始哪一步？或者需要更詳細的說明？

使用者：先從分析開始

AI：好的！請使用 bmad-analyst 來啟動 Analyst Agent。

💡 提示：你也可以直接告訴 Mary 你的專案想法，
   她會引導你完成分析階段。

使用者：bmad-architect

Winston：你好，我是 Winston，系統架構師。
以下是我可以協助你的工作：

CA — Create Architecture（建立系統架構）
VA — Validate Architecture（驗證架構設計）
EA — Edit Architecture（編輯既有架構）
TD — Technical Decision（技術決策建議）

project-context.md 已讀取完畢。
目前專案技術棧：React + Spring Boot + PostgreSQL

請問需要我執行哪項工作？

使用者：CA

Winston：好的，讓我們開始設計系統架構。

首先，讓我確認幾個關鍵資訊：

1. PRD 中定義了多少個核心功能？
   （如果已有 prd.md，我可以直接讀取）

使用者：請讀取 _bmad-output/planning-artifacts/prd.md

Winston：已讀取 PRD。根據分析，核心功能包含：
├── F1: 使用者註冊與認證
├── F2: 信用卡申請提交
├── F3: 身分驗證（eKYC）
├── F4: 信用評分查詢
├── F5: 審核管理
└── F6: 通知系統

系統架構需要考慮的面向：
1. 整體架構風格
2. 前後端分離設計
3. 外部系統整合
4. 安全架構
5. 資料架構

讓我逐一設計...

[Winston 產出完整架構設計文件]

Winston：架構設計已完成，儲存為：
_bmad-output/planning-artifacts/architecture.md

建議下一步：
├── bmad-create-epics-and-stories（拆分工作項目）
├── VA（讓我驗證架構完整性）
└── bmad-tech-writer → MG（產生 Mermaid 架構圖）

需要我繼續嗎？

使用者：bmad-tech-writer

Paige：你好！我是 Paige，技術文件撰寫者。
以下是我可以協助你的工作：

Workflow Triggers（無需參數）：
  DP — Document Project（記錄專案）
  
Conversational Triggers（需要參數）：
  WD — Write Document（撰寫文件 + 主題描述）
  US — User Story Doc（使用者故事文件 + Story ID）
  MG — Mermaid Generate（產生圖表 + 圖表描述）
  VD — Visual Design（視覺設計文件 + 設計描述）
  EC — Explain Concept（解釋概念 + 概念名稱）

請告訴我你需要什麼？

使用者：MG 繪製一張顯示信用卡申請系統整體架構的 C4 Context 圖

Paige：好的！讓我根據 architecture.md 產生 C4 Context 圖。

```mermaid
graph TB
    subgraph "System Context"
        APPLICANT["👤 信用卡申請者<br/>(Web/App)"]
        OFFICER["👤 審核人員<br/>(內部系統)"]
        
        SYSTEM["🏢 信用卡申請系統<br/>(Spring Boot + React)"]
        
        JCIC["🏛️ 聯徵中心<br/>(外部系統)"]
        EKYC["🔐 eKYC 服務<br/>(外部系統)"]
        NOTIFY["📱 通知服務<br/>(簡訊/Email/Push)"]
        CORE["🏦 核心銀行<br/>(AS/400)"]
    end
    
    APPLICANT -->|"申請/查詢"| SYSTEM
    OFFICER -->|"審核/管理"| SYSTEM
    SYSTEM -->|"信用查詢"| JCIC
    SYSTEM -->|"身分驗證"| EKYC
    SYSTEM -->|"發送通知"| NOTIFY
    SYSTEM -->|"帳務處理"| CORE

#### 實戰範例 4：Scrum Master Bob 的 Sprint 管理

```text
使用者：bmad-sm

Bob：你好！我是 Bob，你的 Scrum Master。
以下是我可以協助的工作：

SP — Sprint Planning（Sprint 規劃）
SS — Sprint Status（Sprint 狀態）
DS — Dev Story（準備開發 Story）
ER — Epic Retrospective（Epic 回顧）
CC — Correct Course（範圍變更）

目前 Sprint：Sprint 5
Sprint 目標：完成信用卡申請核心功能
剩餘天數：7 天

請問需要我執行哪項工作？

使用者：SP

Bob：好的，讓我為 Sprint 6 進行規劃。

首先讓我檢查：
├── ✅ Epic CC： 剩餘 3 Stories 未完成
├── ✅ 架構設計：已核准
├── ✅ 團隊速率：平均 20 pts/Sprint

根據團隊速率和剩餘工作，建議的 Sprint 6 Backlog：

| 優先級 | Story | 描述 | 估算 |
|--------|-------|------|------|
| P0 | CC-006 | 信用評分引擎 | 5 pts |
| P0 | CC-007 | 核准通知 | 2 pts |
| P0 | CC-008 | 婉拒通知 | 2 pts |
| P1 | CC-009 | 管理後台-列表 | 3 pts |
| P1 | CC-010 | 管理後台-審核 | 5 pts |
| P2 | CC-011 | 統計報表 | 3 pts |

總計：20 pts（符合團隊速率）

⚠️ 風險提醒：
├── CC-006 依賴聯徵 API，需確認測試環境
└── CC-010 需要法遵部門確認審核流程

是否同意此 Sprint 計畫？需要調整嗎？

使用者：確認，開始 Sprint 6

Bob：Sprint 6 已啟動。
├── Sprint 目標：完成信用卡申請所有功能
├── Sprint 期間：2025-07-07 至 2025-07-18
├── 總 Story Points：20
└── 團隊成員：[依 project-context.md]

建議下一步：
使用 bmad-dev → DS 開始 CC-006 的開發。

💡 BMAD 與 SDD/Spec-Kit 的互補使用

方案一：BMAD 主導，Spec-Kit 輔助
├── 使用 BMAD 進行完整開發流程
└── 在 Planning 階段使用 Spec-Kit 強化規格管理

方案二：依階段選用
├── Analysis/Planning → 使用 SDD + Spec-Kit
├── Solutioning → 使用 BMAD Architect Agent
└── Implementation → 使用 BMAD Developer Agent

方案三：深度整合
├── 將 Spec-Kit 的規格模板整合到 BMAD
└── 使用 BMAD Builder 建立客製化工作流程

# 步驟 1：安裝 BMAD-METHOD（需要 Node.js 20+）
npx bmad-method install

# 步驟 2：進入專案目錄
cd your-project

# 步驟 3：啟動 BMAD AI 智慧引導
# 在 IDE 中輸入：
bmad-help

# 步驟 4：依照提示選擇適合的流程軌道

【練習任務】修復一個簡單的 Bug

1. 描述 Bug：
   "使用者登入後，首頁顯示的姓名有時會是 'undefined'"

2. 與 Developer Agent 互動：
   @Developer Agent
   請協助我分析並修復以下 Bug：
   [描述 Bug 細節]

3. 獲得技術規格後，進行修復

4. 請 AI 協助審查修復

【練習】與每個核心代理對話一次

對話範例：

@PM Agent
你好！請簡單介紹你的專長，以及什麼時候應該找你協助？

@Architect Agent  
你好！請簡單介紹你在專案中的角色，以及你能幫助我什麼？

@Developer Agent
你好！請簡單介紹你的專長，以及我該如何有效地與你協作？

📌 BMAD 團隊導入策略

階段一：試點（2-4 週）
├── 選擇 1-2 位先導者學習 BMAD
├── 選擇一個中型專案試行
├── 收集使用回饋
└── 建立內部最佳實務

階段二：擴散（4-8 週）
├── 先導者分享經驗
├── 逐步擴展到更多團隊成員
├── 建立內部教學材料
└── 定期檢討與優化

階段三：標準化（8-12 週）
├── 將 BMAD 納入團隊標準流程
├── 建立品質指標與 KPI
├── 持續優化與更新
└── 考慮客製化代理

□ 團隊是否有 AI 工具使用經驗？
□ 團隊是否認同 AI 協作的價值？
□ 是否有合適的試點專案？
□ 是否有足夠的學習時間？
□ 是否有管理層支持？
□ 是否有明確的成功標準？

💡 核心觀點：
BMAD 讓專業人員從「執行者」升級為「審核者」與「決策者」。
AI 處理重複性工作，人類專注於高價值判斷。

【Brownfield 導入策略】

步驟 1：盤點現有系統
├── 了解現有架構
├── 識別改進機會
└── 評估 BMAD 適用性

步驟 2：選擇切入點
├── 選擇一個獨立模組
├── 或選擇新功能開發
└── 避免一開始就重構核心

步驟 3：漸進擴展
├── 從小範圍開始
├── 驗證效果後擴展
└── 逐步建立團隊能力

步驟 4：持續優化
├── 收集使用回饋
├── 調整流程與實務
└── 建立長期維護策略

舊版（v5 以前）：/bmad-bmm-create-prd
新版（v6）：    bmad-create-prd

舊版（v5 以前）：/bmad-bmm-help
新版（v6）：    bmad-help

舊版（v5 以前）：/bmad-bmm-dev
新版（v6）：    bmad-dev

🤔 如何選擇 IDE？

如果你重視 BMAD 整合度 → Claude Code 或 Cursor
如果你偏好 GUI 操作    → Cursor
如果你偏好 CLI 操作    → Claude Code 或 Codex CLI
如果你已在用 AWS 生態系 → Kiro
如果你需要最大擴充性   → VS Code + AI 擴充套件

📋 project-context.md 維護策略

1. 初始建立：
   └── 執行 bmad-generate-project-context 自動產生

2. 更新時機：
   ├── 新增重要功能模組後
   ├── 技術棧變更後
   ├── 架構重大調整後
   └── 每個 Sprint 結束時

3. 更新方式：
   ├── 重新執行 bmad-generate-project-context（完整重建）
   └── 手動微調特定章節（增量更新）

📋 離線使用指南

可離線使用的功能：
├── ✅ 閱讀代理定義、工作流程定義
├── ✅ 使用範本建立文件
├── ✅ 檢查清單驗證
├── ✅ 參考已產出的 BMAD 文件
└── ✅ 手動執行工作流程步驟

需要連線的功能：
├── ❌ AI 代理互動
├── ❌ 自動產出文件
├── ❌ 安裝/更新模組
└── ❌ bmad-generate-project-context

症狀：在 IDE 中輸入 "bmad-create-prd" 沒有任何回應

排查步驟：
┌─ 1. 確認已執行 npx bmad-method install
│     └── 檢查 _bmad/ 目錄是否存在
│
├─ 2. 確認 Skills 目錄存在
│     ├── Claude Code → .claude/skills/
│     ├── Cursor → .cursor/skills/
│     └── 檢查是否有 SKILL.md 檔案
│
├─ 3. 確認 IDE 支援 Skills
│     └── 部分 IDE 版本可能需要更新
│
└─ 4. 嘗試重新安裝
      └── npx bmad-method install --force

症狀：輸入 bmad-pm 後，AI 沒有以 John（PM）的角色回應

排查步驟：
┌─ 1. 檢查 SKILL.md 內容是否正確
│     └── cat .claude/skills/bmad-pm/SKILL.md
│
├─ 2. 確認代理定義檔存在
│     └── cat _bmad/agents/pm.md
│
├─ 3. 確認 AI 有足夠的 context window
│     └── 過長的對話可能導致角色偏移
│
└─ 4. 解決方案：開始新對話，重新載入代理

症狀：文件沒有存到 _bmad-output/ 目錄

排查步驟：
┌─ 1. 確認 _bmad-output/ 目錄結構存在
│     ├── _bmad-output/planning-artifacts/
│     └── _bmad-output/implementation-artifacts/
│
├─ 2. 檢查工作流程定義中的 output 路徑
│     └── cat _bmad/workflows/create-prd.yml
│
└─ 3. 手動建立目錄
      └── mkdir -p _bmad-output/{planning,implementation}-artifacts

症狀：npx bmad-method install 或 npx bmad-builder install 失敗

排查步驟：
┌─ 1. 確認 Node.js 版本
│     └── node --version（需要 20+）
│
├─ 2. 清除 npm 快取
│     └── npm cache clean --force
│
├─ 3. 確認網路連線
│     └── npx bmad-method install 需要下載模組
│
└─ 4. 使用其他安裝方式
      └── npm install -g bmad-method && bmad-method install

症狀：載入代理後輸入 CP，但 AI 沒有啟動 Create PRD 流程

原因：AI 可能將 "CP" 理解為一般對話文字

解決方案：
┌─ 1. 明確指示：「請執行 CP 工作流程」
├─ 2. 使用完整名稱：「Create PRD」
├─ 3. 重新載入代理：再次輸入 bmad-pm
└─ 4. 直接使用 Skill：bmad-create-prd（跳過 Agent Menu）

npx bmad-builder install

bmad-agent-builder

Builder：讓我們建立自定義代理，請提供以下資訊：

使用者：
名稱：Compliance Reviewer
角色名：Rebecca
專長：金融法遵審查、個資保護、反洗錢
核心工作流程：
  - compliance-review（合規審查）
  - privacy-impact-assessment（隱私影響評估）
  - aml-check（反洗錢檢查）

# Compliance Reviewer Agent — Rebecca

## Identity
You are Rebecca, a senior compliance reviewer specializing in financial 
regulations in Taiwan. You are meticulous, thorough, and always reference 
specific regulations.

## Expertise
- 銀行法、金融消費者保護法
- 個人資料保護法（PDPA）
- 反洗錢法（AML）、KYC 規範
- ISO 27001、SOC 2 合規
- 金管會各項規範與函令

## Menu
CR — Compliance Review（合規審查）
PIA — Privacy Impact Assessment（隱私影響評估）
AML — Anti-Money Laundering Check（反洗錢檢查）
RA — Risk Assessment（風險評估）

## Behaviors
- 總是引用具體的法規條文
- 使用檢查清單格式呈現審查結果
- 標示風險等級（高/中/低）
- 提供具體的改善建議

# _bmad/workflows/compliance-review.yml
name: Compliance Review
description: 執行系統合規審查
steps:
  - id: scope
    prompt: |
      請提供以下資訊：
      1. 審查範圍（系統名稱、功能模組）
      2. 適用法規（銀行法、個資法等）
      3. 預計上線日期
    required: true
    
  - id: regulatory-mapping
    prompt: |
      根據審查範圍，列出所有適用的法規條文。
      以表格方式呈現，包含：
      - 法規名稱
      - 條文號碼
      - 合規要求摘要
      - 系統影響區域
    required: true
    
  - id: gap-analysis
    prompt: |
      對照法規要求與現有系統設計，進行差距分析。
      標示每個要求的合規狀態：
      ✅ 已合規
      ⚠️ 部分合規（需改善）
      ❌ 未合規（必須處理）
    required: true
    
  - id: remediation-plan
    prompt: |
      針對未合規項目，提出改善計畫。
      包含：優先級、負責人、預計完成時間。
    required: true
    
  - id: report
    prompt: |
      產出正式的合規審查報告。
      包含：摘要、審查結果、改善計畫、簽核欄位。
    output: _bmad-output/planning-artifacts/compliance-review.md

<!-- .claude/skills/bmad-compliance-review/SKILL.md -->
# COMPLIANCE REVIEW

Load and execute the compliance review workflow.

## Instructions
1. Read the file `_bmad/agents/compliance-reviewer.md`
2. Adopt the Rebecca persona
3. Read the file `_bmad/workflows/compliance-review.yml`
4. Execute the workflow steps sequentially
5. Save output to `_bmad-output/planning-artifacts/compliance-review.md`

bmad-compliance-review

Rebecca：你好，我是 Rebecca，合規審查員。
讓我們開始合規審查。請提供審查範圍...

# _bmad/workflows/enterprise-project-init.yml
name: Enterprise Project Initialization
description: 企業級專案啟動標準流程
agent: pm

steps:
  - id: business-case
    name: 建立商業案例
    prompt: |
      請協助建立專案商業案例（Business Case），包含：
      1. 專案背景與目標
      2. 問題陳述
      3. 預期效益（質化 + 量化）
      4. 初步預算估算
      5. ROI 分析
      6. 風險評估
    output: _bmad-output/planning-artifacts/business-case.md
    
  - id: stakeholder-analysis
    name: 利害關係人分析
    prompt: |
      請建立利害關係人分析，使用 RACI 矩陣呈現。
      包含：影響力分析、溝通策略、參與計畫。
    output: _bmad-output/planning-artifacts/stakeholder-analysis.md
    
  - id: governance-setup
    name: 專案治理架構
    prompt: |
      請建立專案治理架構，包含：
      1. 指導委員會組成
      2. 決策流程
      3. 報告機制（週報/月報）
      4. 升級路徑
      5. 變更管理流程
    output: _bmad-output/planning-artifacts/governance.md
    
  - id: compliance-checklist
    name: 合規檢查清單
    prompt: |
      請根據專案類型產出合規檢查清單。
      涵蓋：資安、個資、法遵、稽核要求。
    output: _bmad-output/planning-artifacts/compliance-checklist.md

# 1. 使用 BMM 核心：PRD、架構、開發
bmad-create-prd       → 產品需求
bmad-create-architecture → 系統架構
bmad-dev-story        → Story 開發

# 2. 使用 TEA：企業測試
bmad-tea-test-plan    → 測試計畫
bmad-tea-atdd        → ATDD 測試

# 3. 使用自定義模組：合規審查
bmad-compliance-review → 合規審查
bmad-risk-assessment  → 風險評估

使用方式 1：在對話開頭提供
━━━━━━━━━━━━━━━━━━━━━━━━
"請先閱讀以下 BMAD 文件，然後協助我..."
[貼上 llms-full.txt 內容或提供 URL]

使用方式 2：設定為 IDE 指令集
━━━━━━━━━━━━━━━━━━━━━━━━
將 llms-full.txt 的內容加入 IDE 的
自定義指令集（Custom Instructions）中，
讓 AI 在每次對話都自動理解 BMAD。

使用方式 3：在 project-context.md 中引用
━━━━━━━━━━━━━━━━━━━━━━━━
在 project-context.md 中加入：
"本專案使用 BMAD-METHOD v6.0.4，
完整方法論文件請參考：
https://docs.bmad-method.org/llms-full.txt"

步驟 1：產生專案上下文
bmad-generate-project-context

步驟 2：使用 Analyst (Mary) 記錄現有系統
bmad-analyst → DP（Document Project）

步驟 3：建立現有架構文件
bmad-architect → CA（CREATE Architecture）
（基於現有系統，而非設計新系統）

產出物：
├── project-context.md    ← 專案概覽
├── architecture.md       ← 現有架構記錄
└── tech-debt.md          ← 技術債清單（選用）

1. 客製化代理（使用 BMB）
   └── 針對團隊特有角色建立專屬代理

2. 建立範本庫
   └── 將成功案例轉化為可重複使用的範本

3. 度量與改善
   └── 追蹤 KPI，持續優化流程

4. 知識傳承
   └── 建立內部 BMAD 教學材料

## 專案啟動前檢查

### 環境準備
- [ ] 已安裝 Node.js（建議 20+）
- [ ] 已安裝 BMAD-METHOD（`npx bmad-method install`）
- [ ] IDE 已設定完成（Claude Code / Cursor / Codex CLI / Kiro）
- [ ] 團隊成員都有 AI 工具存取權限

### 專案評估
- [ ] 已確認專案適合使用 BMAD
- [ ] 已選擇適當的流程軌道（Quick / Method / Enterprise）
- [ ] 已識別主要利害關係人
- [ ] 已設定初步的成功標準

### 團隊準備
- [ ] 團隊成員已完成 BMAD 基礎訓練
- [ ] 已指定 BMAD 流程負責人
- [ ] 已建立 Prompt 範本庫
- [ ] 已建立品質審核機制

## Analysis 階段完成檢查

- [ ] Product Brief 已建立（使用 `CB`）
- [ ] 問題陳述已明確定義
- [ ] 研究與探索已完成（使用 `RS`）
- [ ] 成功標準已設定（可量測）
- [ ] 利害關係人已核准

### 產出物檢查
- [ ] product-brief.md 已產出
- [ ] research-notes.md 已產出（選用）
- [ ] project-context.md 已產出（Brownfield 專案）

## Planning 階段完成檢查

- [ ] PRD 已建立（使用 `bmad-create-prd`）
- [ ] PRD 已通過驗證（使用 `VP`）
- [ ] 功能需求已完整定義
- [ ] 驗收標準已設定
- [ ] UX 設計已完成（選用）

### 產出物檢查
- [ ] prd.md 已產出
- [ ] ux-design.md 已產出（選用）
- [ ] tech-spec.md 已產出（Quick Flow）

## Solutioning 階段完成檢查

- [ ] 架構設計已完成（使用 `bmad-create-architecture`）
- [ ] 技術選型已完成並記錄
- [ ] Epic & Story 已拆分（使用 `bmad-create-epics-and-stories`）
- [ ] 實作準備度已檢查（使用 `bmad-check-implementation-readiness`）
- [ ] API 已設計
- [ ] 安全設計已完成（Enterprise 適用）

### 產出物檢查
- [ ] architecture.md 已產出
- [ ] epic-*.md 已產出
- [ ] ADR 文件已建立

## Implementation 階段完成檢查

- [ ] Sprint 已規劃（使用 `bmad-sprint-planning`）
- [ ] Story 已建立（使用 `bmad-create-story`）
- [ ] 程式碼已撰寫（使用 `bmad-dev-story`）
- [ ] Code Review 已完成
- [ ] 測試已執行並通過
- [ ] 部署已完成
- [ ] 文件已更新

### 產出物檢查
- [ ] sprint-backlog.md 已產出
- [ ] story-*.md 已產出
- [ ] 程式碼已提交
- [ ] 測試報告已產出
- [ ] release-notes.md 已產出

## AI 產出品質檢查

### Prompt 品質
- [ ] Prompt 有明確的角色設定
- [ ] Prompt 有清楚的任務描述
- [ ] Prompt 有指定輸出格式
- [ ] 已提供足夠的背景資訊

### AI 產出審核
- [ ] 產出內容符合需求
- [ ] 產出格式正確
- [ ] 專業術語使用正確
- [ ] 沒有明顯的邏輯錯誤
- [ ] 沒有敏感資訊外洩

### 程式碼審核（如適用）
- [ ] 程式碼可編譯/執行
- [ ] 命名清晰有意義
- [ ] 沒有安全漏洞
- [ ] 有適當的錯誤處理
- [ ] 有足夠的測試覆蓋

## BMAD 學習進度檢查

### 第一週
- [ ] 已完成 BMAD 安裝（`npx bmad-method install`）
- [ ] 已執行 `bmad-help`
- [ ] 已完成 Quick Flow 練習
- [ ] 已了解各代理角色

### 第二週
- [ ] 已完成完整 BMad Method 練習
- [ ] 已產出 PRD 文件
- [ ] 已產出架構設計文件
- [ ] 已實際應用於專案任務

### 第三-四週
- [ ] 能獨立完成中型功能開發
- [ ] 能有效使用 Prompt
- [ ] 能審核 AI 產出品質
- [ ] 能指導其他同仁基礎操作