fix: restore missing files (package.json etc) and fix sync script logic

docs/zh-TW/commands/build-fix.md

@@ -0,0 +1,29 @@
+# 建置與修復
+
+增量修復 TypeScript 和建置錯誤：
+
+1. 執行建置：npm run build 或 pnpm build
+
+2. 解析錯誤輸出：
+   - 依檔案分組
+   - 依嚴重性排序
+
+3. 對每個錯誤：
+   - 顯示錯誤上下文（前後 5 行）
+   - 解釋問題
+   - 提出修復方案
+   - 套用修復
+   - 重新執行建置
+   - 驗證錯誤已解決
+
+4. 停止條件：
+   - 修復引入新錯誤
+   - 3 次嘗試後同樣錯誤仍存在
+   - 使用者要求暫停
+
+5. 顯示摘要：
+   - 已修復的錯誤
+   - 剩餘的錯誤
+   - 新引入的錯誤
+
+為了安全，一次修復一個錯誤！

docs/zh-TW/commands/checkpoint.md

@@ -0,0 +1,74 @@
+# Checkpoint 指令
+
+在您的工作流程中建立或驗證檢查點。
+
+## 使用方式
+
+`/checkpoint [create|verify|list] [name]`
+
+## 建立檢查點
+
+建立檢查點時：
+
+1. 執行 `/verify quick` 確保目前狀態是乾淨的
+2. 使用檢查點名稱建立 git stash 或 commit
+3. 將檢查點記錄到 `.claude/checkpoints.log`：
+
+```bash
+echo "$(date +%Y-%m-%d-%H:%M) | $CHECKPOINT_NAME | $(git rev-parse --short HEAD)" >> .claude/checkpoints.log
+```
+
+4. 報告檢查點已建立
+
+## 驗證檢查點
+
+針對檢查點進行驗證時：
+
+1. 從日誌讀取檢查點
+2. 比較目前狀態與檢查點：
+   - 檢查點後新增的檔案
+   - 檢查點後修改的檔案
+   - 現在 vs 當時的測試通過率
+   - 現在 vs 當時的覆蓋率
+
+3. 報告：
+```
+檢查點比較：$NAME
+============================
+變更檔案：X
+測試：+Y 通過 / -Z 失敗
+覆蓋率：+X% / -Y%
+建置：[通過/失敗]
+```
+
+## 列出檢查點
+
+顯示所有檢查點，包含：
+- 名稱
+- 時間戳
+- Git SHA
+- 狀態（目前、落後、領先）
+
+## 工作流程
+
+典型的檢查點流程：
+
+```
+[開始] --> /checkpoint create "feature-start"
+   |
+[實作] --> /checkpoint create "core-done"
+   |
+[測試] --> /checkpoint verify "core-done"
+   |
+[重構] --> /checkpoint create "refactor-done"
+   |
+[PR] --> /checkpoint verify "feature-start"
+```
+
+## 參數
+
+$ARGUMENTS:
+- `create <name>` - 建立命名檢查點
+- `verify <name>` - 針對命名檢查點驗證
+- `list` - 顯示所有檢查點
+- `clear` - 移除舊檢查點（保留最後 5 個）

docs/zh-TW/commands/code-review.md

@@ -0,0 +1,40 @@
+# 程式碼審查
+
+對未提交變更進行全面的安全性和品質審查：
+
+1. 取得變更的檔案：git diff --name-only HEAD
+
+2. 對每個變更的檔案，檢查：
+
+**安全性問題（關鍵）：**
+- 寫死的憑證、API 金鑰、Token
+- SQL 注入弱點
+- XSS 弱點
+- 缺少輸入驗證
+- 不安全的相依性
+- 路徑遍歷風險
+
+**程式碼品質（高）：**
+- 函式 > 50 行
+- 檔案 > 800 行
+- 巢狀深度 > 4 層
+- 缺少錯誤處理
+- console.log 陳述式
+- TODO/FIXME 註解
+- 公開 API 缺少 JSDoc
+
+**最佳實務（中）：**
+- 變異模式（應使用不可變）
+- 程式碼/註解中使用表情符號
+- 新程式碼缺少測試
+- 無障礙問題（a11y）
+
+3. 產生報告，包含：
+   - 嚴重性：關鍵、高、中、低
+   - 檔案位置和行號
+   - 問題描述
+   - 建議修復
+
+4. 如果發現關鍵或高優先問題則阻擋提交
+
+絕不批准有安全弱點的程式碼！

docs/zh-TW/commands/e2e.md

@@ -0,0 +1,115 @@
+---
+description: Generate and run end-to-end tests with Playwright. Creates test journeys, runs tests, captures screenshots/videos/traces, and uploads artifacts.
+---
+
+# E2E 指令
+
+此指令呼叫 **e2e-runner** Agent 來產生、維護和執行使用 Playwright 的端對端測試。
+
+## 此指令的功能
+
+1. **產生測試旅程** - 為使用者流程建立 Playwright 測試
+2. **執行 E2E 測試** - 跨瀏覽器執行測試
+3. **擷取產出物** - 失敗時的截圖、影片、追蹤
+4. **上傳結果** - HTML 報告和 JUnit XML
+5. **識別不穩定測試** - 隔離不穩定的測試
+
+## 何時使用
+
+在以下情況使用 `/e2e`：
+- 測試關鍵使用者旅程（登入、交易、支付）
+- 驗證多步驟流程端對端運作
+- 測試 UI 互動和導航
+- 驗證前端和後端的整合
+- 為生產環境部署做準備
+
+## 運作方式
+
+e2e-runner Agent 會：
+
+1. **分析使用者流程**並識別測試情境
+2. **產生 Playwright 測試**使用 Page Object Model 模式
+3. **跨多個瀏覽器執行測試**（Chrome、Firefox、Safari）
+4. **擷取失敗**的截圖、影片和追蹤
+5. **產生報告**包含結果和產出物
+6. **識別不穩定測試**並建議修復
+
+## 測試產出物
+
+測試執行時，會擷取以下產出物：
+
+**所有測試：**
+- HTML 報告包含時間線和結果
+- JUnit XML 用於 CI 整合
+
+**僅在失敗時：**
+- 失敗狀態的截圖
+- 測試的影片錄製
+- 追蹤檔案用於除錯（逐步重播）
+- 網路日誌
+- Console 日誌
+
+## 檢視產出物
+
+```bash
+# 在瀏覽器檢視 HTML 報告
+npx playwright show-report
+
+# 檢視特定追蹤檔案
+npx playwright show-trace artifacts/trace-abc123.zip
+
+# 截圖儲存在 artifacts/ 目錄
+open artifacts/search-results.png
+```
+
+## 最佳實務
+
+**應該做：**
+- ✅ 使用 Page Object Model 以利維護
+- ✅ 使用 data-testid 屬性作為選擇器
+- ✅ 等待 API 回應，不要用任意逾時
+- ✅ 測試關鍵使用者旅程端對端
+- ✅ 合併到主分支前執行測試
+- ✅ 測試失敗時審查產出物
+
+**不應該做：**
+- ❌ 使用脆弱的選擇器（CSS class 可能改變）
+- ❌ 測試實作細節
+- ❌ 對生產環境執行測試
+- ❌ 忽略不穩定的測試
+- ❌ 失敗時跳過產出物審查
+- ❌ 用 E2E 測試每個邊界情況（使用單元測試）
+
+## 快速指令
+
+```bash
+# 執行所有 E2E 測試
+npx playwright test
+
+# 執行特定測試檔案
+npx playwright test tests/e2e/markets/search.spec.ts
+
+# 以可視模式執行（看到瀏覽器）
+npx playwright test --headed
+
+# 除錯測試
+npx playwright test --debug
+
+# 產生測試程式碼
+npx playwright codegen http://localhost:3000
+
+# 檢視報告
+npx playwright show-report
+```
+
+## 與其他指令的整合
+
+- 使用 `/plan` 識別要測試的關鍵旅程
+- 使用 `/tdd` 進行單元測試（更快、更細粒度）
+- 使用 `/e2e` 進行整合和使用者旅程測試
+- 使用 `/code-review` 驗證測試品質
+
+## 相關 Agent
+
+此指令呼叫位於以下位置的 `e2e-runner` Agent：
+`~/.claude/agents/e2e-runner.md`

docs/zh-TW/commands/eval.md

@@ -0,0 +1,120 @@
+# Eval 指令
+
+管理評估驅動開發工作流程。
+
+## 使用方式
+
+`/eval [define|check|report|list] [feature-name]`
+
+## 定義 Evals
+
+`/eval define feature-name`
+
+建立新的 eval 定義：
+
+1. 使用範本建立 `.claude/evals/feature-name.md`：
+
+```markdown
+## EVAL: feature-name
+建立日期：$(date)
+
+### 能力 Evals
+- [ ] [能力 1 的描述]
+- [ ] [能力 2 的描述]
+
+### 回歸 Evals
+- [ ] [現有行為 1 仍然有效]
+- [ ] [現有行為 2 仍然有效]
+
+### 成功標準
+- 能力 evals 的 pass@3 > 90%
+- 回歸 evals 的 pass^3 = 100%
+```
+
+2. 提示使用者填入具體標準
+
+## 檢查 Evals
+
+`/eval check feature-name`
+
+執行功能的 evals：
+
+1. 從 `.claude/evals/feature-name.md` 讀取 eval 定義
+2. 對每個能力 eval：
+   - 嘗試驗證標準
+   - 記錄通過/失敗
+   - 記錄嘗試到 `.claude/evals/feature-name.log`
+3. 對每個回歸 eval：
+   - 執行相關測試
+   - 與基準比較
+   - 記錄通過/失敗
+4. 報告目前狀態：
+
+```
+EVAL 檢查：feature-name
+========================
+能力：X/Y 通過
+回歸：X/Y 通過
+狀態：進行中 / 就緒
+```
+
+## 報告 Evals
+
+`/eval report feature-name`
+
+產生全面的 eval 報告：
+
+```
+EVAL 報告：feature-name
+=========================
+產生日期：$(date)
+
+能力 EVALS
+----------------
+[eval-1]：通過（pass@1）
+[eval-2]：通過（pass@2）- 需要重試
+[eval-3]：失敗 - 參見備註
+
+回歸 EVALS
+----------------
+[test-1]：通過
+[test-2]：通過
+[test-3]：通過
+
+指標
+-------
+能力 pass@1：67%
+能力 pass@3：100%
+回歸 pass^3：100%
+
+備註
+-----
+[任何問題、邊界情況或觀察]
+
+建議
+--------------
+[發布 / 需要改進 / 阻擋]
+```
+
+## 列出 Evals
+
+`/eval list`
+
+顯示所有 eval 定義：
+
+```
+EVAL 定義
+================
+feature-auth      [3/5 通過] 進行中
+feature-search    [5/5 通過] 就緒
+feature-export    [0/4 通過] 未開始
+```
+
+## 參數
+
+$ARGUMENTS:
+- `define <name>` - 建立新的 eval 定義
+- `check <name>` - 執行並檢查 evals
+- `report <name>` - 產生完整報告
+- `list` - 顯示所有 evals
+- `clean` - 移除舊的 eval 日誌（保留最後 10 次執行）

docs/zh-TW/commands/go-build.md

@@ -0,0 +1,81 @@
+---
+description: Fix Go build errors, go vet warnings, and linter issues incrementally. Invokes the go-build-resolver agent for minimal, surgical fixes.
+---
+
+# Go 建置與修復
+
+此指令呼叫 **go-build-resolver** Agent，以最小變更增量修復 Go 建置錯誤。
+
+## 此指令的功能
+
+1. **執行診斷**：執行 `go build`、`go vet`、`staticcheck`
+2. **解析錯誤**：依檔案分組並依嚴重性排序
+3. **增量修復**：一次一個錯誤
+4. **驗證每次修復**：每次變更後重新執行建置
+5. **報告摘要**：顯示已修復和剩餘的問題
+
+## 何時使用
+
+在以下情況使用 `/go-build`：
+- `go build ./...` 失敗並出現錯誤
+- `go vet ./...` 報告問題
+- `golangci-lint run` 顯示警告
+- 模組相依性損壞
+- 拉取破壞建置的變更後
+
+## 執行的診斷指令
+
+```bash
+# 主要建置檢查
+go build ./...
+
+# 靜態分析
+go vet ./...
+
+# 擴展 linting（如果可用）
+staticcheck ./...
+golangci-lint run
+
+# 模組問題
+go mod verify
+go mod tidy -v
+```
+
+## 常見修復的錯誤
+
+| 錯誤 | 典型修復 |
+|------|----------|
+| `undefined: X` | 新增 import 或修正打字錯誤 |
+| `cannot use X as Y` | 型別轉換或修正賦值 |
+| `missing return` | 新增 return 陳述式 |
+| `X does not implement Y` | 新增缺少的方法 |
+| `import cycle` | 重組套件 |
+| `declared but not used` | 移除或使用變數 |
+| `cannot find package` | `go get` 或 `go mod tidy` |
+
+## 修復策略
+
+1. **建置錯誤優先** - 程式碼必須編譯
+2. **Vet 警告次之** - 修復可疑構造
+3. **Lint 警告第三** - 風格和最佳實務
+4. **一次一個修復** - 驗證每次變更
+5. **最小變更** - 不要重構，只修復
+
+## 停止條件
+
+Agent 會在以下情況停止並報告：
+- 3 次嘗試後同樣錯誤仍存在
+- 修復引入更多錯誤
+- 需要架構變更
+- 缺少外部相依性
+
+## 相關指令
+
+- `/go-test` - 建置成功後執行測試
+- `/go-review` - 審查程式碼品質
+- `/verify` - 完整驗證迴圈
+
+## 相關
+
+- Agent：`agents/go-build-resolver.md`
+- 技能：`skills/golang-patterns/`

docs/zh-TW/commands/go-review.md

@@ -0,0 +1,87 @@
+---
+description: Comprehensive Go code review for idiomatic patterns, concurrency safety, error handling, and security. Invokes the go-reviewer agent.
+---
+
+# Go 程式碼審查
+
+此指令呼叫 **go-reviewer** Agent 進行全面的 Go 特定程式碼審查。
+
+## 此指令的功能
+
+1. **識別 Go 變更**：透過 `git diff` 找出修改的 `.go` 檔案
+2. **執行靜態分析**：執行 `go vet`、`staticcheck` 和 `golangci-lint`
+3. **安全性掃描**：檢查 SQL 注入、命令注入、競態條件
+4. **並行審查**：分析 goroutine 安全性、channel 使用、mutex 模式
+5. **慣用 Go 檢查**：驗證程式碼遵循 Go 慣例和最佳實務
+6. **產生報告**：依嚴重性分類問題
+
+## 何時使用
+
+在以下情況使用 `/go-review`：
+- 撰寫或修改 Go 程式碼後
+- 提交 Go 變更前
+- 審查包含 Go 程式碼的 PR
+- 加入新的 Go 程式碼庫時
+- 學習慣用 Go 模式
+
+## 審查類別
+
+### 關鍵（必須修復）
+- SQL/命令注入弱點
+- 沒有同步的競態條件
+- Goroutine 洩漏
+- 寫死的憑證
+- 不安全的指標使用
+- 關鍵路徑中忽略錯誤
+
+### 高（應該修復）
+- 缺少帶上下文的錯誤包裝
+- 用 Panic 取代 Error 回傳
+- Context 未傳遞
+- 無緩衝 channel 導致死鎖
+- 介面未滿足錯誤
+- 缺少 mutex 保護
+
+### 中（考慮）
+- 非慣用程式碼模式
+- 匯出項目缺少 godoc 註解
+- 低效的字串串接
+- Slice 未預分配
+- 未使用表格驅動測試
+
+## 執行的自動化檢查
+
+```bash
+# 靜態分析
+go vet ./...
+
+# 進階檢查（如果已安裝）
+staticcheck ./...
+golangci-lint run
+
+# 競態偵測
+go build -race ./...
+
+# 安全性弱點
+govulncheck ./...
+```
+
+## 批准標準
+
+| 狀態 | 條件 |
+|------|------|
+| ✅ 批准 | 沒有關鍵或高優先問題 |
+| ⚠️ 警告 | 只有中優先問題（謹慎合併）|
+| ❌ 阻擋 | 發現關鍵或高優先問題 |
+
+## 與其他指令的整合
+
+- 先使用 `/go-test` 確保測試通過
+- 如果發生建置錯誤，使用 `/go-build`
+- 提交前使用 `/go-review`
+- 對非 Go 特定問題使用 `/code-review`
+
+## 相關
+
+- Agent：`agents/go-reviewer.md`
+- 技能：`skills/golang-patterns/`、`skills/golang-testing/`

docs/zh-TW/commands/go-test.md

@@ -0,0 +1,132 @@
+---
+description: Enforce TDD workflow for Go. Write table-driven tests first, then implement. Verify 80%+ coverage with go test -cover.
+---
+
+# Go TDD 指令
+
+此指令強制執行 Go 程式碼的測試驅動開發方法論，使用慣用的 Go 測試模式。
+
+## 此指令的功能
+
+1. **定義類型/介面**：先建立函式簽名骨架
+2. **撰寫表格驅動測試**：建立全面的測試案例（RED）
+3. **執行測試**：驗證測試因正確的原因失敗
+4. **實作程式碼**：撰寫最小程式碼使其通過（GREEN）
+5. **重構**：在測試保持綠色的同時改進
+6. **檢查覆蓋率**：確保 80% 以上覆蓋率
+
+## 何時使用
+
+在以下情況使用 `/go-test`：
+- 實作新的 Go 函式
+- 為現有程式碼新增測試覆蓋率
+- 修復 Bug（先撰寫失敗的測試）
+- 建構關鍵商業邏輯
+- 學習 Go 中的 TDD 工作流程
+
+## TDD 循環
+
+```
+RED     → 撰寫失敗的表格驅動測試
+GREEN   → 實作最小程式碼使其通過
+REFACTOR → 改進程式碼，測試保持綠色
+REPEAT  → 下一個測試案例
+```
+
+## 測試模式
+
+### 表格驅動測試
+```go
+tests := []struct {
+    name     string
+    input    InputType
+    want     OutputType
+    wantErr  bool
+}{
+    {"case 1", input1, want1, false},
+    {"case 2", input2, want2, true},
+}
+
+for _, tt := range tests {
+    t.Run(tt.name, func(t *testing.T) {
+        got, err := Function(tt.input)
+        // 斷言
+    })
+}
+```
+
+### 平行測試
+```go
+for _, tt := range tests {
+    tt := tt // 擷取
+    t.Run(tt.name, func(t *testing.T) {
+        t.Parallel()
+        // 測試內容
+    })
+}
+```
+
+### 測試輔助函式
+```go
+func setupTestDB(t *testing.T) *sql.DB {
+    t.Helper()
+    db := createDB()
+    t.Cleanup(func() { db.Close() })
+    return db
+}
+```
+
+## 覆蓋率指令
+
+```bash
+# 基本覆蓋率
+go test -cover ./...
+
+# 覆蓋率 profile
+go test -coverprofile=coverage.out ./...
+
+# 在瀏覽器檢視
+go tool cover -html=coverage.out
+
+# 依函式顯示覆蓋率
+go tool cover -func=coverage.out
+
+# 帶競態偵測
+go test -race -cover ./...
+```
+
+## 覆蓋率目標
+
+| 程式碼類型 | 目標 |
+|-----------|------|
+| 關鍵商業邏輯 | 100% |
+| 公開 API | 90%+ |
+| 一般程式碼 | 80%+ |
+| 產生的程式碼 | 排除 |
+
+## TDD 最佳實務
+
+**應該做：**
+- 在任何實作前先撰寫測試
+- 每次變更後執行測試
+- 使用表格驅動測試以獲得全面覆蓋
+- 測試行為，不是實作細節
+- 包含邊界情況（空值、nil、最大值）
+
+**不應該做：**
+- 在測試之前撰寫實作
+- 跳過 RED 階段
+- 直接測試私有函式
+- 在測試中使用 `time.Sleep`
+- 忽略不穩定的測試
+
+## 相關指令
+
+- `/go-build` - 修復建置錯誤
+- `/go-review` - 實作後審查程式碼
+- `/verify` - 執行完整驗證迴圈
+
+## 相關
+
+- 技能：`skills/golang-testing/`
+- 技能：`skills/tdd-workflow/`

docs/zh-TW/commands/learn.md

@@ -0,0 +1,70 @@
+# /learn - 擷取可重用模式
+
+分析目前的工作階段並擷取值得儲存為技能的模式。
+
+## 觸發
+
+在工作階段中任何時間點解決了非瑣碎問題時執行 `/learn`。
+
+## 擷取內容
+
+尋找：
+
+1. **錯誤解決模式**
+   - 發生了什麼錯誤？
+   - 根本原因是什麼？
+   - 什麼修復了它？
+   - 這可以重用於類似錯誤嗎？
+
+2. **除錯技術**
+   - 非顯而易見的除錯步驟
+   - 有效的工具組合
+   - 診斷模式
+
+3. **變通方案**
+   - 函式庫怪癖
+   - API 限制
+   - 特定版本的修復
+
+4. **專案特定模式**
+   - 發現的程式碼庫慣例
+   - 做出的架構決策
+   - 整合模式
+
+## 輸出格式
+
+在 `~/.claude/skills/learned/[pattern-name].md` 建立技能檔案：
+
+```markdown
+# [描述性模式名稱]
+
+**擷取日期：** [日期]
+**上下文：** [此模式何時適用的簡短描述]
+
+## 問題
+[此模式解決什麼問題 - 要具體]
+
+## 解決方案
+[模式/技術/變通方案]
+
+## 範例
+[如適用的程式碼範例]
+
+## 何時使用
+[觸發條件 - 什麼應該啟動此技能]
+```
+
+## 流程
+
+1. 審查工作階段中可擷取的模式
+2. 識別最有價值/可重用的見解
+3. 起草技能檔案
+4. 請使用者在儲存前確認
+5. 儲存到 `~/.claude/skills/learned/`
+
+## 注意事項
+
+- 不要擷取瑣碎的修復（打字錯誤、簡單的語法錯誤）
+- 不要擷取一次性問題（特定 API 停機等）
+- 專注於會在未來工作階段節省時間的模式
+- 保持技能專注 - 每個技能一個模式

docs/zh-TW/commands/orchestrate.md

@@ -0,0 +1,140 @@
+# Orchestrate 指令
+
+複雜任務的循序 Agent 工作流程。
+
+## 使用方式
+
+`/orchestrate [workflow-type] [task-description]`
+
+## 工作流程類型
+
+### feature
+完整的功能實作工作流程：
+```
+planner -> tdd-guide -> code-reviewer -> security-reviewer
+```
+
+### bugfix
+Bug 調查和修復工作流程：
+```
+explorer -> tdd-guide -> code-reviewer
+```
+
+### refactor
+安全重構工作流程：
+```
+architect -> code-reviewer -> tdd-guide
+```
+
+### security
+以安全性為焦點的審查：
+```
+security-reviewer -> code-reviewer -> architect
+```
+
+## 執行模式
+
+對工作流程中的每個 Agent：
+
+1. **呼叫 Agent**，帶入前一個 Agent 的上下文
+2. **收集輸出**作為結構化交接文件
+3. **傳遞給下一個 Agent**
+4. **彙整結果**為最終報告
+
+## 交接文件格式
+
+Agent 之間，建立交接文件：
+
+```markdown
+## 交接：[前一個 Agent] -> [下一個 Agent]
+
+### 上下文
+[完成事項的摘要]
+
+### 發現
+[關鍵發現或決策]
+
+### 修改的檔案
+[觸及的檔案列表]
+
+### 開放問題
+[下一個 Agent 的未解決項目]
+
+### 建議
+[建議的後續步驟]
+```
+
+## 最終報告格式
+
+```
+協調報告
+====================
+工作流程：feature
+任務：新增使用者驗證
+Agents：planner -> tdd-guide -> code-reviewer -> security-reviewer
+
+摘要
+-------
+[一段摘要]
+
+AGENT 輸出
+-------------
+Planner：[摘要]
+TDD Guide：[摘要]
+Code Reviewer：[摘要]
+Security Reviewer：[摘要]
+
+變更的檔案
+-------------
+[列出所有修改的檔案]
+
+測試結果
+------------
+[測試通過/失敗摘要]
+
+安全性狀態
+---------------
+[安全性發現]
+
+建議
+--------------
+[發布 / 需要改進 / 阻擋]
+```
+
+## 平行執行
+
+對於獨立的檢查，平行執行 Agents：
+
+```markdown
+### 平行階段
+同時執行：
+- code-reviewer（品質）
+- security-reviewer（安全性）
+- architect（設計）
+
+### 合併結果
+將輸出合併為單一報告
+```
+
+## 參數
+
+$ARGUMENTS:
+- `feature <description>` - 完整功能工作流程
+- `bugfix <description>` - Bug 修復工作流程
+- `refactor <description>` - 重構工作流程
+- `security <description>` - 安全性審查工作流程
+- `custom <agents> <description>` - 自訂 Agent 序列
+
+## 自訂工作流程範例
+
+```
+/orchestrate custom "architect,tdd-guide,code-reviewer" "重新設計快取層"
+```
+
+## 提示
+
+1. **複雜功能從 planner 開始**
+2. **合併前總是包含 code-reviewer**
+3. **對驗證/支付/PII 使用 security-reviewer**
+4. **保持交接簡潔** - 專注於下一個 Agent 需要的內容
+5. **如有需要，在 Agents 之間執行 verification**

docs/zh-TW/commands/plan.md

@@ -0,0 +1,113 @@
+---
+description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
+---
+
+# Plan 指令
+
+此指令呼叫 **planner** Agent，在撰寫任何程式碼前建立全面的實作計畫。
+
+## 此指令的功能
+
+1. **重述需求** - 釐清需要建構什麼
+2. **識別風險** - 揭示潛在問題和阻礙
+3. **建立步驟計畫** - 將實作拆解為階段
+4. **等待確認** - 必須在繼續前收到使用者批准
+
+## 何時使用
+
+在以下情況使用 `/plan`：
+- 開始新功能
+- 進行重大架構變更
+- 進行複雜重構
+- 多個檔案/元件會受影響
+- 需求不清楚或模糊
+
+## 運作方式
+
+planner Agent 會：
+
+1. **分析請求**並以清晰的語言重述需求
+2. **拆解為階段**，包含具體、可執行的步驟
+3. **識別相依性**元件之間的關係
+4. **評估風險**和潛在阻礙
+5. **估計複雜度**（高/中/低）
+6. **呈現計畫**並等待您明確確認
+
+## 使用範例
+
+```
+使用者：/plan 我需要在市場解決時新增即時通知
+
+Agent（planner）：
+# 實作計畫：即時市場解決通知
+
+## 需求重述
+- 當使用者關注的市場解決時發送通知
+- 支援多個通知管道（應用內、Email、Webhook）
+- 確保通知可靠送達
+- 包含市場結果和使用者持倉結果
+
+## 實作階段
+
+### 階段 1：資料庫結構描述
+- 新增 notifications 表格，欄位：id、user_id、market_id、type、status、created_at
+- 新增 user_notification_preferences 表格用於管道偏好
+- 在 user_id 和 market_id 上建立索引以優化效能
+
+### 階段 2：通知服務
+- 在 lib/notifications.ts 建立通知服務
+- 使用 BullMQ/Redis 實作通知佇列
+- 為失敗的送達新增重試邏輯
+- 建立通知範本
+
+### 階段 3：整合點
+- 連接到市場解決邏輯（當狀態變更為 "resolved"）
+- 查詢所有在該市場有持倉的使用者
+- 為每個使用者加入通知佇列
+
+### 階段 4：前端元件
+- 在標題建立 NotificationBell 元件
+- 新增 NotificationList 彈窗
+- 透過 Supabase 訂閱實作即時更新
+- 新增通知偏好設定頁面
+
+## 相依性
+- Redis（用於佇列）
+- Email 服務（SendGrid/Resend）
+- Supabase 即時訂閱
+
+## 風險
+- 高：Email 送達率（需要 SPF/DKIM）
+- 中：每個市場 1000+ 使用者時的效能
+- 中：如果市場頻繁解決可能造成通知垃圾訊息
+- 低：即時訂閱的開銷
+
+## 估計複雜度：中
+- 後端：4-6 小時
+- 前端：3-4 小時
+- 測試：2-3 小時
+- 總計：9-13 小時
+
+**等待確認**：繼續此計畫？（是/否/修改）
+```
+
+## 重要提醒
+
+**關鍵**：planner Agent **不會**撰寫任何程式碼，直到您明確以「是」、「繼續」或類似肯定回應確認計畫。
+
+如果您想要修改，回應：
+- "修改：[您的變更]"
+- "不同的方法：[替代方案]"
+- "跳過階段 2，先做階段 3"
+
+## 與其他指令的整合
+
+計畫後：
+- 使用 `/tdd` 以測試驅動開發實作
+- 如果發生建置錯誤，使用 `/build-fix`
+- 使用 `/code-review` 審查完成的實作
+
+## 相關 Agent
+
+此指令呼叫位於以下位置的 `planner` Agent：
+`~/.claude/agents/planner.md`

docs/zh-TW/commands/refactor-clean.md

@@ -0,0 +1,28 @@
+# 重構清理
+
+透過測試驗證安全地識別和移除無用程式碼：
+
+1. 執行無用程式碼分析工具：
+   - knip：找出未使用的 exports 和檔案
+   - depcheck：找出未使用的相依性
+   - ts-prune：找出未使用的 TypeScript exports
+
+2. 在 .reports/dead-code-analysis.md 產生完整報告
+
+3. 依嚴重性分類發現：
+   - 安全：測試檔案、未使用的工具
+   - 注意：API 路由、元件
+   - 危險：設定檔、主要進入點
+
+4. 只提議安全的刪除
+
+5. 每次刪除前：
+   - 執行完整測試套件
+   - 驗證測試通過
+   - 套用變更
+   - 重新執行測試
+   - 如果測試失敗則回滾
+
+6. 顯示已清理項目的摘要
+
+在執行測試前絕不刪除程式碼！

docs/zh-TW/commands/setup-pm.md

@@ -0,0 +1,80 @@
+---
+description: Configure your preferred package manager (npm/pnpm/yarn/bun)
+disable-model-invocation: true
+---
+
+# 套件管理器設定
+
+為此專案或全域設定您偏好的套件管理器。
+
+## 使用方式
+
+```bash
+# 偵測目前的套件管理器
+node scripts/setup-package-manager.js --detect
+
+# 設定全域偏好
+node scripts/setup-package-manager.js --global pnpm
+
+# 設定專案偏好
+node scripts/setup-package-manager.js --project bun
+
+# 列出可用的套件管理器
+node scripts/setup-package-manager.js --list
+```
+
+## 偵測優先順序
+
+決定使用哪個套件管理器時，按以下順序檢查：
+
+1. **環境變數**：`CLAUDE_PACKAGE_MANAGER`
+2. **專案設定**：`.claude/package-manager.json`
+3. **package.json**：`packageManager` 欄位
+4. **Lock 檔案**：是否存在 package-lock.json、yarn.lock、pnpm-lock.yaml 或 bun.lockb
+5. **全域設定**：`~/.claude/package-manager.json`
+6. **備援**：第一個可用的套件管理器（pnpm > bun > yarn > npm）
+
+## 設定檔
+
+### 全域設定
+```json
+// ~/.claude/package-manager.json
+{
+  "packageManager": "pnpm"
+}
+```
+
+### 專案設定
+```json
+// .claude/package-manager.json
+{
+  "packageManager": "bun"
+}
+```
+
+### package.json
+```json
+{
+  "packageManager": "pnpm@8.6.0"
+}
+```
+
+## 環境變數
+
+設定 `CLAUDE_PACKAGE_MANAGER` 以覆蓋所有其他偵測方法：
+
+```bash
+# Windows (PowerShell)
+$env:CLAUDE_PACKAGE_MANAGER = "pnpm"
+
+# macOS/Linux
+export CLAUDE_PACKAGE_MANAGER=pnpm
+```
+
+## 執行偵測
+
+要查看目前套件管理器偵測結果，執行：
+
+```bash
+node scripts/setup-package-manager.js --detect
+```

docs/zh-TW/commands/tdd.md

@@ -0,0 +1,100 @@
+---
+description: Enforce test-driven development workflow. Scaffold interfaces, generate tests FIRST, then implement minimal code to pass. Ensure 80%+ coverage.
+---
+
+# TDD 指令
+
+此指令呼叫 **tdd-guide** Agent 來強制執行測試驅動開發方法論。
+
+## 此指令的功能
+
+1. **建立介面骨架** - 先定義類型/介面
+2. **先產生測試** - 撰寫失敗的測試（RED）
+3. **實作最小程式碼** - 撰寫剛好足以通過的程式碼（GREEN）
+4. **重構** - 在測試保持綠色的同時改進程式碼（REFACTOR）
+5. **驗證覆蓋率** - 確保 80% 以上測試覆蓋率
+
+## 何時使用
+
+在以下情況使用 `/tdd`：
+- 實作新功能
+- 新增新函式/元件
+- 修復 Bug（先撰寫重現 bug 的測試）
+- 重構現有程式碼
+- 建構關鍵商業邏輯
+
+## 運作方式
+
+tdd-guide Agent 會：
+
+1. **定義介面**用於輸入/輸出
+2. **撰寫會失敗的測試**（因為程式碼還不存在）
+3. **執行測試**並驗證它們因正確的原因失敗
+4. **撰寫最小實作**使測試通過
+5. **執行測試**並驗證它們通過
+6. **重構**程式碼，同時保持測試通過
+7. **檢查覆蓋率**，如果低於 80% 則新增更多測試
+
+## TDD 循環
+
+```
+RED → GREEN → REFACTOR → REPEAT
+
+RED:      撰寫失敗的測試
+GREEN:    撰寫最小程式碼使其通過
+REFACTOR: 改進程式碼，保持測試通過
+REPEAT:   下一個功能/情境
+```
+
+## TDD 最佳實務
+
+**應該做：**
+- ✅ 在任何實作前先撰寫測試
+- ✅ 在實作前執行測試並驗證它們失敗
+- ✅ 撰寫最小程式碼使測試通過
+- ✅ 只在測試通過後才重構
+- ✅ 新增邊界情況和錯誤情境
+- ✅ 目標 80% 以上覆蓋率（關鍵程式碼 100%）
+
+**不應該做：**
+- ❌ 在測試之前撰寫實作
+- ❌ 跳過每次變更後執行測試
+- ❌ 一次撰寫太多程式碼
+- ❌ 忽略失敗的測試
+- ❌ 測試實作細節（測試行為）
+- ❌ Mock 所有東西（優先使用整合測試）
+
+## 覆蓋率要求
+
+- **所有程式碼至少 80%**
+- **以下類型需要 100%：**
+  - 財務計算
+  - 驗證邏輯
+  - 安全關鍵程式碼
+  - 核心商業邏輯
+
+## 重要提醒
+
+**強制要求**：測試必須在實作之前撰寫。TDD 循環是：
+
+1. **RED** - 撰寫失敗的測試
+2. **GREEN** - 實作使其通過
+3. **REFACTOR** - 改進程式碼
+
+絕不跳過 RED 階段。絕不在測試之前撰寫程式碼。
+
+## 與其他指令的整合
+
+- 先使用 `/plan` 理解要建構什麼
+- 使用 `/tdd` 帶著測試實作
+- 如果發生建置錯誤，使用 `/build-fix`
+- 使用 `/code-review` 審查實作
+- 使用 `/test-coverage` 驗證覆蓋率
+
+## 相關 Agent
+
+此指令呼叫位於以下位置的 `tdd-guide` Agent：
+`~/.claude/agents/tdd-guide.md`
+
+並可參考位於以下位置的 `tdd-workflow` 技能：
+`~/.claude/skills/tdd-workflow/`

docs/zh-TW/commands/test-coverage.md

@@ -0,0 +1,27 @@
+# 測試覆蓋率
+
+分析測試覆蓋率並產生缺少的測試：
+
+1. 執行帶覆蓋率的測試：npm test --coverage 或 pnpm test --coverage
+
+2. 分析覆蓋率報告（coverage/coverage-summary.json）
+
+3. 識別低於 80% 覆蓋率閾值的檔案
+
+4. 對每個覆蓋不足的檔案：
+   - 分析未測試的程式碼路徑
+   - 為函式產生單元測試
+   - 為 API 產生整合測試
+   - 為關鍵流程產生 E2E 測試
+
+5. 驗證新測試通過
+
+6. 顯示前後覆蓋率指標
+
+7. 確保專案達到 80% 以上整體覆蓋率
+
+專注於：
+- 正常流程情境
+- 錯誤處理
+- 邊界情況（null、undefined、空值）
+- 邊界條件

docs/zh-TW/commands/update-codemaps.md

@@ -0,0 +1,17 @@
+# 更新程式碼地圖
+
+分析程式碼庫結構並更新架構文件：
+
+1. 掃描所有原始檔案的 imports、exports 和相依性
+2. 以下列格式產生精簡的程式碼地圖：
+   - codemaps/architecture.md - 整體架構
+   - codemaps/backend.md - 後端結構
+   - codemaps/frontend.md - 前端結構
+   - codemaps/data.md - 資料模型和結構描述
+
+3. 計算與前一版本的差異百分比
+4. 如果變更 > 30%，在更新前請求使用者批准
+5. 為每個程式碼地圖新增新鮮度時間戳
+6. 將報告儲存到 .reports/codemap-diff.txt
+
+使用 TypeScript/Node.js 進行分析。專注於高階結構，而非實作細節。

docs/zh-TW/commands/update-docs.md

@@ -0,0 +1,31 @@
+# 更新文件
+
+從單一真相來源同步文件：
+
+1. 讀取 package.json scripts 區段
+   - 產生 scripts 參考表
+   - 包含註解中的描述
+
+2. 讀取 .env.example
+   - 擷取所有環境變數
+   - 記錄用途和格式
+
+3. 產生 docs/CONTRIB.md，包含：
+   - 開發工作流程
+   - 可用的 scripts
+   - 環境設定
+   - 測試程序
+
+4. 產生 docs/RUNBOOK.md，包含：
+   - 部署程序
+   - 監控和警報
+   - 常見問題和修復
+   - 回滾程序
+
+5. 識別過時的文件：
+   - 找出 90 天以上未修改的文件
+   - 列出供手動審查
+
+6. 顯示差異摘要
+
+單一真相來源：package.json 和 .env.example

docs/zh-TW/commands/verify.md

@@ -0,0 +1,59 @@
+# 驗證指令
+
+對目前程式碼庫狀態執行全面驗證。
+
+## 說明
+
+按此確切順序執行驗證：
+
+1. **建置檢查**
+   - 執行此專案的建置指令
+   - 如果失敗，報告錯誤並停止
+
+2. **型別檢查**
+   - 執行 TypeScript/型別檢查器
+   - 報告所有錯誤，包含 檔案:行號
+
+3. **Lint 檢查**
+   - 執行 linter
+   - 報告警告和錯誤
+
+4. **測試套件**
+   - 執行所有測試
+   - 報告通過/失敗數量
+   - 報告覆蓋率百分比
+
+5. **Console.log 稽核**
+   - 在原始檔案中搜尋 console.log
+   - 報告位置
+
+6. **Git 狀態**
+   - 顯示未提交的變更
+   - 顯示上次提交後修改的檔案
+
+## 輸出
+
+產生簡潔的驗證報告：
+
+```
+驗證：[通過/失敗]
+
+建置：    [OK/失敗]
+型別：    [OK/X 個錯誤]
+Lint：    [OK/X 個問題]
+測試：    [X/Y 通過，Z% 覆蓋率]
+密鑰：    [OK/找到 X 個]
+日誌：    [OK/X 個 console.logs]
+
+準備好建立 PR：[是/否]
+```
+
+如果有任何關鍵問題，列出它們並提供修復建議。
+
+## 參數
+
+$ARGUMENTS 可以是：
+- `quick` - 只檢查建置 + 型別
+- `full` - 所有檢查（預設）
+- `pre-commit` - 與提交相關的檢查
+- `pre-pr` - 完整檢查加上安全性掃描