fix localhost and hostExist

agents/backend-agent.md

@@ -0,0 +1,20 @@
+# Backend Agent (Golang Backend Engineer)
+
+## Core Goal
+Responsible for API design, server-side implementation, and ensuring high-quality, testable Golang code following Domain-Driven + go-zero style architecture.
+
+## Workflow (Input & Output)
+
+| Stage | Action | Input | Output | Skill/Tool |
+|-------|--------|-------|--------|-----------|
+| API Design | Design RESTful APIs | PRD | `docs/api/{date}-{feature}.yaml` | `be-api-design`, `design-an-interface` |
+| DB Schema | Align API with Schema | API spec + Domain model | Schema Alignment Confirmation | Collaboration w/ DBA Agent |
+| Task Breakdown | Review implementation plan | `./plans/{feature}.md` | Feasibility Confirmation | Review Orchestrator's plan |
+| Implementation | Build server-side logic | Plan + API spec + DB schema | Production-ready Go code | `go-backend-dev`, `tdd` |
+| QA Support | Fix bugs & regressions | QA report | Bug fixes + Regression tests | Bug fix support |
+| Code Review | Address PR feedback | Review comments | Updated Code | Respond to PR feedback |
+
+## Key Deliverables
+- [ ] **OpenAPI 3.0 Specification**: Mapped to all functional requirements.
+- [ ] **Domain-Driven Implementation**: Structure containing `pkg/domain`, `pkg/usecase`, `internal/logic`, and `pkg/repository`.
+- [ ] **Test Suite**: Unit tests $\ge 80\%$, business logic $\ge 90\%$, and passing integration tests for critical paths.

agents/pm-agent.md

@@ -1,145 +1,20 @@
 # PM Agent (Product Manager)
 
-## Role Positioning
+## Core Goal
+Responsible for requirement discovery, PRD writing, and product planning to ensure a clear, testable, and valuable product definition.
 
-**Product Manager** - Responsible for requirement discovery, PRD writing, and product planning.
+## Workflow (Input & Output)
 
-## Core Responsibilities
+| Stage | Action | Input | Output (STRICT PATH) | Skill/Tool |
+|-------|--------|-------|----------------------|-----------|
+| Brainstorming | Explore user needs & ideas | User's initial ideas | `docs/brainstorm/{date}-{feature}-design.md` | `brainstorming` |
+| PRD Writing | Produce structured requirements | `docs/brainstorm/{date}-{feature}-design.md` | `docs/prd/{date}-{feature}.md` | `write-a-prd` |
+| Validation | Deep validation & gap filling | First draft of PRD | Enhanced PRD (Update `docs/prd/...`) | `grill-me` |
 
-1. **Requirement Discovery** - Understand user needs through interviews
-2. **PRD Writing** - Produce structured Product Requirement Documents (including Functional & Non-Functional requirements)
-3. **User Stories** - Define clear user stories
-4. **Acceptance Criteria** - Set testable acceptance criteria
-5. **Prioritization** - Prioritize features and requirements
-
-## Skills Used
-
-### Stage 1: Brainstorming
-- **Skill**: `brainstorming`
-- **Input**: User's initial ideas
-- **Output**: `docs/brainstorm/{date}-{feature}-design.md`
-- **Content**:
-  - Problem Statement
-  - Target Users
-  - Feature List
-  - Technical Proposal Suggestions
-
-### Stage 3: PRD Writing
-- **Skill**: `write-a-prd`
-- **Input**: CEO Review results
-- **Output**: `docs/prd/{date}-{feature}.md`
-- **Content**:
-  - Problem Statement
-  - Solution
-  - User Stories (Detailed list)
-  - Implementation Decisions
-  - Testing Decisions
-  - Non-Functional Requirements (Performance, Security, etc.)
-  - Out of Scope
-
-### Stage 3.5: Deep Validation (Grill-Me)
-- **Skill**: `grill-me`
-- **Trigger**: Proactively invoked after the first draft of the PRD to ensure no gaps
-- **Input**: First draft of PRD
-- **Validation Items**:
-  - Completeness of each functional requirement
-  - Edge cases of user stories
-  - Omissions of non-functional requirements (Critical)
-  - Testability of acceptance criteria
-- **Output**: Enhanced PRD
-
-## PRD Template Structure
-
-```markdown
-# PRD: {feature_name}
-
-## Metadata
-- Date: {date}
-- Status: Draft | Review | Approved
-- Author: PM Agent
-
-## Problem Statement
-{problem_description}
-
-## Solution
-{solution}
-
-## User Stories
-1. As a {role}, I want {feature}, so that {benefit}
-2. ...
-
-## Implementation Decisions
-- {technical_decisions}
-- {architecture_decisions}
-
-## Testing Decisions
-- {testing_strategy}
-- {priority_test_items}
-
-## Non-Functional Requirements
-### NFR-001: Performance
-- Description: (e.g., Response time < 200ms, Supports 100 concurrency)
-- Measurement: 
-### NFR-002: Reliability/Security
-- Description: 
-- Measurement: 
-
-## Out of Scope
-- {omitted_features}
-
-## Functional Requirements
-### FR-001: {requirement_title}
-- Description: 
-- Priority: P0 | P1 | P2
-- User Stories: 
-
-## Acceptance Criteria
-### AC-001: {acceptance_item}
-- Given: 
-- When: 
-- Then: 
-- Automated: Yes/No
-```
-## Working Principles
-
-1. **User-Centric** - All requirements start from the user's perspective
-2. **Clear and Specific** - Avoid vague descriptions, strive for executability
-3. **Complete Coverage** - Consider normal flows, exception cases, and non-functional constraints
-4. **Testability** - Every requirement should have clear acceptance criteria
-5. **Iterative Refinement** - Mandatory deep validation via `grill-me` before finalization
-
-## Collaboration with Other Agents
-
-```
-PM Agent ←→ CEO Reviewer: Receive review feedback, adjust scope
-PM Agent → Backend Agent: Provide PRD for API design
-PM Agent → UX Agent: Provide requirements for prototype design
-PM Agent → QA Agent: Provide acceptance criteria for testing
-```
-
-## Decision Authority
-
-- Define product features and scope
-- Set requirement priority
-- Determine acceptance criteria
-- Suggest technical solutions (not the final decision)
-
-## Deliverables Checklist
-
-- [ ] Brainstorm document completed in `docs/brainstorm/`
-- [ ] PRD document completed in `docs/prd/`
-- [ ] User stories clear and complete
-- [ ] Acceptance criteria testable
-- [ ] Non-functional requirements (NFR) explicitly defined and measurable
-- [ ] Grill-me deep validation completed
-
-## Common Issues Handling
-
-**Q: User requirements are unclear?**  
-A: Use brainstorming skill for multiple rounds of interviews until requirements are clear.
-
-**Q: Technical feasibility is doubtful?**  
-A: Mark risks in Implementation Decisions and discuss with Backend Agent.
-
-**Q: Scope is too large?**  
-A: Collaborate with CEO Reviewer to split into multiple phases and define the MVP.
+## Key Deliverables
+- [ ] **Brainstorm Document**: Problem statement, target users, and feature list. (Path: `docs/brainstorm/`)
+- [ ] **Product Requirement Document (PRD)**:
+  - Detailed User Stories.
+  - Testable Acceptance Criteria (AC).
+  - Measurable Non-Functional Requirements (NFR - Performance, Security).
+  - Explicit Out of Scope definitions. (Path: `docs/prd/`)

agents/translation/backend-agent-zh.md

@@ -0,0 +1,20 @@
+# 後端 Agent (Golang 後端工程師)
+
+## 核心目標
+負責 API 設計、伺服器端實作，並確保遵循 Domain-Driven + go-zero 風格架構的高品質、可測試 Golang 程式碼。
+
+## 工作流 (輸入與輸出)
+
+| 階段 | 行動 | 輸入 | 輸出 | 技能/工具 |
+|-------|--------|-------|--------|-----------|
+| API 設計 | 設計 RESTful API | PRD | `docs/api/{date}-{feature}.yaml` | `be-api-design`, `design-an-interface` |
+| DB Schema | 將 API 與 Schema 對齊 | API 規範 + 領域模型 | Schema 對齊確認 | 與 DBA Agent 協作 |
+| 任務分解 | 審查實作計劃 | `./plans/{feature}.md` | 可行性確認 | 審查 Orchestrator 的計劃 |
+| 實作 | 構建伺服器端邏輯 | 計劃 + API 規範 + DB schema | 生產就緒的 Go 程式碼 | `go-backend-dev`, `tdd` |
+| QA 支援 | 修復 Bug 與回歸測試 | QA 報告 | Bug 修復 + 回歸測試 | Bug 修復支援 |
+| 程式碼審查 | 處理 PR 回饋 | 審查意見 | 更新後的程式碼 | 回應 PR 回饋 |
+
+## 關鍵交付物
+- [ ] **OpenAPI 3.0 規範**: 映射至所有功能需求。
+- [ ] **領域驅動實作 (Domain-Driven)**: 包含 `pkg/domain`, `pkg/usecase`, `internal/logic`, 及 `pkg/repository` 的結構。
+- [ ] **測試套件**: 單元測試 $\ge 80\%$，業務邏輯 $\ge 90\%$，且關鍵路徑的整合測試通過。

agents/translation/pm-agent-zh.md

@@ -0,0 +1,20 @@
+# PM Agent (產品經理)
+
+## 核心目標
+負責需求探索、PRD 編寫及產品規劃，以確保定義出清晰、可測試且具價值的產品。
+
+## 工作流 (輸入與輸出)
+
+| 階段 | 行動 | 輸入 | 輸出 | 技能/工具 |
+|-------|--------|-------|--------|-----------|
+| 腦力激盪 | 探索用戶需求與想法 | 用戶的初步想法 | `docs/brainstorm/{date}-{feature}-design.md` | `brainstorming` |
+| PRD 編寫 | 產出結構化需求文件 | CEO 審查結果 | `docs/prd/{date}-{feature}.md` | `write-a-prd` |
+| 驗證 | 深度驗證與補洞 | PRD 初稿 | 強化後的 PRD | `grill-me` |
+
+## 關鍵交付物
+- [ ] **腦力激盪文件**: 問題陳述、目標用戶及功能清單。
+- [ ] **產品需求文件 (PRD)**:
+  - 詳細的用戶故事 (User Stories)。
+  - 可測試的驗收標準 (Acceptance Criteria)。
+  - 可量化的非功能性需求 (NFR - 性能、安全)。
+  - 明確的範圍外 (Out of Scope) 定義。

design-idea/IMPLEMENTATION_CHECKLIST.md

@@ -0,0 +1,322 @@
+# 實施檢查清單
+
+本文件提供 Vibe-Kanban 工作流程的實施檢查清單，確保所有組件都已正確實作。
+
+---
+
+## 檢查清單總覽
+
+- [ ] Phase 1: 核心框架
+- [ ] Phase 2: 設計階段技能
+- [ ] Phase 3: 整合測試
+- [ ] Phase 4: 優化
+
+---
+
+## Phase 1: 核心框架
+
+### 1.1 主控技能 - vibe-kanban
+
+```
+skills/vibe-kanban/
+├── SKILL.md                # 主技能定義
+├── references/
+│   └── workflow-diagram.md # 工作流程圖
+└── templates/
+    └── state-template.yaml # 狀態模板
+```
+
+#### SKILL.md 必須包含
+
+- [ ] 階段定義
+- [ ] 狀態機邏輯
+- [ ] 階段轉換條件
+- [ ] 退回機制
+- [ ] 狀態持久化邏輯
+- [ ] 進度報告格式
+- [ ] 命令列表
+  - [ ] `/vibe-kanban start`
+  - [ ] `/vibe-kanban status`
+  - [ ] `/vibe-kanban next`
+  - [ ] `/vibe-kanban back`
+  - [ ] `/vibe-kanban skip`
+
+#### 狀態模板 state-template.yaml
+
+- [ ] 專案名稱欄位
+- [ ] 當前階段欄位
+- [ ] 歷史記錄欄位
+- [ ] 產出文件欄位
+- [ ] 阻塞原因欄位
+- [ ] 下一步動作欄位
+
+### 1.2 PRD 技能 - pm-prd
+
+```
+skills/pm-prd/
+├── SKILL.md
+└── templates/
+    └── prd-template.md
+```
+
+#### SKILL.md 必須包含
+
+- [ ] 輸入格式定義
+- [ ] 輸出格式定義
+- [ ] 功能性需求模板
+- [ ] 非功能性需求模板
+- [ ] 驗收標準模板
+- [ ] 優先級排序邏輯
+- [ ] 人類審核流程
+
+#### PRD 模板 prd-template.md
+
+- [ ] Metadata 區塊
+- [ ] 背景區塊
+- [ ] 功能性需求區塊 (FR-001, FR-002, ...)
+- [ ] 非功能性需求區塊 (NFR-001, NFR-002, ...)
+- [ ] 驗收標準區塊 (AC-001, AC-002, ...)
+- [ ] 排期建議區塊
+- [ ] 依賴區塊
+- [ ] 風險評估區塊
+
+---
+
+## Phase 2: 設計階段技能
+
+### 2.1 API 設計技能 - be-api-design
+
+```
+skills/be-api-design/
+├── SKILL.md
+└── templates/
+    └── openapi-template.yaml
+```
+
+#### SKILL.md 必須包含
+
+- [ ] RESTful API 設計原則
+- [ ] OpenAPI 3.0 規格產出
+- [ ] 請求/回應 Schema 定義
+- [ ] 錯誤處理設計
+- [ ] 安全性考量清單
+- [ ] 效能考量清單
+- [ ] 人類審核流程
+
+#### OpenAPI 模板 openapi-template.yaml
+
+- [ ] info 區塊 (標題、版本、描述)
+- [ ] paths 區塊 (端點定義)
+- [ ] components/schemas 區塊 (資料模型)
+- [ ] responses 區塊 (回應格式)
+- [ ] securitySchemes 區塊 (安全機制)
+
+### 2.2 資料庫設計技能- dba-schema
+
+```
+skills/dba-schema/
+├── SKILL.md
+└── templates/
+    └── schema-template.sql
+```
+
+#### SKILL.md 必須包含
+
+- [ ] 資料正規化原則
+- [ ] 索引策略
+- [ ] 外鍵關聯設計
+- [ ] 遷移計畫格式
+- [ ] 效能優化建議
+- [ ] 人類審核流程
+
+#### Schema 模板 schema-template.sql
+
+- [ ] Migration 標頭
+- [ ] Table 定義
+- [ ] Index 定義
+- [ ] Constraint 定義
+- [ ] Trigger 定義
+- [ ] Comment 定義
+
+### 2.3 UX 原型技能 - ux-prototype
+
+```
+skills/ux-prototype/
+├── SKILL.md
+└── templates/
+    ├── user-flow-template.md
+    └── component-mapping-template.md
+```
+
+#### SKILL.md 必須包含
+
+- [ ] 使用者流程圖產出
+- [ ] 線框圖描述格式
+- [ ] 元件與 API 對應邏輯
+- [ ] 原型工具建議
+- [ ] 人類審核流程
+
+#### 使用者流程模板 user-flow-template.md
+
+- [ ] Mermaid 流程圖
+- [ ] 頁面清單表格
+- [ ] 頁面 URL 對應
+
+#### 元件對應模板 component-mapping-template.md
+
+- [ ] 頁面元件列表
+- [ ] 元件資料來源
+- [ ] API 端點對應
+- [ ] 快取策略建議
+
+---
+
+## Phase 3: 整合測試
+
+### 3.1 端到端流程測試
+
+- [ ] 測試案例 1: 完整流程從頭到尾
+  - [Brainstorming → CEO Review → PRD → ... → Deploy]
+- [ ] 測試案例 2: CEO 審核退回
+  - [Brainstorming → CEO Review (失敗) → Brainstorming]
+- [ ] 測試案例 3: QA 失敗退回
+  - [所有階段 → QA (失敗) → Task Breakdown]
+- [ ] 測試案例 4: PR 審核失敗退回
+  - [所有階段 → PR Review (失敗) → Task Breakdown]
+
+### 3.2 狀態持久化測試
+
+- [ ] 測試狀態檔案建立
+- [ ] 測試狀態檔案更新
+- [ ] 測試狀態檔案恢復
+- [ ] 測試狀態檔案損壞處理
+
+### 3.3 退回機制測試
+
+- [ ] 測試退回到上一階段
+- [ ] 測試退回到特定階段
+- [ ] 測試退回後的產出清理
+- [ ] 測試退回後重新執行
+
+### 3.4 併發測試
+
+- [ ] 測試多專案併發執行
+- [ ] 測試鎖機制
+- [ ] 測試資源競爭
+
+---
+
+## Phase 4: 優化
+
+### 4.1 效能優化
+
+- [ ] 階段轉換時間優化
+- [ ] 檔案讀寫優化
+- [ ] 快取機制實作
+
+### 4.2 錯誤處理優化
+
+- [ ] 友善錯誤訊息
+- [ ] 錯誤恢復機制
+- [ ] 錯誤日誌記錄
+
+### 4.3 使用者體驗優化
+
+- [ ] 進度視覺化
+- [ ] 預估時間顯示
+- [ ] 歷史記錄瀏覽
+
+### 4.4 文件完善
+
+- [ ] 使用者指南
+- [ ] 開發者文件
+- [ ] API 文件
+- [ ] 最佳實踐指南
+
+---
+
+## 測試矩陣
+
+### 功能測試
+
+| 功能 | 測試案例 | 預期結果 | 實際結果 | 狀態 |
+|------|---------|---------|---------|------|
+| 開始新專案 | 輸入專案名稱 | 建立狀態檔案 | | [ ] |
+| 查看狀態 | 執行status | 顯示當前階段 | | [ ] |
+| 前往下一階段 | 執行 next | 狀態更新 | | [ ] |
+| 退回上一階段 | 執行 back | 狀態回滾 | | [ ] |
+| 跳過階段 | 執行 skip | 狀態跳過 | | [ ] |
+
+### 整合測試
+
+| 整合點 | 測試案例 | 預期結果 | 實際結果 | 狀態 |
+|--------|---------|---------|---------|------|
+| PM → CEO | PRD 審核通過 | 進入 API 設計 | | [ ] |
+| CEO 失敗 | PRD 審核失敗 | 退回Brainstorming | | [ ] |
+| QA 失敗 | 測試不通過 | 退回 Task Breakdown | | [ ] |
+| Deploy | 部署成功 | 專案完成 | | [ ] |
+
+### 效能測試
+
+| 指標 | 目標 | 實際 | 狀態 |
+|------|------|------|------|
+| 階段轉換時間 | < 5 秒 | | [ ] |
+| 狀態載入時間 | < 1 秒 | | [ ] |
+|檔案寫入時間 | < 2 秒 | | [ ] |
+
+---
+
+## 部署檢查清單
+
+### 部署前
+
+- [ ] 所有測試通過
+- [ ] 文件完整
+- [ ] 版本號更新
+- [ ] CHANGELOG 更新
+
+### 部署中
+
+- [ ] 備份現有版本
+- [ ] 部署新版本
+- [ ] 驗證部署成功
+
+### 部署後
+
+- [ ] 監控錯誤日誌
+- [ ] 驗證功能正常
+- [ ] 更新使用文件
+
+---
+
+## 維護檢查清單
+
+### 每週
+
+- [ ] 檢查錯誤日誌
+- [ ] 檢查效能指標
+- [ ] 檢查使用者反饋
+
+### 每月
+
+- [ ] 更新技能版本
+- [ ] 審核技術債
+- [ ] 優化流程
+
+### 每季
+
+- [ ] 全面測試回歸
+- [ ] 安全性審核
+- [ ] 架構審核
+
+---
+
+## 簽核記錄
+
+| 階段 | 審核人 | 日期 | 簽核 |
+|------|-------|------|------|
+| Phase 1 | | | [ ] |
+| Phase 2 | | | [ ] |
+| Phase 3 | | | [ ] |
+| Phase 4 | | | [ ] |
+| 最終審核 | | | [ ] |

design-idea/QUICK_START_GUIDE.md

@@ -0,0 +1,197 @@
+# Vibe-Kanban 快速開始指南
+
+本指南幫助您快速理解如何使用 Vibe-Kanban 工作流程。
+
+---
+
+## 核心概念
+
+### 什麼是 Vibe-Kanban？
+
+Vibe-Kanban 是一個由 AI 代理協作的軟體開發工作流程系統。每個開發階段都由特定的 AI 代理負責，從需求探索到部署全自動化。
+
+### 核心角色
+
+| 角色 | 負責階段 | AI 技能 |
+|------|---------|---------|
+| PM (產品經理) | 需求探索、PRD 撰寫 | brainstorming,pm-prd |
+| CEO (商業決策) | 商業價值審核 | plan-ceo-review |
+| Backend Engineer | API 設計 | be-api-design |
+| DBA | 資料庫規劃 | dba-schema |
+| UX Designer | 原型設計 | ux-prototype |
+| Design Reviewer | 設計審核 | design-review |
+| QA Engineer | 測試驗收 | qa |
+| OPS (運維) | 部署 | land-and-deploy |
+
+---
+
+## 使用方式
+
+### 1. 開始新專案
+
+```bash
+/vibe-kanban start "使用者認證功能"
+```
+
+系統會自動：
+1. 建立專案狀態檔案
+2. 觸發 PM 進行需求探索
+3. 進入 Brainstorming 階段
+
+### 2. 查看當前狀態
+
+```bash
+/vibe-kanban status
+```
+
+輸出範例：
+```
+╔══════════════════════════════════════════════════════════════╗
+║                    VIBE-KANBAN 狀態                          ║
+╠══════════════════════════════════════════════════════════════╣
+║ 專案: feature-user-auth                                      ║
+║ 當前階段: CEO_REVIEW (CEO 商業價值審核)                       ║
+║ 狀態: IN_PROGRESS                                            ║
+║                                                              ║
+║ 下一步: 等待 CEO 審核通過                                     ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+### 3. 前往下一階段
+
+```bash
+/vibe-kanban next
+```
+
+### 4. 退回修改
+
+```bash
+/vibe-kanban back "設計與需求不符，需要重新定義"
+```
+
+---
+
+## 工作流程總覽
+
+```
+┌─────────┐    ┌──────────┐    ┌─────────┐    ┌───────────┐
+│Brainstorm│ ──▶│CEO Review│ ──▶│   PRD   │ ──▶│ API Design │
+└─────────┘    └──────────┘    └─────────┘    └───────────┘
+                                                   │
+                                                   ▼
+┌─────────┐    ┌──────────┐    ┌──────────┐    ┌───────────┐
+│  Deploy │ ◀──│PR Review │◀───│    QA    │◀───│DB Schema  │
+└─────────┘    └──────────┘    └──────────┘    └───────────┘
+```
+
+---
+
+## 各階段產出
+
+### 階段 1-2: 需求探索
+- **產出**: `docs/brainstorm/{date}-{feature}.md`
+- **內容**: 需求分析、使用者故事、技術方案
+
+### 階段 3: PRD 撰寫
+- **產出**: `docs/prd/{date}-{feature}.md`
+- **內容**: 功能性需求、非功能性需求、驗收標準
+
+### 階段 4: API 設計
+- **產出**: `docs/api/{date}-{feature}.yaml`
+- **內容**: OpenAPI 3.0 規格文件
+
+### 階段 5: 資料庫規劃
+- **產出**: `docs/db/{date}-{feature}.sql`
+- **內容**: 資料表定義、索引、遷移計畫
+
+### 階段 6: UX 原型
+- **產出**: `docs/design/{date}-{feature}/`
+- **內容**: 使用者流程、線框圖、原型連結
+
+### 階段 7: 設計審核
+- **產出**: `docs/design/{date}-{feature}/review-report.md`
+- **內容**: 審核報告、修改建議
+
+### 階段 8: 任務拆分
+- **產出**: `.gstack/kanban/{project}/tasks.md`
+- **內容**: 前後端任務分配
+
+### 階段 9: 實作
+- **產出**: 程式碼
+- **內容**: 功能實作、單元測試
+
+### 階段 10: QA 測試
+- **產出**: `.gstack/qa-reports/qa-report-{date}.md`
+- **內容**: 測試報告、Bug 列表
+
+### 階段 11: PR 審核
+- **產出**: PR 描述、審核報告
+- **內容**: 代碼變更說明
+
+### 階段 12: 部署
+- **產出**: `.gstack/deploy-reports/deploy-report-{date}.md`
+- **內容**: 部署日誌、驗證結果
+
+---
+
+常見問題
+
+### Q: 如果某個階段的產出不滿意怎麼辦？
+
+A: 使用 `/vibe-kanban back "原因"` 退回到上一階段重新處理。
+
+### Q: 可以跳過某些階段嗎？
+
+A: 使用 `/vibe-kanban skip`，但需要確認跳過的原因和風險。
+
+### Q: 如何查看歷史記錄？
+
+A: 查看 `.gstack/kanban/{project}/` 目錄下的 `state.yaml` 檔案。
+
+### Q: 多人協作時如何同步狀態？
+
+A: 將 `.gstack/kanban/` 目錄加入版本控制，團隊成員可以共享狀態。
+
+---
+
+## 最佳實踐
+
+1. **每個階段都應該產出文件** - 確保可追溯性
+2. **及時退回修改** - 發現問題立即退回，不要累積技術債
+3. **QA 前確保驗收標準完整** - 測試案例來自驗收標準
+4. **部署前確認所有測試通過** - 自動化測試是門檻
+5. **保存所有產出文件** - 方便日後參考和審計
+
+---
+
+## 故障排除
+
+### 問題: 狀態檔案損壞
+
+```bash
+# 重置狀態檔案
+rm .gstack/kanban/{project}/state.yaml
+/vibe-kanban start "{project-name}"
+```
+
+### 問題: 階段卡住無法前進
+
+```bash
+# 強制前往下一階段
+/vibe-kanban next --force
+```
+
+### 問題: 需要回到特定階段
+
+```bash
+# 跳轉到特定階段
+/vibe-kanban goto PRD
+```
+
+---
+
+## 下一步
+
+1. 查看 [VIBE_KANBAN_PLAN.md](VIBE_KANBAN_PLAN.md) 了解詳細設計
+2. 查看 [IMPLEMENTATION_CHECKLIST.md](IMPLEMENTATION_CHECKLIST.md) 了解實施步驟
+3. 開始使用 `/vibe-kanban start "您的功能名稱"`

design-idea/SKILL_DEPENDENCIES.md

@@ -0,0 +1,500 @@
+# 技能依賴圖
+
+本文件描述 Vibe-Kanban 工作流程中各技能之間的依賴關係。
+
+---
+
+## 依賴圖總覽
+
+```
+┌─────────────────────────────────────────────────────────────────────────┐
+│                        技能依賴關係圖                                    │
+└─────────────────────────────────────────────────────────────────────────┘
+
+                              ┌──────────────┐
+                              │   使用者    │
+                              │   輸入想法    │
+                              └──────┬───────┘
+                                     │
+                                     ▼
+                    ┌────────────────────────────────┐
+                    │                                │
+                    │      vibe-kanban (主控)        │
+                    │                                │
+                    └────────────────┬───────────────┘
+                                     │
+         ┌───────────────────────────┼───────────────────────────┐
+         │                           │                           │
+         ▼                           ▼                           ▼
+┌─────────────────┐     ┌─────────────────────────┐     ┌─────────────────┐
+│  brainstorming  │     │   plan-ceo-review       │     │     pm-prd     │
+│                 │     │   (現有技能)              │     │    (新建技能)  │
+│   (現有技能)     │     │                         │     │                │
+└────────┬────────┘     └────────────┬────────────┘     └────────┬────────┘
+         │                           │                           │
+         └─────────────┬─────────────┘                           │
+                       │                                         │
+                       ▼                                         │
+               ┌─────────────────┐                               │
+               │   ceo-review    │◀──────────────────────────────┘
+               │     output      │
+               └────────┬────────┘│
+                        │
+                        ▼
+              ┌────────────────────────────┐
+              │                            │
+              │be-api-design (新建技能)   │
+              │                            │
+              └─────────────┬──────────────┘│
+                            │
+                            ▼
+              ┌────────────────────────────┐
+              │                            │
+              │   dba-schema (新建技能)     │
+              │                            │
+              └─────────────┬──────────────┘
+                            │
+                            ▼
+              ┌────────────────────────────┐
+              │                            │
+              │  ux-prototype (新建技能)   │
+              │                            │
+              └─────────────┬──────────────┘
+                            │
+                            ▼
+              ┌────────────────────────────┐
+              │                            │
+              │   design-review (現有技能)  │
+              │                            │
+              └─────────────┬──────────────┘
+                            │
+                            │ 失敗退回 PRD
+                            │
+                            ▼
+    ┌─────────────────────────────────────────┐
+    │                                         │
+    │ dispatching-parallel-agents (現有技能)  │
+    │                                         │
+    └────────────────┬────────────────────────┘│
+                     │
+                     ▼
+              ┌──────────────┐
+              │              │
+              │ 前端實作      │
+              │              │
+              └──────┬───────┘
+                     │        ┌──────────────┐
+                     │        │              │
+                     └───────▶│  後端實作     │
+                              │              │
+                              └──────┬───────┘
+                                     │
+                                     ▼
+              ┌────────────────────────────────┐
+              │                                │
+              │        qa (現有技能)             │
+              │                                │
+              └─────────────┬──────────────────┘
+                            │
+                            │ 失敗退回 Task Breakdown
+                            │
+                            ▼
+              ┌────────────────────────────────┐
+              │                                │
+              │     review (現有技能)           │
+              │                                │
+              └─────────────┬──────────────────┘
+                            │
+                            │ 失敗退回 Task Breakdown
+                            │
+                            ▼
+              ┌────────────────────────────────┐
+              │                                │
+              │   land-and-deploy (現有技能)    │
+              │                                │
+              └────────────────┬───────────────┘
+                                │
+                                ▼
+                          ┌──────────┐
+                          │          │
+                          │   完成   │
+                          │          │
+                          └──────────┘
+```
+
+---
+
+## 技能分類
+
+### 現有技能 (可直接使用)
+
+| 技能名稱 | 位置 | 用途 |
+|---------|------|------|
+| `brainstorming` | skills/ | PM 需求探索 |
+| `plan-ceo-review` | gstack/| CEO 商業價值審核 |
+| `design-review` | gstack/| 設計審核 |
+| `dispatching-parallel-agents` | skills/ | 任務平行拆分 |
+| `qa` | gstack/ | QA 測試驗收 |
+| `review` | gstack/ | PR 代碼審核 |
+| `land-and-deploy` | gstack/ | 部署流程 |
+
+### 新建技能 (需要實作)
+
+| 技能名稱 | 位置 | 用途 |
+|---------|------|------|
+| `vibe-kanban`| skills/ | 主控協調器 |
+| `pm-prd` | skills/ | PRD 撰寫 |
+| `be-api-design` | skills/ | API 設計 |
+| `dba-schema` | skills/ | 資料庫規劃 |
+| `ux-prototype` | skills/ | UX 原型 |
+
+---
+
+## 詳細依賴關係
+
+### Stage 1: Brainstorming
+
+```yaml
+技能: brainstorming
+類型: 現有
+輸入:
+  - 使用者輸入的想法
+  - 專案上下文 (CLAUDE.md, README.md 等)
+輸出:
+  - docs/brainstorm/{date}-{feature}.md
+依賴: 無
+觸發: vibe-kanban (主控)
+```
+
+### Stage 2: CEO Review
+
+```yaml
+技能: plan-ceo-review
+類型: 現有
+輸入:
+  - docs/brainstorm/{date}-{feature}.md
+輸出:
+  - docs/ceo-review/{date}-{feature}.md
+  - 審核報告
+依賴:
+  - brainstorming (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 brainstorming
+```
+
+### Stage 3: PRD
+
+```yaml
+技能: pm-prd
+類型: 新建
+輸入:
+  - docs/brainstorm/{date}-{feature}.md
+  - docs/ceo-review/{date}-{feature}.md
+輸出:
+  - docs/prd/{date}-{feature}.md
+依賴:
+  - brainstorming (必須完成)
+  - plan-ceo-review (必須通過)
+觸發: vibe-kanban (主控)
+退回: 可退回 ceo-review
+```
+
+### Stage 4: API Design
+
+```yaml
+技能: be-api-design
+類型: 新建
+輸入:
+  - docs/prd/{date}-{feature}.md
+輸出:
+  - docs/api/{date}-{feature}.yaml
+依賴:
+  - pm-prd (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 pm-prd
+```
+
+### Stage 5: DB Schema
+
+```yaml
+技能: dba-schema
+類型: 新建
+輸入:
+  - docs/api/{date}-{feature}.yaml
+  - docs/prd/{date}-{feature}.md
+輸出:
+  - docs/db/{date}-{feature}.sql
+  - docs/db/migrations/{version}-{description}.sql
+依賴:
+  - be-api-design (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 be-api-design
+```
+
+### Stage 6: UX Prototype
+
+```yaml
+技能: ux-prototype
+類型: 新建
+輸入:
+  - docs/prd/{date}-{feature}.md
+  - docs/api/{date}-{feature}.yaml
+  - docs/db/{date}-{feature}.sql
+輸出:
+  - docs/design/{date}-{feature}/user-flow.md
+  - docs/design/{date}-{feature}/wireframes/
+  - docs/design/{date}-{feature}/prototype-link.md
+依賴:
+  - dba-schema (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 dba-schema
+```
+
+### Stage 7: Design Review
+
+```yaml
+技能: design-review
+類型: 現有
+輸入:
+  - docs/design/{date}-{feature}/
+輸出:
+  - docs/design/{date}-{feature}/review-report.md
+依賴:
+  - ux-prototype (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 pm-prd (設計與需求不符)
+```
+
+### Stage 8: Task Breakdown
+
+```yaml
+技能: dispatching-parallel-agents-doc
+類型: 現有
+輸入:
+  - docs/prd/{date}-{feature}.md
+  - docs/api/{date}-{feature}.yaml
+  - docs/design/{date}-{feature}/
+輸出:
+  - .gstack/kanban/{project}/tasks.md
+  - 任務分配
+依賴:
+  - design-review (必須通過)
+觸發: vibe-kanban (主控)
+退回: 無
+```
+
+### Stage 9: Implementation
+
+```yaml
+技能: 無 (手動或使用 writing-plans)
+類型: 手動
+輸入:
+  - .gstack/kanban/{project}/tasks.md
+輸出:
+  - 程式碼
+  - 單元測試
+依賴:
+  - dispatching-parallel-agents-doc (必須完成)
+觸發: 開發者手動
+退回: 無
+```
+
+### Stage 10: QA
+
+```yaml
+技能: qa
+類型: 現有
+輸入:
+  - 程式碼
+  - docs/prd/{date}-{feature}.md (驗收標準)
+輸出:
+  - .gstack/qa-reports/qa-report-{date}.md
+依賴:
+  -實作 (必須完成)
+觸發: vibe-kanban (主控)
+退回: 可退回 dispatching-parallel-agents-doc (步驟四)
+```
+
+### Stage 11: PR Review
+
+```yaml
+技能: review
+類型: 現有
+輸入:
+  - PR (程式碼變更)
+輸出:
+  -PR 審核報告
+依賴:
+  - qa (必須通過)
+觸發: vibe-kanban (主控)
+退回: 可退回 dispatching-parallel-agents-doc (步驟四)
+```
+
+### Stage 12: Deploy
+
+```yaml
+技能: land-and-deploy
+類型: 現有
+輸入:
+  - 已核准的 PR
+輸出:
+  - .gstack/deploy-reports/deploy-report-{date}.md
+依賴:
+  - review (必須通過)
+觸發: vibe-kanban (主控)
+退回: 無 (部署失敗可重新部署)
+```
+
+---
+
+## 退回路徑總覽
+
+```yaml
+退回路徑:
+  - from: CEO_REVIEW
+    to: BRAINSTORM
+    reason: "商業價值不足或需求不清"
+    
+  - from: PRD
+    to: CEO_REVIEW
+    reason: "PRD 與 CEO 審核不符"
+    
+  - from: API_DESIGN
+    to: PRD
+    reason: "API 設計與需求不符"
+    
+  - from: DB_SCHEMA
+    to: API_DESIGN
+    reason: "資料結構與 API 衝突"
+    
+  - from: UX_PROTOTYPE
+    to: DB_SCHEMA
+    reason: "原型與資料結構不符"
+    
+  - from: DESIGN_REVIEW
+    to: PRD
+    reason: "設計與需求不符"
+    
+  - from: QA
+    to: TASK_BREAKDOWN
+    reason: "測試不通過"
+    
+  - from: PR_REVIEW
+    to: TASK_BREAKDOWN
+    reason: "代碼審核不通過"
+    
+  - from: DEPLOY
+    to: IMPLEMENTATION
+    reason: "部署失敗"
+```
+
+---
+
+## 檔案流向圖
+
+```
+使用者輸入
+    │
+    ▼
+docs/brainstorm/{date}-{feature}.md
+    │
+    ▼
+docs/ceo-review/{date}-{feature}.md
+    │
+    ▼
+docs/prd/{date}-{feature}.md
+    │
+    ├──▶ docs/api/{date}-{feature}.yaml
+    │         │
+    │         └──▶ docs/db/{date}-{feature}.sql
+    │                  │
+    │                  └──▶ docs/design/{date}-{feature}/
+    │                            │
+    │                            └──▶ docs/design/{date}-{feature}/review-report.md
+    │
+    └──▶ .gstack/kanban/{project}/tasks.md
+              │
+              └──▶ 程式碼
+                      │
+                      ├──▶ .gstack/qa-reports/qa-report-{date}.md
+                      │
+                      ├──▶ PR (代碼變更)
+                      │
+                      └──▶ .gstack/deploy-reports/deploy-report-{date}.md
+```
+
+---
+
+## 版本控制建議
+
+### 應納入版本控制的檔案
+
+```
+.gstack/kanban/{project}/state.yaml  # 工作流狀態
+docs/brainstorm/                      # 需求探索文件
+docs/prd/                              # PRD 文件
+docs/api/                              # API 規格
+docs/db/                               # 資料庫設計
+docs/design/                           # 設計文件
+.gstack/qa-reports/                    # QA 報告
+.gstack/deploy-reports/                # 部署報告
+```
+
+### 不應納入版本控制的檔案
+
+```
+.gstack/tmp/                           # 暫存檔案
+node_modules/                          # 依賴
+*.log                                  # 日誌檔案
+```
+
+---
+
+## 授權和稽核
+
+### 每個階段的授權需求
+
+| 階段 | 需要授權 | 授權者 |
+|------|---------|--------|
+| BRAINSTORM | 否 | - |
+| CEO_REVIEW | 是 | CEO/決策者 |
+| PRD | 是 | PM |
+| API_DESIGN | 是 | 後端負責人 |
+| DB_SCHEMA | 是 | DBA |
+| UX_PROTOTYPE | 是 | UX 設計師 |
+| DESIGN_REVIEW | 是 | 設計審核者 |
+| TASK_BREAKDOWN | 否 | - |
+| IMPLEMENTATION | 否 | - |
+| QA | 否 | - |
+| PR_REVIEW | 是 | 代碼審核者 |
+| DEPLOY | 否 | - |
+
+---
+
+## 效能考量
+
+### 平行執行機會
+
+```yaml
+可平行執行:
+  - API_DESIGN + DB_SCHEMA (可同時進行)
+  - 前端實作 + 後端實作 (可同時進行)
+
+不可平行執行:
+  - BRAINSTORM → CEO_REVIEW (必須順序)
+  - PRD → API_DESIGN (必須順序)
+  - QA → PR_REVIEW → DEPLOY (必須順序)
+```
+
+### 快取策略
+
+```yaml
+可快取:
+  - 專案上下文 (CLAUDE.md, README.md)
+  - 現有 API 規格
+  - 現有資料庫 Schema
+
+不可快取:
+  - 當前階段的輸出
+  - 狀態檔案
+```

design-idea/VIBE_KANBAN_INTEGRATION_PLAN.md

@@ -0,0 +1,440 @@
+# Vibe-Kanban 工作流程 - 技能整合規劃
+
+**版本**: 3.0  
+**日期**: 2025-01-15  
+**狀態**: 實施階段
+
+---
+
+## 執行摘要
+
+本規劃整合多個現有技能，建立完整的軟體開發工作流程。
+
+**總計**: 11 個現有技能 + 5 個新建技能  
+**Agent**: 8 個核心 Agent + 1 個主控協調器  
+**階段**: 12 個工作流程階段
+
+---
+
+## 現有技能整合清單
+
+### 核心技能（直接使用）
+
+| Skill | 來源 | 用途 | 整合階段 |
+|-------|------|------|---------|
+| `brainstorming` | skills | PM 需求探索 | Stage 1 |
+| `plan-ceo-review` | gstack | CEO 商業價值審核 | Stage 2 |
+| `write-a-prd` | skills | PRD 撰寫（含訪談） | Stage 3 |
+| `grill-me` | skills | **深度驗證閘門** | Stage 3.5 |
+| `prd-to-plan` | skills | 實作計畫產出 | Stage 8 |
+| `design-an-interface` | skills | API 介面設計 | Stage 4 |
+| `tdd` | skills | 測試驅動開發 | Stage 9 |
+| `qa` | skills | QA 測試驗收 | Stage 10 |
+| `review` | gstack | PR 代碼審核 | Stage 11 |
+| `land-and-deploy` | gstack | 部署流程 | Stage 12 |
+| `cso` | gstack | 安全審核 | Stage 7/11 |
+| `codex` | gstack | 多 AI 代碼審核 | Stage 11 |
+
+### 新增技能（需實作）
+
+| Skill | 用途 | 優先級 |
+|-------|------|--------|
+| `vibe-kanban` | **主控協調器** | P0 |
+| `be-api-design` | OpenAPI 規格產出 | P1 |
+| `go-backend-dev` | **Golang 後端實作** | P1 |
+| `dba-schema` | 資料庫 Schema 設計 | P1 |
+| `ux-prototype` | UX 原型設計 | P2 |
+
+---
+
+## Agent 角色定義
+
+| # | Agent | 角色 | 主要技能 |
+|---|-------|------|---------|
+| 1 | **Orchestrator** | 主控協調器 | `vibe-kanban` |
+| 2 | **PM Agent** | 產品經理 | `brainstorming`, `write-a-prd` |
+| 3 | **CEO Reviewer** | 商業決策者 | `plan-ceo-review` |
+| 4 | **Backend Agent** | Golang 後端工程師 | `be-api-design`, `go-backend-dev`, `design-an-interface`, `tdd` |
+| 5 | **DBA Agent** | 資料庫工程師 | `dba-schema` |
+| 6 | **UX Agent** | 使用者體驗設計師 | `ux-prototype` |
+| 7 | **QA Agent** | 品質保證工程師 | `qa` |
+| 8 | **DevOps Agent** | 運維工程師 | `land-and-deploy` |
+| 9 | **Design Reviewer** | 設計審核者 | `design-review` |
+| 10 | **Security Reviewer** | 安全審核者 | `cso` |
+| 11 | **Code Reviewer** | 代碼審核者 | `review`, `codex` |
+
+---
+
+## 完整工作流程（含 Grill-Me 整合）
+
+```
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                      VIBE-KANBAN + GRILL-ME 工作流程                         │
+└─────────────────────────────────────────────────────────────────────────────┘
+
+Stage 1: Brainstorming (PM Agent)
+├── Skill: brainstorming
+├── 輸入: 使用者想法
+├── 輸出: docs/brainstorm/{date}-{feature}.md
+└── 下一步: CEO Review
+
+Stage 2: CEO Review (CEO Reviewer)
+├── Skill: plan-ceo-review
+├── 輸入: Brainstorm 文件
+├── 輸出: docs/ceo-review/{date}-{feature}.md
+└── 下一步: PRD 撰寫
+
+Stage 3: PRD 撰寫 (PM Agent)
+├── Skill: write-a-prd
+├── 輸入: CEO Review 結果
+├── 輸出: docs/prd/{date}-{feature}.md (初版)
+└── 下一步: 深度驗證 (可選)
+
+Stage 3.5: 深度驗證 ⭐ GRILL-ME 整合點
+├── Skill: grill-me
+├── 觸發條件: 使用者選擇 "進行深度驗證"
+├── 輸入: PRD 初版
+├── 驗證項目:
+│   ├── 每個功能性需求的完整性
+│   ├── 使用者故事的邊界情況
+│   ├── 非功能性需求的遺漏
+│   ├── 驗收標準的可測試性
+│   └── 潛在風險和依賴
+├── 輸出: 強化後的 PRD
+└── 下一步: API Design
+
+Stage 4: API Design (Backend Agent)
+├── Skill: be-api-design + design-an-interface
+├── 輸入: PRD
+├── 輸出: docs/api/{date}-{feature}.yaml
+└── 下一步: DB Schema (平行)
+
+Stage 5: DB Schema (DBA Agent)
+├── Skill: dba-schema
+├── 輸入: API 規格
+├── 輸出: docs/db/{date}-{feature}.sql
+└── 下一步: UX Prototype (平行)
+
+Stage 6: UX Prototype (UX Agent)
+├── Skill: ux-prototype
+├── 輸入: PRD + API + DB
+├── 輸出: docs/design/{date}-{feature}/
+└── 下一步: Design Review
+
+Stage 7: Design Review (Design Reviewer)
+├── Skill: design-review
+├── 輸入: 所有設計文件
+├── 輸出: docs/design/review-report.md
+├── 決策點:
+│   ├── ✅ 通過 → Task Breakdown
+│   └── ❌ 退回 → PRD 修改
+└── 下一步: Task Breakdown
+
+Stage 8: Task Breakdown (Orchestrator)
+├── Skill: prd-to-plan
+├── 輸入: 所有設計文件
+├── 輸出: ./plans/{feature}.md
+└── 下一步: 實作 (平行)
+
+Stage 9: Implementation (Backend + Frontend Agents)
+├── Backend Skill: go-backend-dev + tdd
+├── Frontend Skill: (現有技能或手動)
+├── 輸入: 實作計畫
+├── 輸出: 程式碼
+└── 下一步: QA
+
+Stage 10: QA (QA Agent)
+├── Skill: qa
+├── 輸入: 程式碼 + 驗收標準
+├── 輸出: .gstack/qa-reports/qa-report.md
+├── 決策點:
+│   ├── ✅ 通過 → PR Review
+│   └── ❌ 失敗 → 退回 Task Breakdown
+└── 下一步: PR Review
+
+Stage 11: PR Review (Code Reviewer)
+├── Skill: review + codex
+├── 輸入: PR
+├── 輸出: PR 審核報告
+├── 決策點:
+│   ├── ✅ 通過 → Deploy
+│   └── ❌ 失敗 → 退回 Task Breakdown
+└── 下一步: Deploy
+
+Stage 12: Deploy (DevOps Agent)
+├── Skill: land-and-deploy
+├── 輸入: 已核准 PR
+├── 輸出: .gstack/deploy-reports/deploy-report.md
+└── 🎉 完成
+```
+
+---
+
+## Grill-Me 深度驗證詳細設計
+
+### 觸發機制
+
+在每個關鍵階段後，Orchestrator 會詢問：
+
+```
+╔══════════════════════════════════════════════════════════════╗
+║                    🔥 深度驗證機會                            ║
+╠══════════════════════════════════════════════════════════════╣
+║                                                              ║
+║  當前階段: PRD 撰寫                                          ║
+║  狀態: ✅ 初版已完成                                          ║
+║                                                              ║
+║  是否需要進行深度驗證 (grill-me)？                             ║
+║  這將透過密集訪談壓力測試計畫的完整性。                         ║
+║                                                              ║
+║  [A] 是 - 進行深度驗證 (推薦用於關鍵功能)                      ║
+║  [B] 否 - 直接進入下一階段                                    ║
+║                                                              ║
+╚══════════════════════════════════════════════════════════════╝
+```
+
+### 驗證檢查清單
+
+#### Stage 3.5 - PRD 深度驗證
+
+```yaml
+驗證項目:
+  功能性需求:
+    - "每個 FR 是否有明確的驗收標準？"
+    - "使用者故事是否覆蓋所有使用者角色？"
+    - "是否有遺漏的邊界情況？"
+    
+  非功能性需求:
+    - "效能需求是否具體可量測？"
+    - "安全性需求是否完整？"
+    - "可用性和可靠性是否考量？"
+    
+  技術可行性:
+    - "現有技術棧是否支援？"
+    - "是否有外部依賴風險？"
+    - "擴展性是否考量？"
+    
+  業務邏輯:
+    - "所有業務規則是否明確？"
+    - "錯誤處理流程是否定義？"
+    - "狀態轉換是否清晰？"
+```
+
+### 整合流程圖
+
+```mermaid
+graph TD
+    A[Stage 3: PRD 初版] --> B{深度驗證?}
+    B -->|是| C[Stage 3.5: grill-me]
+    B -->|否| D[Stage 4: API Design]
+    
+    C --> C1[問題 1: 需求完整性]
+    C1 --> C2[問題 2: 邊界情況]
+    C2 --> C3[問題 3: 風險評估]
+    C3 --> C4[...更多問題]
+    C4 --> E[強化 PRD]
+    
+    E --> D
+    
+    D --> F[後續階段]
+```
+
+---
+
+## 各階段交付文件
+
+| 階段 | Agent | 主要技能 | 輔助技能 | 交付文件 |
+|------|-------|---------|---------|---------|
+| 1 | PM | brainstorming | - | `docs/brainstorm/{date}-{feature}.md` |
+| 2 | CEO Reviewer | plan-ceo-review | - | `docs/ceo-review/{date}-{feature}.md` |
+| 3 | PM | write-a-prd | - | `docs/prd/{date}-{feature}.md` (初版) |
+| 3.5 | PM | **grill-me** | - | `docs/prd/{date}-{feature}.md` (強化版) |
+| 4 | Backend | be-api-design | design-an-interface | `docs/api/{date}-{feature}.yaml` |
+| 5 | DBA | dba-schema | - | `docs/db/{date}-{feature}.sql` |
+| 6 | UX | ux-prototype | - | `docs/design/{date}-{feature}/` |
+| 7 | Design Reviewer | design-review | cso | `docs/design/review-report.md` |
+| 8 | Orchestrator | prd-to-plan | dispatching-parallel-agents | `./plans/{feature}.md` |
+| 9 | Backend | go-backend-dev | tdd | `internal/`, `cmd/`, `pkg/` |
+| 10 | QA | qa | - | `.gstack/qa-reports/qa-report.md` |
+| 11 | Code Reviewer | review | codex | PR 審核報告 |
+| 12 | DevOps | land-and-deploy | - | `.gstack/deploy-reports/deploy-report.md` |
+
+---
+
+## 技能依賴關係
+
+```yaml
+技能依賴:
+  brainstorming:
+    輸入: 使用者想法
+    輸出: brainstorm.md
+    
+  plan-ceo-review:
+    輸入: brainstorm.md
+    輸出: ceo-review.md
+    
+  write-a-prd:
+    輸入: ceo-review.md
+    輸出: prd.md (初版)
+    
+  grill-me:  # 可選
+    輸入: prd.md (初版)
+    輸出: prd.md (強化版)
+    依賴: write-a-prd
+    
+  be-api-design:
+    輸入: prd.md
+    輸出: api-spec.yaml
+    輔助: design-an-interface
+    
+  dba-schema:
+    輸入: api-spec.yaml
+    輸出: schema.sql
+    
+  ux-prototype:
+    輸入: prd.md, api-spec.yaml, schema.sql
+    輸出: design/
+    
+  design-review:
+    輸入: design/
+    輸出: review-report.md
+    
+  prd-to-plan:
+    輸入: prd.md, api-spec.yaml, design/
+    輸出: ./plans/{feature}.md
+    
+  go-backend-dev:
+    輸入: ./plans/{feature}.md
+    輸出: 程式碼
+    輔助: tdd
+    
+  qa:
+    輸入: 程式碼, prd.md (驗收標準)
+    輸出: qa-report.md
+    
+  review:
+    輸入: PR
+    輸出: pr-review.md
+    輔助: codex
+    
+  land-and-deploy:
+    輸入: pr-review.md (已核准)
+    輸出: deploy-report.md
+```
+
+---
+
+## Golang 後端特定規則（go-backend-dev）
+
+### 架構風格
+
+```yaml
+預設架構: Clean Architecture (適合中型專案)
+
+專案結構:
+  cmd/api/main.go              # 進入點
+  internal/
+    domain/                    # Entities, Value Objects
+    usecase/                   # Business Logic
+    interface/
+      http/                   # Handlers
+      repository/             # Repository interfaces
+    infrastructure/           # DB, Cache implementations
+  pkg/
+    logger/                   # Zap
+    errors/                   # 自定義錯誤
+    validator/                # go-playground/validator
+  api/openapi.yaml
+  migrations/
+  test/
+```
+
+### 編碼規範
+
+```yaml
+命名:
+  Package: 小寫單數 (user, not users)
+  Interface: 方法名 + 'er' (Reader, Writer)
+  Exported: PascalCase
+  Internal: camelCase
+
+錯誤處理:
+  - Always check errors
+  - Error strings lowercase
+  - Use fmt.Errorf with %w
+  
+API 設計:
+  RESTful: /api/v1/{resource}
+  狀態碼: 200, 201, 400, 401, 404, 422, 500
+  
+測試:
+  - Unit tests >= 80% 覆蓋率
+  - Integration tests for critical paths
+  - Use testify + mockery
+```
+
+---
+
+## 實作優先順序
+
+### Phase 1: 核心框架 (Week 1)
+
+| 優先級 | Skill | 複雜度 | 說明 |
+|-------|-------|--------|------|
+| P0 | vibe-kanban | 高 | 主控協調器，整合所有技能 |
+| P0 | grill-me 整合 | 中 | 設計深度驗證流程 |
+
+### Phase 2: 設計階段技能 (Week 2)
+
+| 優先級 | Skill | 複雜度 | 說明 |
+|-------|-------|--------|------|
+| P1 | be-api-design | 中 | OpenAPI 規格產出 |
+| P1 | go-backend-dev | 高 | **Golang 後端實作** |
+| P1 | dba-schema | 中 | 資料庫設計 |
+
+### Phase 3: 整合測試 (Week 3)
+
+- 整合所有現有技能
+- 端到端流程測試
+- 退回機制測試
+
+### Phase 4: 優化 (Week 4)
+
+- 效能優化
+- 文件完善
+- 使用指南
+
+---
+
+## 附錄
+
+### A. 技術棧建議
+
+**Golang 後端**:
+- 框架: Gin 或 Echo
+- ORM: GORM 或 sqlx
+- 配置: Viper
+- 日誌: Zap
+- 驗證: go-playground/validator
+- 測試: testify + mockery
+- 文件: swag (Swagger)
+
+**資料庫**:
+- 主要: PostgreSQL
+- 快取: Redis
+- 遷移: golang-migrate/migrate
+
+**部署**:
+- 容器: Docker
+- CI/CD: GitHub Actions
+
+### B. 參考資源
+
+1. [Uber Go Style Guide](https://github.com/uber-go/guide)
+2. [golang-standards/project-layout](https://github.com/golang-standards/project-layout)
+3. [Go Clean Architecture](https://github.com/bxcodec/go-clean-arch)
+4. [A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php) (for grill-me 概念)
+
+---
+
+**下一步**: 開始實作 `vibe-kanban` 主控技能？

design-idea/struct.md

@@ -0,0 +1,115 @@
+.
+├── build
+│   └── Dockerfile
+├── docker-compose.yml
+├── etc
+│   └── member.example.yaml
+├── generate
+│   └── protobuf
+│       └── member.proto
+├── go.mod
+├── internal
+│   ├── config
+│   │   └── config.go
+│   ├── logic
+│   │   └── account
+│   │       ├── bind_account_logic.go
+│   │       ├── bind_user_info_logic.go
+│   │       ├── bind_verify_email_logic.go
+│   │       ├── bind_verify_phone_logic.go
+│   │       ├── check_refresh_code_logic.go
+│   │       ├── create_user_account_logic.go
+│   │       ├── generate_refresh_code_logic.go
+│   │       ├── get_u_i_d_by_account_logic.go
+│   │       ├── get_user_account_info_logic.go
+│   │       ├── get_user_info_logic.go
+│   │       ├── line_code_to_access_token_logic.go
+│   │       ├── line_get_profile_by_access_token_logic.go
+│   │       ├── list_member_logic.go
+│   │       ├── update_status_logic.go
+│   │       ├── update_user_info_logic.go
+│   │       ├── update_user_token_logic.go
+│   │       ├── verify_google_auth_result_logic.go
+│   │       ├── verify_platform_auth_result_logic.go
+│   │       └── verify_refresh_code_logic.go
+│   ├── server
+│   │   └── account
+│   │       └── account_server.go
+│   └── svc
+│       └── service_context.go
+├── Makefile
+├── member.go
+├── pkg
+│   ├── domain
+│   │   ├── config
+│   │   │   └── config.go
+│   │   ├── const.go
+│   │   ├── entity
+│   │   │   ├── account_uid_table.go
+│   │   │   ├── account.go
+│   │   │   ├── auto_id.go
+│   │   │   └── user.go
+│   │   ├── errors.go
+│   │   ├── member
+│   │   │   ├── account_type_test.go
+│   │   │   ├── account_type.go
+│   │   │   ├── alert_type_test.go
+│   │   │   ├── alert_type.go
+│   │   │   ├── generate_code_type_test.go
+│   │   │   ├── generate_code_type.go
+│   │   │   ├── platform_test.go
+│   │   │   ├── platform.go
+│   │   │   ├── status_test.go
+│   │   │   └── status.go
+│   │   ├── redis.go
+│   │   ├── repository
+│   │   │   ├── account_uid.go
+│   │   │   ├── account.go
+│   │   │   ├── auto_id.go
+│   │   │   ├── user.go
+│   │   │   └── verify_code.go
+│   │   └── usecase
+│   │       ├── account.go
+│   │       ├── common.go
+│   │       ├── generate_uid.go
+│   │       └── verify.go
+│   ├── mock
+│   │   ├── repository
+│   │   │   ├── account_uid.go
+│   │   │   ├── account.go
+│   │   │   ├── auto_id.go
+│   │   │   ├── user.go
+│   │   │   └── verify_code.go
+│   │   └── usecase
+│   │       └── generate_uid.go
+│   ├── repository
+│   │   ├── account_test.go
+│   │   ├── account_uid_test.go
+│   │   ├── account_uid.go
+│   │   ├── account.go
+│   │   ├── auto_id_test.go
+│   │   ├── auto_id.go
+│   │   ├── error.go
+│   │   ├── start_mongo_container_test.go
+│   │   ├── user_test.go
+│   │   ├── user.go
+│   │   ├── verify_code_test.go
+│   │   └── verify_code.go
+│   └── usecase
+│       ├── account.go
+│       ├── binding_test.go
+│       ├── binding.go
+│       ├── generate_test.go
+│       ├── generate_verify_code_utils_test.go
+│       ├── generate_verify_code_utils.go
+│       ├── generate.go
+│       ├── member_test.go
+│       ├── member.go
+│       ├── password_utils_test.go
+│       ├── password_utils.go
+│       ├── verify_google_test.go
+│       ├── verify_google.go
+│       ├── verify_line.go
+│       ├── verify_test.go
+│       └── verify.go
+└── readme.md

skills/be-api-design/SKILL.md

@@ -0,0 +1,532 @@
+---
+name: be-api-design
+description: "Backend Agent uses this skill to design API specs. Based on PRD, produce OpenAPI 3.0 spec including endpoints, request/response structures, error handling. Trigger: After PRD approved (Stage 4)."
+---
+
+# /be-api-design — API Design
+
+Backend Agent uses this skill to design API specs.
+
+## Responsibilities
+
+1. Analyze functional requirements from PRD
+2. Use `design-an-interface` to explore multiple API design options
+3. Design RESTful API endpoints
+4. Define request/response schemas
+5. Design error handling mechanism
+6. Produce OpenAPI 3.0 spec
+
+## Input
+
+- PRD document (`docs/prd/{date}-{feature}.md`)
+- Existing API style (existing API specs in project)
+- Data model context
+
+## Output
+
+- API spec document: `docs/api/{date}-{feature}.yaml` (OpenAPI 3.0)
+
+## Flow
+
+```
+Read PRD
+    ↓
+Identify resources and operations
+    ↓
+Call design-an-interface to explore 2-3 design options
+    ↓
+Select best option
+    ↓
+Define OpenAPI Schema
+    ↓
+Design error handling
+    ↓
+Security review
+    ↓
+Produce OpenAPI document
+```
+
+### Step Details
+
+**1. Read PRD**
+
+Extract all functional requirements from PRD, identify:
+- Resources (nouns): users, orders, products, etc.
+- Operations (verbs): create, read, update, delete, etc.
+- Relationships: relationships between resources (one-to-many, many-to-many)
+- Non-functional requirements: pagination, rate limiting, authentication, etc.
+
+**2. Identify Resources and Operations**
+
+Map functional requirements to RESTful resources:
+- Each noun → potential resource
+- Each verb → HTTP method
+- Each relationship → nested resource or standalone endpoint
+
+**3. Call design-an-interface**
+
+Use `design-an-interface` skill to generate 2-3 distinct API design options:
+- Option A: Minimize method count (1-3 endpoints per resource)
+- Option B: Maximize flexibility (support multiple use cases)
+- Option C: Optimize for most common operations
+
+Compare pros and cons, select best design.
+
+**4. Define OpenAPI Schema**
+
+Use template below to produce complete OpenAPI 3.0 spec.
+
+**5. Security Review**
+
+Ensure all endpoints have appropriate authentication and permission controls.
+
+**6. Produce Document**
+
+Save to `docs/api/{date}-{feature}.yaml`.
+
+## Design Principles
+
+### RESTful Design
+
+```yaml
+Resource-oriented:
+  - URL represents resource, not action
+  - HTTP methods represent actions
+
+Example:
+  GET    /api/v1/users              # List users
+  GET    /api/v1/users/{id}         # Get specific user
+  POST   /api/v1/users              # Create user
+  PUT    /api/v1/users/{id}         # Full update
+  PATCH  /api/v1/users/{id}         # Partial update
+  DELETE /api/v1/users/{id}         # Delete user
+
+Nested resources:
+  GET    /api/v1/users/{id}/orders  # Get user's orders
+  POST   /api/v1/users/{id}/orders  # Create order for user
+```
+
+### HTTP Status Codes
+
+```yaml
+Success:
+  200: OK                          # GET, PUT, PATCH, DELETE success
+  201: Created                     # POST successfully created resource
+  204: No Content                  # DELETE success, no response body
+
+Client Error:
+  400: Bad Request                 # Request format error
+  401: Unauthorized                # Not authenticated
+  403: Forbidden                   # No permission
+  404: Not Found                   # Resource not found
+  409: Conflict                    # Resource conflict (e.g., duplicate)
+  422: Unprocessable Entity        # Validation error
+  429: Too Many Requests           # Rate limit
+
+Server Error:
+  500: Internal Server Error       # Server internal error
+  502: Bad Gateway                 # Upstream service error
+  503: Service Unavailable         # Service temporarily unavailable
+```
+
+### Response Format
+
+```yaml
+Success response:
+  type: object
+  properties:
+    data:
+      type: object
+    meta:
+      type: object
+      properties:
+        page:
+          type: integer
+        limit:
+          type: integer
+        total:
+          type: integer
+        total_pages:
+          type: integer
+
+Error response:
+  type: object
+  properties:
+    error:
+      type: object
+      properties:
+        code:
+          type: string
+        message:
+          type: string
+        details:
+          type: array
+          items:
+            type: object
+            properties:
+              field:
+                type: string
+              message:
+                type: string
+```
+
+## OpenAPI 3.0 Template
+
+```yaml
+openapi: 3.0.3
+info:
+  title: {API Name}
+  version: 1.0.0
+  description: |
+    {Description}
+
+    Related PRD: {PRD Link}
+
+servers:
+  - url: https://api.example.com/v1
+    description: Production
+  - url: https://staging-api.example.com/v1
+    description: Staging
+
+paths:
+  /users:
+    get:
+      summary: List users
+      tags:
+        - Users
+      parameters:
+        - name: page
+          in: query
+          schema:
+            type: integer
+            default: 1
+        - name: limit
+          in: query
+          schema:
+            type: integer
+            default: 20
+            maximum: 100
+        - name: search
+          in: query
+          schema:
+            type: string
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserListResponse'
+        '401':
+          $ref: '#/components/responses/Unauthorized'
+        '500':
+          $ref: '#/components/responses/InternalError'
+
+    post:
+      summary: Create user
+      tags:
+        - Users
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/CreateUserRequest'
+      responses:
+        '201':
+          description: Created successfully
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '400':
+          $ref: '#/components/responses/BadRequest'
+        '422':
+          $ref: '#/components/responses/ValidationError'
+
+  /users/{id}:
+    parameters:
+      - name: id
+        in: path
+        required: true
+        schema:
+          type: string
+
+    get:
+      summary: Get user
+      tags:
+        - Users
+      responses:
+        '200':
+          description: Success
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '404':
+          $ref: '#/components/responses/NotFound'
+
+    put:
+      summary: Full update user
+      tags:
+        - Users
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/UpdateUserRequest'
+      responses:
+        '200':
+          description: Updated successfully
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '404':
+          $ref: '#/components/responses/NotFound'
+        '422':
+          $ref: '#/components/responses/ValidationError'
+
+    patch:
+      summary: Partial update user
+      tags:
+        - Users
+      requestBody:
+        required: true
+        content:
+          application/json:
+            schema:
+              $ref: '#/components/schemas/PatchUserRequest'
+      responses:
+        '200':
+          description: Updated successfully
+          content:
+            application/json:
+              schema:
+                $ref: '#/components/schemas/UserResponse'
+        '404':
+          $ref: '#/components/responses/NotFound'
+
+    delete:
+      summary: Delete user
+      tags:
+        - Users
+      responses:
+        '204':
+          description: Deleted successfully
+        '404':
+          $ref: '#/components/responses/NotFound'
+
+components:
+  schemas:
+    User:
+      type: object
+      properties:
+        id:
+          type: string
+          example: "usr_123456"
+        email:
+          type: string
+          format: email
+          example: "user@example.com"
+        name:
+          type: string
+          example: "John Doe"
+        status:
+          type: string
+          enum: [active, inactive, suspended]
+          example: "active"
+        created_at:
+          type: string
+          format: date-time
+        updated_at:
+          type: string
+          format: date-time
+      required:
+        - id
+        - email
+        - name
+        - status
+        - created_at
+        - updated_at
+
+    CreateUserRequest:
+      type: object
+      properties:
+        email:
+          type: string
+          format: email
+        password:
+          type: string
+          minLength: 8
+        name:
+          type: string
+          minLength: 1
+          maxLength: 100
+      required:
+        - email
+        - password
+        - name
+
+    UpdateUserRequest:
+      type: object
+      properties:
+        email:
+          type: string
+          format: email
+        name:
+          type: string
+          minLength: 1
+          maxLength: 100
+        status:
+          type: string
+          enum: [active, inactive]
+
+    PatchUserRequest:
+      type: object
+      properties:
+        name:
+          type: string
+          minLength: 1
+          maxLength: 100
+        status:
+          type: string
+          enum: [active, inactive]
+
+    UserResponse:
+      type: object
+      properties:
+        data:
+          $ref: '#/components/schemas/User'
+
+    UserListResponse:
+      type: object
+      properties:
+        data:
+          type: array
+          items:
+            $ref: '#/components/schemas/User'
+        meta:
+          type: object
+          properties:
+            page:
+              type: integer
+            limit:
+              type: integer
+            total:
+              type: integer
+            total_pages:
+              type: integer
+
+    Error:
+      type: object
+      properties:
+        error:
+          type: object
+          properties:
+            code:
+              type: string
+            message:
+              type: string
+            details:
+              type: array
+              items:
+                type: object
+                properties:
+                  field:
+                    type: string
+                  message:
+                    type: string
+
+  responses:
+    BadRequest:
+      description: Request format error
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+
+    Unauthorized:
+      description: Not authenticated
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+
+    NotFound:
+      description: Resource not found
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+
+    ValidationError:
+      description: Validation error
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+
+    InternalError:
+      description: Server internal error
+      content:
+        application/json:
+          schema:
+            $ref: '#/components/schemas/Error'
+
+  securitySchemes:
+    bearerAuth:
+      type: http
+      scheme: bearer
+      bearerFormat: JWT
+
+security:
+  - bearerAuth: []
+```
+
+## Design Checklist
+
+### Security
+- [ ] All endpoints have appropriate authentication
+- [ ] Input validation complete
+- [ ] Rate limiting designed
+- [ ] CORS configured
+
+### Performance
+- [ ] Pagination support
+- [ ] Caching strategy
+- [ ] Batch operation support
+
+### Reliability
+- [ ] Error response format unified
+- [ ] Retry mechanism recommendations
+- [ ] Idempotency design
+
+### Consistency
+- [ ] Naming convention consistent (resources use plural nouns)
+- [ ] Response format consistent (data/meta/error structure)
+- [ ] Filter/sort/pagination parameters consistent
+
+## Related Skills
+
+- **Prerequisite**: `write-a-prd` (after PRD approved)
+- **辅助**: `design-an-interface` (explore multiple design options)
+- **Follow-up**: `dba-schema` (DB Schema design)
+- **Rollback**: Can rollback to `write-a-prd` to modify requirements
+
+## Rollback Mechanism
+
+```
+Design Review rejects API design
+    ↓
+Modify OpenAPI spec
+    ↓
+Re-submit (or re-call design-an-interface)
+
+DBA Agent finds Schema conflict
+    ↓
+Negotiate domain model or API response format adjustments
+    ↓
+Update OpenAPI spec
+```

skills/design-an-interface/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: design-an-interface
+description: "Backend Agent uses this skill to explore multiple API interface design options. Based on 'Design It Twice' principle, generate multiple distinct designs, compare, and select the best option. Trigger: API design phase (Stage 4), called by be-api-design skill."
+---
+
+# /design-an-interface — Interface Design Exploration
+
+Backend Agent uses this skill to explore API interface design options.
+
+Based on "Design It Twice" principle from "A Philosophy of Software Design": The first idea is usually not the best. Generate multiple distinct designs, then compare and choose.
+
+## Responsibilities
+
+1. Generate 2-3 distinct interface design options for module requirements
+2. Each option uses different design constraints
+3. Compare pros and cons of options
+4. Assist in selecting or synthesizing the best option
+
+## Input
+
+- Module description (functional requirements from PRD)
+- User stories and usage scenarios
+
+## Output
+
+- Multiple interface design options (including interface signatures, usage examples, pros/cons analysis)
+- Option comparison and recommendations
+
+## Flow
+
+```
+Collect requirements
+    ↓
+Generate 2-3 design options (parallel sub-agents)
+    ↓
+Present each option
+    ↓
+Compare options (interface simplicity, generality, implementation efficiency, depth)
+    ↓
+Synthesize best option or select most suitable
+```
+
+### Step Details
+
+**1. Collect Requirements**
+
+Before designing, understand:
+- [ ] What problem does this module solve?
+- [ ] Who are the callers? (other modules, external users, tests)
+- [ ] What are the key operations?
+- [ ] What are the constraints? (performance, compatibility, existing patterns)
+- [ ] What should be hidden internally? What should be exposed externally?
+
+Ask: "What does this module need to do? Who will use it?"
+
+**2. Generate Design Options (Parallel Sub-Agents)**
+
+Generate 3+ distinct options simultaneously. Each option must follow different constraints:
+
+```
+Option A: Minimize method count — target 1-3 methods
+Option B: Maximize flexibility — support multiple use cases
+Option C: Optimize for most common operations
+Option D (optional): Reference specific paradigm or framework design
+```
+
+Each option should include:
+1. Interface signature (types/methods)
+2. Usage examples (how callers actually use it)
+3. What complexity this design hides
+4. Trade-offs of this option
+
+**3. Present Options**
+
+Present each option one by one, including:
+- Interface signature: types, methods, params
+- Usage examples: how callers actually use it
+- Hidden complexity: small interface hiding large implementation (good) vs large interface with thin implementation (bad)
+
+Allow user to fully absorb each option before comparison.
+
+**4. Compare Options**
+
+Compare across dimensions:
+
+- **Interface simplicity**: Few methods, simple parameters → Easier to learn and use correctly
+- **Generality vs Specificity**: Flexibility vs focus, where are the trade-offs
+- **Implementation efficiency**: Does interface shape allow efficient internal implementation?
+- **Depth**: Small interface hiding large complexity (deep module, good) vs large interface with thin implementation (shallow module, bad)
+- **Ease of correct usage vs ease of misuse**
+
+Discuss trade-offs in text, not just tables. Emphasize where options diverge most.
+
+**5. Synthesize Best Option**
+
+The best design often combines insights from multiple options. Ask:
+- "Which option fits your primary use case best?"
+- "Are there elements from other options worth incorporating?"
+
+## Evaluation Criteria
+
+From "A Philosophy of Software Design":
+
+**Interface simplicity**: Few methods, simple parameters = Easier to learn and use correctly.
+
+**Generality**: Can handle future use cases without modification. But avoid over-generalization.
+
+**Implementation efficiency**: Does interface shape allow efficient implementation? Or does it force awkward internal implementation?
+
+**Depth**: Small interface hiding large complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).
+
+```
+Deep module (good):
+┌─────────────────────┐
+│   Small Interface   │  ← Few methods, simple parameters
+├─────────────────────┤
+│                     │
+│                     │
+│  Deep Implementation│  ← Complex logic hidden inside
+│                     │
+│                     │
+└─────────────────────┘
+
+Shallow module (avoid):
+┌─────────────────────────────────┐
+│       Large Interface           │  ← Many methods, complex parameters
+├─────────────────────────────────┤
+│  Thin Implementation            │  ← Just a pass-through
+└─────────────────────────────────┘
+```
+
+## Anti-Patterns
+
+- Don't let sub-agents generate similar designs — force distinct ones
+- Don't skip comparison — value comes from contrast
+- Don't implement at this stage — this is pure interface design
+- Don't evaluate options based on implementation effort — only look at interface quality
+
+## Golang Interface Design Examples
+
+```go
+// Option A: Minimize method count
+type UserRepository interface {
+    GetByID(ctx context.Context, id string) (*domain.User, error)
+    Save(ctx context.Context, user *domain.User) error
+}
+// Pros: Simple, easy to mock
+// Cons: Save handles both Create and Update, depends on whether it exists
+
+// Option B: Separate read/write
+type UserReader interface {
+    GetByID(ctx context.Context, id string) (*domain.User, error)
+    List(ctx context.Context, page, limit int) ([]*domain.User, error)
+}
+
+type UserWriter interface {
+    Create(ctx context.Context, user *domain.User) error
+    Update(ctx context.Context, user *domain.User) error
+    Delete(ctx context.Context, id string) error
+}
+// Pros: CQRS friendly, separated concerns
+// Cons: More methods, but each method has clearer semantics
+
+// Option C: Optimize for common operations
+type UserService interface {
+    Register(ctx context.Context, email, password, name string) (*domain.User, error)
+    Authenticate(ctx context.Context, email, password string) (*domain.User, error)
+    GetProfile(ctx context.Context, id string) (*domain.User, error)
+}
+// Pros: Directly maps to business operations, most intuitive
+// Cons: Need to add method for each new operation, less flexible
+```
+
+## Integration with be-api-design
+
+This skill is automatically called by `be-api-design` at step 3. API design flow:
+
+```
+be-api-design step 1: Read PRD
+be-api-design step 2: Identify resources and operations
+→ design-an-interface: Explore 2-3 API design options
+be-api-design step 4: Select option, define OpenAPI spec
+```
+
+## Related Skills
+
+- **Prerequisite**: `write-a-prd` (PRD complete)
+- **Follow-up**: `be-api-design` (API spec definition)

skills/design-patterns/abstract-factory/SKILL.md

@@ -0,0 +1,15 @@
+# Abstract Factory Pattern
+
+## Description
+Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Abstract Factory Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/abstract-factory)

skills/design-patterns/adapter/SKILL.md

@@ -0,0 +1,15 @@
+# Adapter Pattern
+
+## Description
+Convert the interface of a class into another interface that clients expect.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Adapter Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/adapter)

skills/design-patterns/bridge/SKILL.md

@@ -0,0 +1,15 @@
+# Bridge Pattern
+
+## Description
+Decouple an abstraction from its implementation so that the two can vary independently.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Bridge Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/bridge)

skills/design-patterns/builder/SKILL.md

@@ -0,0 +1,15 @@
+# Builder Pattern
+
+## Description
+Separate the construction of a complex object from its representation, allowing the same construction process to create different representations.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Builder Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/builder)

skills/design-patterns/chain-of-responsibility/SKILL.md

@@ -0,0 +1,15 @@
+# Chain of Responsibility Pattern
+
+## Description
+Allow multiple objects to handle the same request.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Chain of Responsibility Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/chain-of-responsibility)

skills/design-patterns/command/SKILL.md

@@ -0,0 +1,15 @@
+# Command Pattern
+
+## Description
+Encapsulate a request as an object, thereby allowing parameterization of clients with different requests.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Command Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/command)

skills/design-patterns/composite/SKILL.md

@@ -0,0 +1,15 @@
+# Composite Pattern
+
+## Description
+Compose objects into tree structures to represent part-whole hierarchies.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Composite Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/composite)

skills/design-patterns/decorator/SKILL.md

@@ -0,0 +1,15 @@
+# Decorator Pattern
+
+## Description
+Dynamically add additional responsibilities to an object.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Decorator Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/decorator)

skills/design-patterns/facade/SKILL.md

@@ -0,0 +1,15 @@
+# Facade Pattern
+
+## Description
+Provide a unified interface to a set of interfaces in a subsystem, hiding the implementation details of the subsystem.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Facade Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/facade)

skills/design-patterns/factory-method/SKILL.md

@@ -0,0 +1,15 @@
+# Factory Method Pattern
+
+## Description
+Define an interface for creating an object, but let subclasses decide which class to instantiate.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Factory Method Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/factory-method)

skills/design-patterns/flyweight/SKILL.md

@@ -0,0 +1,15 @@
+# Flyweight Pattern
+
+## Description
+Use sharing to support large quantities of fine-grained objects efficiently.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Flyweight Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/flyweight)

skills/design-patterns/iterator/SKILL.md

@@ -0,0 +1,15 @@
+# Iterator Pattern
+
+## Description
+Provide a method to sequentially access elements of an aggregate object without exposing its internal representation.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Iterator Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/iterator)

skills/design-patterns/mediator/SKILL.md

@@ -0,0 +1,15 @@
+# Mediator Pattern
+
+## Description
+Use a mediator object to encapsulate a series of class interactions.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Mediator Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/mediator)

skills/design-patterns/memento/SKILL.md

@@ -0,0 +1,15 @@
+# Memento Pattern
+
+## Description
+Capture an object's internal state without violating encapsulation, so that the object can be restored to this state later.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Memento Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/memento)

skills/design-patterns/observer/SKILL.md

@@ -0,0 +1,15 @@
+# Observer Pattern
+
+## Description
+Define a one-to-many dependency relationship so that when one object's state changes, all dependent objects are notified and automatically updated.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Observer Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/observer)

skills/design-patterns/prototype/SKILL.md

@@ -0,0 +1,15 @@
+# Prototype Pattern
+
+## Description
+Use a prototype instance to create other instances.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Prototype Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/prototype)

skills/design-patterns/proxy/SKILL.md

@@ -0,0 +1,15 @@
+# Proxy Pattern
+
+## Description
+Provide a surrogate or placeholder for another object to control access to it.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Proxy Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/proxy)

skills/design-patterns/singleton/SKILL.md

@@ -0,0 +1,15 @@
+# Singleton Pattern
+
+## Description
+Ensure a class has only one instance and provide a global point of access to it.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Singleton Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/singleton)

skills/design-patterns/state/SKILL.md

@@ -0,0 +1,15 @@
+# State Pattern
+
+## Description
+Allow an object to alter its behavior when its internal state changes.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [State Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/state)

skills/design-patterns/strategy/SKILL.md

@@ -0,0 +1,15 @@
+# Strategy Pattern
+
+## Description
+Define a family of algorithms, encapsulate each one, and make them interchangeable.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Strategy Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/strategy)

skills/design-patterns/template-method/SKILL.md

@@ -0,0 +1,15 @@
+# Template Method Pattern
+
+## Description
+Define the skeleton of an operation, deferring some steps to subclasses.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Template Method Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/template-method)

skills/design-patterns/visitor/SKILL.md

@@ -0,0 +1,15 @@
+# Visitor Pattern
+
+## Description
+Without changing the element classes, define new operations that act on these elements.
+
+## Use Cases
+Load this skill when you need to solve design problems described by this pattern in your code.
+
+## Guidelines
+1. Analyze whether current code structure matches the pattern's intent.
+2. Refactor or implement following the pattern's typical structure.
+3. Ensure the pattern introduction reduces coupling or improves flexibility.
+
+## Detailed Reference
+For more details, diagrams, and code examples: [Visitor Pattern - RefactoringGuru](https://refactoringguru.cn/design-patterns/visitor)

skills/go-backend-dev/SKILL.md

@@ -0,0 +1,812 @@
+---
+name: go-backend-dev
+description: "Backend Agent uses this skill to implement Golang backend. Based on implementation plan and API spec, use Domain-Driven + go-zero style architecture and TDD process to produce production-ready code. Trigger: After Task Breakdown complete (Stage 9)."
+---
+
+# /go-backend-dev — Golang Backend Implementation
+
+Backend Agent uses this skill to implement Golang backend.
+
+## Responsibilities
+
+1. Establish project structure based on implementation plan (Domain-Driven + go-zero style)
+2. Implement features using TDD process (Red-Green-Refactor)
+3. Deliver incrementally by vertical slices (end-to-end, not layer-by-layer)
+4. Implement Domain / Usecase / Logic / Repository layers
+5. Write unit tests and integration tests
+
+## Input
+
+- Implementation plan (`./plans/{feature}.md`)
+- API spec (`docs/api/{date}-{feature}.yaml`)
+- DB Schema (`docs/db/{date}-{feature}.sql`)
+
+## Output
+
+- Golang code structure
+- Test code (unit tests >= 80%, business logic >= 90%)
+- Protobuf definitions (if gRPC needed)
+
+## Flow
+
+```
+Read implementation plan + API spec + DB Schema
+    ↓
+Identify vertical slices (each slice = end-to-end feature)
+    ↓
+Execute TDD loop for each slice:
+    ├── RED:   Write test → Test fails
+    ├── GREEN: Write minimal code → Test passes
+    └── REFACTOR: Refactor → Test still passes
+    ↓
+Build order within slice:
+    domain (entity/value object/interface)
+    → pkg/domain/usecase (interface)
+    → pkg/domain/repository (interface)
+    → pkg/usecase (implementation)
+    → pkg/mock (mock)
+    → internal/logic (handler logic)
+    → pkg/repository (infrastructure implementation)
+    ↓
+All slices complete → Run integration tests
+    ↓
+Confirm deliverables checklist
+```
+
+### Step Details
+
+**1. Read Input**
+
+Read three documents simultaneously:
+- Implementation plan: Understand vertical slice breakdown and priority
+- API spec: Understand endpoints, request/response structures
+- DB Schema: Understand table structures and relationships
+
+**2. Identify Vertical Slices**
+
+Not horizontal slicing (layer by layer), but vertical slicing (end-to-end):
+
+```
+✅ Correct way (vertical):
+  Slice 1: User registration (domain.entity + domain.usecase interface + usecase implementation + logic + repository)
+  Slice 2: User login (same as above)
+  Slice 3: User list (same as above)
+
+❌ Wrong way (horizontal):
+  Stage 1: All domain entities
+  Stage 2: All usecases
+  Stage 3: All logic handlers
+```
+
+**3. TDD Loop (Each Slice)**
+
+For each slice, follow Red-Green-Refactor:
+
+```
+RED:    Write a test → Test fails
+GREEN:  Write minimal code to make test pass → Test passes
+REFACTOR: Refactor code → Test still passes
+```
+
+Build order within slice (inside-out):
+1. `pkg/domain/entity/` — Define Entity and Value Object
+2. `pkg/domain/member/` — Define value objects and enums (with tests)
+3. `pkg/domain/usecase/` — Define Use Case interface
+4. `pkg/domain/repository/` — Define Repository interface
+5. `pkg/usecase/` — Implement business logic (write tests first)
+6. `pkg/mock/` — Generate mocks
+7. `internal/logic/` — Handler logic
+8. `pkg/repository/` — Infrastructure implementation (with DB tests)
+
+**4. Testing**
+
+After each slice completes, ensure:
+- Unit tests pass (`pkg/usecase/*_test.go`)
+- Value object tests pass (`pkg/domain/member/*_test.go`)
+- Repository tests pass (`pkg/repository/*_test.go`)
+- Integration tests pass (critical paths)
+- Test coverage meets requirements
+
+**5. Completion Verification**
+
+Finally confirm all deliverables are complete.
+
+## Project Structure
+
+```
+project-root/
+├── build/
+│   └── Dockerfile                        # Build image
+│
+├── etc/
+│   └── {service}.example.yaml            # Example config file
+│
+├── generate/
+│   └── protobuf/
+│       └── {service}.proto               # Protobuf definitions (if gRPC)
+│
+├── internal/                              # Application layer (not exposed externally)
+│   ├── config/
+│   │   └── config.go                      # Application config
+│   ├── logic/
+│   │   └── {module}/
+│   │       ├── create_{entity}_logic.go   # One logic file per use case
+│   │       ├── get_{entity}_logic.go
+│   │       ├── update_{entity}_logic.go
+│   │       └── ...
+│   ├── server/
+│   │   └── {module}/
+│   │       └── {module}_server.go          # Server definition (HTTP/gRPC)
+│   └── svc/
+│       └── service_context.go             # Dependency injection container
+│
+├── pkg/                                   # Domain layer (can be exposed externally)
+│   ├── domain/
+│   │   ├── config/
+│   │   │   └── config.go                  # Domain config
+│   │   ├── entity/
+│   │   │   ├── {entity}.go                # Entity definition
+│   │   │   ├── {entity}_uid_table.go      # UID mapping table
+│   │   │   └── auto_id.go                 # Auto ID generation
+│   │   ├── {module}/
+│   │   │   ├── {value_object}.go          # Value objects and enums
+│   │   │   └── {value_object}_test.go      # Value object tests
+│   │   ├── repository/
+│   │   │   ├── {entity}.go                # Repository interface
+│   │   │   └── ...
+│   │   ├── usecase/
+│   │   │   ├── {module}.go                # Use Case interface
+│   │   │   └── ...
+│   │   ├── errors.go                      # Domain sentinel errors
+│   │   ├── const.go                        # Domain constants
+│   │   └── redis.go                        # Redis domain definitions
+│   ├── mock/
+│   │   ├── repository/
+│   │   │   ├── {entity}.go                # Repository mock
+│   │   │   └── ...
+│   │   └── usecase/
+│   │       └── {module}.go                # Use Case mock
+│   ├── repository/
+│   │   ├── {entity}.go                     # Repository implementation
+│   │   ├── {entity}_test.go                # Repository tests
+│   │   ├── {entity}_uid.go                 # UID Repository implementation
+│   │   ├── {entity}_uid_test.go
+│   │   ├── error.go                        # Repository error definitions
+│   │   └── start_{db}_container_test.go     # testcontainers startup
+│   └── usecase/
+│       ├── {module}.go                     # Use Case implementation
+│       ├── {operation}.go                   # Specific operation
+│       ├── {operation}_test.go              # Use Case tests
+│       └── {utils}.go                       # Utility functions
+│
+├── {service}.go                            # Application entry point
+├── Makefile
+├── go.mod
+├── go.sum
+├── docker-compose.yml
+└── readme.md
+```
+
+## Dependency Direction Rules
+
+```
+pkg/domain/         ← No external dependencies (innermost, pure definitions)
+    ↑
+pkg/domain/usecase/ ← Use Case interface (only interface definitions)
+pkg/domain/repository/ ← Repository interface (only interface definitions)
+    ↑
+pkg/usecase/        ← Depends on domain interfaces (business logic implementation)
+pkg/mock/           ← Depends on domain interfaces (test mocks)
+    ↑
+internal/logic/     ← Depends on usecase implementations (handler logic)
+internal/server/    ← Depends on logic (HTTP/gRPC server)
+internal/svc/      ← Depends on all (DI container, assemble dependencies)
+    ↑
+pkg/repository/     ← Depends on domain interfaces (infrastructure implementation)
+```
+
+```
+            ┌─────────────────────────────────┐
+            │    pkg/domain/                  │  ← Pure definitions, no dependencies
+            │    ├── entity/                  │
+            │    ├── {module}/ (value objects)│
+            │    ├── repository/ (interfaces) │
+            │    ├── usecase/ (interfaces)    │
+            │    ├── errors.go                │
+            │    └── const.go                 │
+            ├─────────────────────────────────┤
+            │    pkg/usecase/                 │  ← Depends on domain interfaces
+            │    pkg/mock/                    │  ← Depends on domain interfaces
+            ├─────────────────────────────────┤
+            │    internal/logic/              │  ← Depends on usecase
+            │    internal/server/             │
+            │    internal/config/             │
+            │    internal/svc/                │  ← DI container
+            ├─────────────────────────────────┤
+            │    pkg/repository/              │  ← Depends on domain interfaces
+            └─────────────────────────────────┘
+```
+
+## Architecture Principles
+
+### `pkg/domain/` — Pure Domain Definitions
+
+`pkg/domain/` is the core, containing only **interfaces and definitions**, no implementations:
+
+```go
+// pkg/domain/entity/user.go — Entity definition
+package entity
+
+type User struct {
+    ID        string    `json:"id"`
+    Email     string    `json:"email"`
+    Name      string    `json:"name"`
+    Status    string    `json:"status"`
+    CreatedAt time.Time `json:"created_at"`
+    UpdatedAt time.Time `json:"updated_at"`
+}
+```
+
+```go
+// pkg/domain/member/status.go — Value object (with tests)
+package member
+
+type Status string
+
+const (
+    StatusActive   Status = "active"
+    StatusInactive Status = "inactive"
+)
+
+func (s Status) IsValid() bool {
+    switch s {
+    case StatusActive, StatusInactive:
+        return true
+    }
+    return false
+}
+
+func NewStatus(s string) (Status, error) {
+    status := Status(s)
+    if !status.IsValid() {
+        return "", fmt.Errorf("invalid status: %s", s)
+    }
+    return status, nil
+}
+```
+
+```go
+// pkg/domain/member/status_test.go — Value object tests
+package member
+
+func TestStatus_IsValid(t *testing.T) {
+    assert.True(t, StatusActive.IsValid())
+    assert.True(t, StatusInactive.IsValid())
+    assert.False(t, Status("unknown").IsValid())
+}
+
+func TestNewStatus(t *testing.T) {
+    status, err := NewStatus("active")
+    assert.NoError(t, err)
+    assert.Equal(t, StatusActive, status)
+
+    _, err = NewStatus("unknown")
+    assert.Error(t, err)
+}
+```
+
+```go
+// pkg/domain/repository/user.go — Repository interface
+package repository
+
+type UserRepository interface {
+    GetByID(ctx context.Context, id string) (*entity.User, error)
+    GetByEmail(ctx context.Context, email string) (*entity.User, error)
+    Create(ctx context.Context, user *entity.User) error
+    Update(ctx context.Context, user *entity.User) error
+    Delete(ctx context.Context, id string) error
+}
+```
+
+```go
+// pkg/domain/usecase/user.go — Use Case interface
+package usecase
+
+type UserUsecase interface {
+    CreateUser(ctx context.Context, input CreateUserInput) (*entity.User, error)
+    GetUser(ctx context.Context, id string) (*entity.User, error)
+    UpdateUser(ctx context.Context, id string, input UpdateUserInput) (*entity.User, error)
+}
+```
+
+```go
+// pkg/domain/errors.go — Domain sentinel errors
+package domain
+
+import "errors"
+
+var (
+    ErrUserNotFound   = errors.New("user not found")
+    ErrInvalidInput   = errors.New("invalid input")
+    ErrDuplicateEmail = errors.New("email already exists")
+)
+```
+
+### `pkg/usecase/` — Business Logic Implementation
+
+One functional domain per file, test file in same directory:
+
+```go
+// pkg/usecase/account.go — Use Case entry point
+package usecase
+
+type AccountUsecase struct {
+    userRepo    repository.UserRepository
+    accountRepo repository.AccountRepository
+    redis       *redis.Client
+}
+
+func NewAccountUsecase(
+    userRepo repository.UserRepository,
+    accountRepo repository.AccountRepository,
+    redis *redis.Client,
+) *AccountUsecase {
+    return &AccountUsecase{
+        userRepo:    userRepo,
+        accountRepo: accountRepo,
+        redis:       redis,
+    }
+}
+```
+
+```go
+// pkg/usecase/create_user.go — Single operation
+package usecase
+
+func (uc *AccountUsecase) CreateUser(ctx context.Context, input CreateUserInput) (*entity.User, error) {
+    if err := input.Validate(); err != nil {
+        return nil, fmt.Errorf("validate input: %w", err)
+    }
+
+    existing, _ := uc.userRepo.GetByEmail(ctx, input.Email)
+    if existing != nil {
+        return nil, domain.ErrDuplicateEmail
+    }
+
+    user, err := entity.NewUser(input.Email, input.Password, input.Name)
+    if err != nil {
+        return nil, fmt.Errorf("create user: %w", err)
+    }
+
+    if err := uc.userRepo.Create(ctx, user); err != nil {
+        return nil, fmt.Errorf("save user: %w", err)
+    }
+
+    return user, nil
+}
+```
+
+```go
+// pkg/usecase/create_user_test.go — Test in same directory
+package usecase
+
+func TestAccountUsecase_CreateUser_Success(t *testing.T) {
+    mockUserRepo := new(mock.UserRepository)
+    uc := NewAccountUsecase(mockUserRepo, nil, nil)
+
+    mockUserRepo.On("GetByEmail", mock.Anything, "test@example.com").Return(nil, nil)
+    mockUserRepo.On("Create", mock.Anything, mock.AnythingOfType("*entity.User")).Return(nil)
+
+    user, err := uc.CreateUser(context.Background(), input)
+
+    assert.NoError(t, err)
+    assert.NotNil(t, user)
+    mockUserRepo.AssertExpectations(t)
+}
+```
+
+### `pkg/mock/` — Auto-Generated Mocks
+
+```go
+// pkg/mock/repository/user.go — Generated by mockery
+//go:generate mockery --name=UserRepository --output=../../mock/repository --outpkg=mock_repository
+
+package mock_repository
+
+import (
+    "github.com/stretchr/testify/mock"
+    "your-project/pkg/domain/repository"
+)
+
+type UserRepository struct {
+    mock.Mock
+}
+
+func (m *UserRepository) GetByID(ctx context.Context, id string) (*entity.User, error) {
+    args := m.Called(ctx, id)
+    if args.Get(0) == nil {
+        return nil, args.Error(1)
+    }
+    return args.Get(0).(*entity.User), args.Error(1)
+}
+```
+
+### `internal/logic/` — Handler Logic
+
+One logic file per use case (go-zero style):
+
+```go
+// internal/logic/account/create_user_logic.go
+package account
+
+type CreateUserLogic struct {
+    ctx    context.Context
+    svcCtx *svc.ServiceContext
+}
+
+func NewCreateUserLogic(ctx context.Context, svcCtx *svc.ServiceContext) *CreateUserLogic {
+    return &CreateUserLogic{
+        ctx:    ctx,
+        svcCtx: svcCtx,
+    }
+}
+
+func (l *CreateUserLogic) CreateUser(req *types.CreateUserReq) (*types.UserResp, error) {
+    user, err := l.svcCtx.UserUsecase.CreateUser(l.ctx, usecase.CreateUserInput{
+        Email:    req.Email,
+        Password: req.Password,
+        Name:     req.Name,
+    })
+    if err != nil {
+        return nil, err
+    }
+
+    return &types.UserResp{
+        ID:    user.ID,
+        Email: user.Email,
+        Name:  user.Name,
+    }, nil
+}
+```
+
+### `internal/svc/` — Dependency Injection Container
+
+```go
+// internal/svc/service_context.go
+package svc
+
+type ServiceContext struct {
+    Config           config.Config
+    UserUsecase      usecase.UserUsecase
+    AccountUsecase   usecase.AccountUsecase
+}
+
+func NewServiceContext(c config.Config) *ServiceContext {
+    db := mongo.NewClient(c.Mongo.URI)
+    redisClient := redis.NewClient(c.Redis)
+
+    userRepo := repository.NewUserRepository(db)
+    accountRepo := repository.NewAccountRepository(db)
+
+    return &ServiceContext{
+        Config:         c,
+        UserUsecase:    usecase.NewUserUsecase(userRepo, redisClient),
+        AccountUsecase: usecase.NewAccountUsecase(userRepo, accountRepo, redisClient),
+    }
+}
+```
+
+### `pkg/repository/` — Infrastructure Implementation
+
+```go
+// pkg/repository/user.go
+package repository
+
+type userRepository struct {
+    db *mongo.Database
+}
+
+func NewUserRepository(db *mongo.Database) domain.Repository.UserRepository {
+    return &userRepository{db: db}
+}
+
+func (r *userRepository) GetByID(ctx context.Context, id string) (*entity.User, error) {
+    var user entity.User
+    err := r.db.Collection("users").FindOne(ctx, bson.M{"_id": id}).Decode(&user)
+    if err != nil {
+        if err == mongo.ErrNoDocuments {
+            return nil, domain.ErrUserNotFound
+        }
+        return nil, fmt.Errorf("find user by id: %w", err)
+    }
+    return &user, nil
+}
+```
+
+```go
+// pkg/repository/user_test.go
+package repository
+
+func TestUserRepository_GetByID_Success(t *testing.T) {
+    db := startMongoContainer(t)
+    defer db.Client().Disconnect(context.Background())
+
+    repo := NewUserRepository(db)
+    // ...
+}
+```
+
+## Coding Standards
+
+### File Naming
+
+```
+Value objects and enums: pkg/domain/{module}/{name}.go         + _test.go
+Entity:                 pkg/domain/entity/{name}.go
+Repository interface:   pkg/domain/repository/{name}.go
+Usecase interface:      pkg/domain/usecase/{module}.go
+Usecase implementation: pkg/usecase/{operation}.go             + _test.go
+Usecase utilities:      pkg/usecase/{module}_utils.go           + _test.go
+Repository impl:        pkg/repository/{name}.go                + _test.go
+Mock:                   pkg/mock/repository/{name}.go
+                        pkg/mock/usecase/{module}.go
+Handler logic:          internal/logic/{module}/{operation}_logic.go
+Server:                 internal/server/{module}/{module}_server.go
+Service Context:        internal/svc/service_context.go
+Protobuf definitions:   generate/protobuf/{module}.proto
+Config files:           etc/{service}.yaml
+Dockerfile:             build/Dockerfile
+```
+
+### Naming Conventions
+
+```go
+// Package: lowercase, semantically clear
+package usecase    // not usecases
+package repository // not repositories
+package entity     // not entities
+
+// Entity struct: PascalCase, no suffix
+type User struct { ... }     // not UserModel, UserEntity
+
+// Value Object: base type alias + methods
+type Status string            // not StatusEnum
+
+// Interface: defined in pkg/domain/, semantic naming
+type UserRepository interface { ... }  // not UserRepo or UserRepositoryI
+
+// Use Case struct: {Module}Usecase
+type AccountUsecase struct { ... }
+
+// Use Case methods: verb prefix
+func (uc *AccountUsecase) CreateUser(ctx context.Context, ...) (*entity.User, error)
+func (uc *AccountUsecase) GetUser(ctx context.Context, id string) (*entity.User, error)
+
+// Logic struct: {Operation}Logic
+type CreateUserLogic struct { ... }
+
+// Error: Err prefix
+var ErrUserNotFound = errors.New("user not found")
+
+// Constant: PascalCase (exported) or camelCase (internal)
+const MaxRetryCount = 3
+const defaultPageSize = 20
+```
+
+### Error Handling
+
+```go
+// Sentinel errors — pkg/domain/errors.go
+var (
+    ErrUserNotFound   = errors.New("user not found")
+    ErrInvalidInput   = errors.New("invalid input")
+    ErrDuplicateEmail = errors.New("email already exists")
+)
+
+// Error wrapping — always use %w
+if err != nil {
+    return fmt.Errorf("create user: %w", err)
+}
+
+// Error checking — always use errors.Is
+if errors.Is(err, domain.ErrUserNotFound) {
+    // handle not found
+}
+
+// Repository errors — pkg/repository/error.go
+var (
+    ErrMongoConnection = errors.New("mongo connection failed")
+    ErrRedisConnection = errors.New("redis connection failed")
+)
+```
+
+### Interface Design
+
+```go
+// Interface defined in pkg/domain/ (consumer side)
+// Implementation defined in pkg/ (provider side)
+
+// Accept interfaces, return structs
+func NewUserUsecase(repo repository.UserRepository, redis *redis.Client) *UserUsecase {
+    return &UserUsecase{repo: repo, redis: redis}
+}
+
+// Keep interfaces small (1-3 methods)
+type UserRepository interface {
+    GetByID(ctx context.Context, id string) (*entity.User, error)
+    Create(ctx context.Context, user *entity.User) error
+}
+```
+
+## TDD Standards
+
+This skill integrates with `tdd` skill, following shared TDD principles.
+
+### Test Pyramid
+
+```
+         /\
+        /  \
+       / E2E \          <- Few critical flows
+      /--------\
+     /Integration\      <- DB + Redis (testcontainers)
+    /--------------\
+   /   Unit Tests    \   <- Most, 80%+ coverage
+  /--------------------\
+```
+
+### Test Location
+
+```
+Test files in same directory as source:
+
+pkg/domain/member/status_test.go         ← Value object tests
+pkg/usecase/create_user_test.go          ← Use Case tests
+pkg/repository/user_test.go              ← Repository tests
+pkg/repository/start_mongo_container_test.go ← testcontainers startup
+```
+
+### Vertical Slice TDD
+
+Each slice follows this order:
+
+```
+Slice: User registration
+  1. RED:   Write TestStatus_IsValid (value object)
+  2. GREEN: Write Status.IsValid()
+  3. RED:   Write TestAccountUsecase_CreateUser_Success
+  4. GREEN: Write domain/entity, domain/usecase interface, pkg/usecase implementation, mock
+  5. RED:   Write TestAccountUsecase_CreateUser_DuplicateEmail
+  6. GREEN: Add duplicate check
+  7. RED:   Write TestUserRepository_Create (DB test)
+  8. GREEN: Write pkg/repository/user.go
+  9. RED:   Write TestCreateUserLogic (handler test)
+  10. GREEN: Write internal/logic/account/create_user_logic.go
+  11. REFACTOR: Clean up everything
+```
+
+### Mock Strategy
+
+```go
+// Use mockery to auto-generate mocks
+// Add go:generate directive in interface file
+//go:generate mockery --name=UserRepository --output=../../mock/repository --outpkg=mock_repository
+
+// Unit tests use mock
+func TestAccountUsecase_CreateUser_Success(t *testing.T) {
+    mockRepo := new(mock_repository.UserRepository)
+    uc := usecase.NewAccountUsecase(mockRepo, nil, nil)
+
+    mockRepo.On("GetByEmail", mock.Anything, "test@example.com").Return(nil, nil)
+    mockRepo.On("Create", mock.Anything, mock.AnythingOfType("*entity.User")).Return(nil)
+
+    user, err := uc.CreateUser(context.Background(), input)
+
+    assert.NoError(t, err)
+    assert.NotNil(t, user)
+}
+```
+
+### testcontainers Strategy
+
+```go
+// pkg/repository/start_mongo_container_test.go
+func startMongoContainer(t *testing.T) *mongo.Database {
+    ctx := context.Background()
+    req := testcontainers.ContainerRequest{
+        Image:        "mongo:7",
+        ExposedPorts: []string{"27017/tcp"},
+        WaitingFor:   wait.ForListeningPort("27017/tcp"),
+    }
+
+    mongoC, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
+        ContainerRequest: req,
+        Started:          true,
+    })
+    require.NoError(t, err)
+
+    t.Cleanup(func() {
+        mongoC.Terminate(ctx)
+    })
+
+    // ... return connected database
+}
+```
+
+### Coverage Requirements
+
+- Value objects (`pkg/domain/member/`): >= 90%
+- Use Case (`pkg/usecase/`): >= 90%
+- Repository (`pkg/repository/`): >= 80%
+- Logic (`internal/logic/`): >= 80% (mainly integration tests)
+- Critical paths: Integration tests required
+
+## Vertical Slice Template
+
+File list for each vertical slice:
+
+```
+Slice: {operation}_{entity}
+
+New/modified files:
+├── pkg/domain/entity/{entity}.go              ← Entity definition
+├── pkg/domain/member/{value_object}.go         ← Value object (if needed)
+├── pkg/domain/member/{value_object}_test.go     ← Value object tests
+├── pkg/domain/repository/{entity}.go           ← Repository interface
+├── pkg/domain/usecase/{module}.go              ← Use Case interface
+├── pkg/usecase/{operation}.go                  ← Use Case implementation
+├── pkg/usecase/{operation}_test.go             ← Use Case tests
+├── pkg/mock/repository/{entity}.go             ← Repository mock
+├── pkg/repository/{entity}.go                  ← Repository implementation
+├── pkg/repository/{entity}_test.go             ← Repository tests
+├── internal/logic/{module}/{operation}_logic.go ← Handler logic
+└── internal/svc/service_context.go              ← Update DI
+```
+
+## Completion Checklist
+
+### After Each Slice
+- [ ] Value object tests pass
+- [ ] Use Case tests pass
+- [ ] Repository tests pass (with DB)
+- [ ] Error handling complete
+- [ ] Dependency direction correct (domain has no external dependencies)
+
+### After All Complete
+- [ ] Project structure follows Domain-Driven + go-zero style
+- [ ] `pkg/domain/` contains all Entity, Value Object, interface definitions
+- [ ] `pkg/usecase/` contains all business logic implementations
+- [ ] `pkg/repository/` contains all infrastructure implementations
+- [ ] `internal/logic/` contains all Handler logic
+- [ ] `internal/svc/` contains complete dependency injection setup
+- [ ] Unit tests >= 80% coverage
+- [ ] Business logic >= 90% coverage
+- [ ] Integration tests pass (critical paths)
+- [ ] Error handling consistent and uses `%w` wrapping
+
+## Related Skills
+
+- **Prerequisite**: `prd-to-plan` (implementation plan), `be-api-design` (API spec), `dba-schema` (DB Schema)
+- **辅助**: `tdd` (TDD Red-Green-Refactor process), `design-an-interface` (interface design)
+- **Follow-up**: `qa` (QA testing)
+
+## Rollback Mechanism
+
+```
+QA failed (Stage 10)
+    ↓
+Orchestrator re-assigns fix task
+    ↓
+Backend Agent fixes bug + adds regression test
+    ↓
+Re-enter QA (Stage 10)
+
+Code Review rejected (Stage 10)
+    ↓
+Handle PR feedback
+    ↓
+Re-enter QA (Stage 10) for verification
+
+Implementation plan not feasible
+    ↓
+Return to Task Breakdown (Stage 8) for re-decomposition

skills/prd-to-plan/SKILL.md

@@ -0,0 +1,203 @@
+---
+name: prd-to-plan
+description: "Converts PRD into a multi-phase implementation plan using vertical slices (tracer bullets). Orchestrator uses this skill at Stage 8 to produce implementation plans for Stage 9 Backend/Frontend Agent implementation. Trigger: After Design Review passes, when Orchestrator performs Task Breakdown."
+---
+
+# /prd-to-plan — PRD to Implementation Plan
+
+Orchestrator uses this skill to convert PRD into vertical slice implementation plans.
+
+## Responsibilities
+
+1. Confirm PRD content is complete and in context
+2. Explore existing codebase to understand architecture and patterns
+3. Identify persistent architectural decisions across phases
+4. Decompose PRD into vertical slices (tracer bullets)
+5. Confirm slice granularity with user
+6. Produce implementation plan document
+
+## Input
+
+- PRD document (`docs/prd/{date}-{feature}.md`)
+- API specification (`docs/api/{date}-{feature}.yaml`)
+- DB Schema (`docs/db/{date}-{feature}.sql`)
+- Design documents (`docs/design/{date}-{feature}/`)
+
+## Output
+
+- Implementation plan: `./plans/{feature}.md`
+
+## Process
+
+```
+Confirm PRD in context
+    ↓
+Explore codebase (architecture, patterns, integration layers)
+    ↓
+Identify persistent architectural decisions (routes, schema, models, auth)
+    ↓
+Draft vertical slice decomposition
+    ↓
+Confirm slice granularity with user
+    ↓
+Iterate until user approves
+    ↓
+Write plan file
+```
+
+### Step Details
+
+**1. Confirm PRD in context**
+
+The PRD should already be in the conversation. If not, ask the user to paste or point to the file.
+
+**2. Explore codebase**
+
+If the codebase hasn't been explored yet, explore to understand:
+- Current architectural patterns
+- Existing code conventions
+- Integration layers (DB, API, external services)
+- Existing test patterns
+
+**3. Identify persistent architectural decisions**
+
+Before slicing, identify high-level decisions unlikely to change during implementation:
+
+- Route structure / URL patterns
+- Database schema shape
+- Key data models
+- Authentication / authorization approach
+- Third-party service boundaries
+
+Write these decisions in the plan file header for all phases to reference.
+
+**4. Draft vertical slices**
+
+Decompose PRD into **tracer bullet** phases. Each phase is a thin vertical slice cutting through all integration layers end-to-end, **not** horizontal slicing.
+
+**Vertical slice principles:**
+
+- Each slice delivers a narrow but complete path through all layers (schema, API, usecase, logic, tests)
+- Completed slices can be demonstrated or verified independently
+- Prefer multiple thin slices over few thick slices
+- Don't include specific filenames, function names, or implementation details that may change with subsequent phases
+- Include persistent decisions: route paths, schema shapes, data model names
+
+**Horizontal slice (wrong) vs Vertical slice (correct):**
+
+```
+❌ Horizontal slice:
+  Phase 1: All domain entities
+  Phase 2: All usecases
+  Phase 3: All API handlers
+  Phase 4: All repository implementations
+
+✅ Vertical slice (tracer bullets):
+  Phase 1: User registration (entity + usecase + handler + repo + tests)
+  Phase 2: User login (same)
+  Phase 3: User list (same)
+  Phase 4: User profile update (same)
+```
+
+**5. Confirm with user**
+
+Present decomposition as a numbered list, each phase containing:
+
+- **Title**: Brief descriptive name
+- **User stories covered**: Which user stories from PRD this maps to
+
+Ask the user:
+- How does the granularity feel? (too coarse / too fine)
+- Need to merge or split any phases?
+
+Iterate until user approves.
+
+**6. Write plan file**
+
+Create `./plans/` directory (if it doesn't exist). Write Markdown file.
+
+## Plan Template
+
+```markdown
+# Plan: {Feature Name}
+
+> Source PRD: {PRD link or identifier}
+> Source API: {API specification link}
+> Source DB Schema: {DB Schema link}
+
+## Architectural Decisions
+
+Persistent decisions across all phases:
+
+- **Routes**: {API route structure}
+- **Schema**: {database schema shape}
+- **Key models**: {key data models}
+- **Auth**: {authentication/authorization approach}
+- **Third-party services**: {external service boundaries}
+
+---
+
+## Phase 1: {Title}
+
+**User stories**: {list of user stories from PRD}
+
+### What to build
+
+End-to-end behavior description for this vertical slice. Describe complete behavior, not layer-by-layer implementation details.
+
+### Acceptance criteria
+
+- [ ] Acceptance criteria 1
+- [ ] Acceptance criteria 2
+- [ ] Acceptance criteria 3
+
+---
+
+## Phase 2: {Title}
+
+**User stories**: {list of user stories from PRD}
+
+### What to build
+
+...
+
+### Acceptance criteria
+
+- [ ] ...
+
+---
+
+<!-- Repeat for each Phase -->
+```
+
+## Role in Vibe-Kanban
+
+```
+Stage 7: Design Review passes
+    ↓
+Stage 8: Task Breakdown (Orchestrator uses prd-to-plan)
+    ↓
+Output ./plans/{feature}.md
+    ↓
+Stage 9: Implementation (Backend/Frontend Agent implements according to plan)
+```
+
+Orchestrator will parse the plan and:
+1. Identify frontend and backend tasks
+2. Assign to corresponding agents
+3. May trigger parallel task distribution
+
+## Dependent Skills
+
+- **Prerequisite**: `write-a-prd` (PRD complete), `be-api-design` (API spec), `dba-schema` (DB Schema), `design-review` (design review passed)
+- **Follow-up**: `go-backend-dev` (Backend implementation), frontend implementation skill
+
+## Rollback Mechanism
+
+```
+Implementation plan infeasible
+    ↓
+Rollback to Stage 7 (Design Review) for re-review
+    or
+Rollback to Stage 4 (API Design) to adjust design
+```

skills/tdd/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: tdd
+description: "Backend Agent uses this skill for Test-Driven Development. Follows Red-Green-Refactor cycle and vertical slicing principles, ensuring tests cover behavior rather than implementation details. Trigger: Implementation phase (Stage 9), integrated with go-backend-dev skill."
+---
+
+# /tdd — Test-Driven Development
+
+Backend Agent uses this skill for Test-Driven Development.
+
+## Core Philosophy
+
+**Test behavior, not implementation details.**
+
+Good tests verify behavior through public interfaces, describing the system "what" it does, not "how" it does it. Tests still pass after refactoring.
+
+Bad tests are coupled to implementation: mocking internal collaborators, testing private methods. Tests fail after refactoring, but behavior hasn't changed.
+
+## Anti-Pattern: Horizontal Slicing
+
+**Don't write all tests first, then all implementations.** This is "horizontal slicing":
+
+```
+❌ Wrong way:
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+✅ Correct way (vertical slicing):
+  RED→GREEN: test1 → impl1
+  RED→GREEN: test2 → impl2
+  RED→GREEN: test3 → impl3
+```
+
+Horizontal slicing produces low-quality tests:
+- Tests written early verify "imagined" behavior, not "actual" behavior
+- Tests become validators of data structures and function signatures, not user-observable behavior
+- Tests are insensitive to real changes — they pass when behavior is broken, fail when behavior hasn't changed but after refactoring
+
+## Flow
+
+```
+Confirm interface changes and test scope
+    ↓
+Write first test (tracer bullet)
+    ↓
+RED: Test fails
+    ↓
+GREEN: Write minimal code to make test pass
+    ↓
+Write next test
+    ↓
+RED → GREEN loop
+    ↓
+All behavior tests complete
+    ↓
+REFACTOR: Refactor
+    ↓
+Confirm all tests still pass
+```
+
+### Step Details
+
+**1. Planning**
+
+Before writing any code:
+- [ ] Confirm which interface changes are needed with user
+- [ ] Confirm which behaviors need testing (prioritize)
+- [ ] Identify opportunities for deep modules (small interface, deep implementation)
+- [ ] Design interfaces for testability
+- [ ] List behaviors to test (not implementation steps)
+- [ ] Get user approval for test plan
+
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
+
+**You cannot test everything.** Confirm with user which behaviors are most important, focus testing effort on critical paths and complex logic, not every possible edge case.
+
+**2. Tracer Bullet**
+
+Write a test that confirms one thing about the system:
+
+```
+RED:   Write first behavior test → Test fails
+GREEN: Write minimal code to make test pass → Test passes
+```
+
+This is your tracer bullet — proving the end-to-end path works.
+
+**3. Incremental Loop**
+
+For each remaining behavior:
+
+```
+RED:   Write next test → Fails
+GREEN: Minimal code to make test pass → Passes
+```
+
+Rules:
+- One test at a time
+- Write only enough code to make current test pass
+- Don't predict future tests
+- Tests focus on observable behavior
+
+**4. Refactoring**
+
+After all tests pass, look for refactoring candidates:
+- [ ] Extract duplicate logic
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles naturally
+- [ ] Consider what new code reveals about existing code problems
+- [ ] Run tests after each refactoring step
+
+**Never refactor while in RED state. Get back to GREEN first.**
+
+## Good Tests vs Bad Tests
+
+### Good Tests
+
+**Integration style**: Test through real interfaces, not mocking internal parts.
+
+```go
+// GOOD: Test observable behavior
+func TestUserUsecase_CreateUser_Success(t *testing.T) {
+    mockRepo := new(mock.UserRepository)
+    uc := NewUserUsecase(mockRepo, logger)
+
+    mockRepo.On("GetByEmail", mock.Anything, "test@example.com").Return(nil, nil)
+    mockRepo.On("Create", mock.Anything, mock.AnythingOfType("*domain.User")).Return(nil)
+
+    user, err := uc.CreateUser(context.Background(), input)
+
+    assert.NoError(t, err)
+    assert.NotNil(t, user)
+    assert.Equal(t, "test@example.com", user.Email)
+}
+```
+
+Characteristics:
+- Tests behavior that users/callers care about
+- Uses only public APIs
+- Tests still pass after internal implementation refactoring
+- Describes "what" instead of "how"
+- One logical assertion per test
+
+### Bad Tests
+
+**Implementation detail testing**: Coupled to internal structure.
+
+```go
+// BAD: Test implementation details
+func TestUserUsecase_CreateUser_CallsRepoCreate(t *testing.T) {
+    mockRepo := new(mock.UserRepository)
+    uc := NewUserUsecase(mockRepo, logger)
+
+    uc.CreateUser(context.Background(), input)
+
+    // This tests "how" instead of "what"
+    mockRepo.AssertCalled(t, "Create", mock.Anything, mock.Anything)
+}
+```
+
+Red flags:
+- Mocking internal collaborators just to verify they were called
+- Testing private methods
+- Asserting call counts or order
+- Tests fail after refactoring but behavior unchanged
+- Test names describe "how" instead of "what"
+
+```go
+// BAD: Bypass interface validation
+func TestCreateUser_SavesToDatabase(t *testing.T) {
+    CreateUser(ctx, input)
+    row := db.QueryRow("SELECT * FROM users WHERE name = $1", "Alice")
+    // Direct database query, bypassing public interface
+}
+
+// GOOD: Validate through interface
+func TestCreateUser_MakesUserRetrievable(t *testing.T) {
+    user, _ := CreateUser(ctx, input)
+    retrieved, _ := GetUser(ctx, user.ID)
+    assert.Equal(t, "Alice", retrieved.Name)
+    // Validate behavior through public interface
+}
+```
+
+## Golang Testing Standards
+
+### Test Naming
+
+```go
+// Test{Unit}_{Scenario}
+func TestUserUsecase_CreateUser_Success(t *testing.T) {}
+func TestUserUsecase_CreateUser_InvalidEmail(t *testing.T) {}
+func TestUserUsecase_CreateUser_Duplicate(t *testing.T) {}
+```
+
+### Test Pyramid
+
+```
+         /\
+        /  \
+       / E2E \          <- Few critical flows
+      /--------\
+     /Integration\      <- API + DB
+    /--------------\
+   /   Unit Tests    \   <- Most, 80%+ coverage
+  /--------------------\
+```
+
+### Mock Strategy
+
+Only mock at **system boundaries**:
+- External APIs (payments, email, etc.)
+- Database (sometimes — prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+- Your own classes/modules
+- Internal collaborators
+- Things you can control
+
+```go
+// Use mockery to auto-generate mocks
+//go:generate mockery --name=UserRepository
+
+// Unit tests use mock repo
+func TestUserUsecase_CreateUser_Success(t *testing.T) {
+    mockRepo := new(mock.UserRepository)
+    uc := NewUserUsecase(mockRepo, logger)
+
+    mockRepo.On("GetByEmail", mock.Anything, "test@example.com").Return(nil, nil)
+    mockRepo.On("Create", mock.Anything, mock.AnythingOfType("*domain.User")).Return(nil)
+
+    user, err := uc.CreateUser(context.Background(), input)
+
+    assert.NoError(t, err)
+    assert.NotNil(t, user)
+}
+```
+
+## Interface Design for Testability
+
+Good interfaces make testing natural:
+
+**1. Accept dependencies, don't create them**
+
+```go
+// Testable
+func (s *UserService) CreateUser(ctx context.Context, input CreateUserInput, repo UserRepository) (*User, error) {}
+
+// Hard to test
+func (s *UserService) CreateUser(ctx context.Context, input CreateUserInput) (*User, error) {
+    repo := postgres.NewUserRepository(db) // Creates dependency
+}
+```
+
+**2. Return results, don't produce side effects**
+
+```go
+// Testable
+func CalculateDiscount(cart *Cart) Discount {}
+
+// Hard to test
+func ApplyDiscount(cart *Cart) {
+    cart.Total -= discount // Mutates input
+}
+```
+
+**3. Small interface surface area**
+- Fewer methods = fewer tests to write
+- Fewer parameters = simpler test setup
+
+## Checklist for Each Cycle
+
+```
+[ ] Test describes behavior, not implementation
+[ ] Test uses only public interfaces
+[ ] Test still passes after internal refactoring
+[ ] Code is minimal implementation to make current test pass
+[ ] No speculative features
+```
+
+## Refactoring Candidates
+
+After TDD cycle completes, look for:
+- **Duplicate logic** → Extract function/class
+- **Too long methods** → Split into private helpers (keep tests on public interface)
+- **Shallow modules** → Merge or deepen
+- **Feature envy** → Move logic to where the data is
+- **Primitive obsession** → Introduce value objects
+- **New code revealing existing code problems**
+
+## Related Skills
+
+- **Prerequisite**: `go-backend-dev` (used in implementation)
+- **辅助**: `design-an-interface` (design interfaces for testability)
+- **Follow-up**: `qa` (QA testing)