universal-dev-standards 5.0.0-rc.8 → 5.0.0

package/bundled/locales/zh-TW/skills/spec-driven-dev/SKILL.md

@@ -1,13 +1,10 @@
 ---
 source: ../../../../skills/spec-driven-dev/SKILL.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-02-10
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-03-23
 status: current
-description: |
-  在撰寫程式碼前，建立、審查和管理規格文件。
-  使用時機：建立規格、審查設計、規格驅動開發流程。
-  關鍵字：spec, specification, SDD, design, review, 規格, 設計, 審查, 驗證。
+description: "[UDS] 在撰寫程式碼前，建立、審查和管理規格文件"
 ---
 
 # 規格驅動開發助手
@@ -16,9 +13,37 @@ description: |
 
 在撰寫程式碼前，建立、審查和管理規格文件。
 
+## 快速檢查清單
+
+- 搜尋現有規格：查看 `specs/`、`docs/specs/` 或專案規格目錄
+- 決定範圍：新功能 vs 修改現有功能
+- 選擇唯一的規格 ID：`SPEC-NNN` 或 kebab-case 變更 ID
+- 撰寫包含明確 AC（Given/When/Then 格式）的提案
+- 實作前取得核准
+- 依序實作任務，對照規格驗證
+- 完成後歸檔規格
+
+## 決策樹
+
+```
+新需求？
+├─ 修復符合規格行為的 Bug？ → 直接修復
+├─ 錯字/格式/註解？ → 直接修復
+├─ 相依套件更新（不破壞相容性）？ → 直接修復
+├─ 新功能/能力？ → 建立提案
+├─ 破壞性變更？ → 建立提案
+├─ 架構變更？ → 建立提案
+└─ 不確定？ → 建立提案（較安全）
+```
+
 ## 工作流程
 
-CREATE ──► REVIEW ──► APPROVE ──► IMPLEMENT ──► VERIFY
+```
+DISCUSS ──► CREATE ──► REVIEW ──► APPROVE ──► IMPLEMENT ──► VERIFY ──► ARCHIVE
+```
+
+### 0. Discuss - 釐清範圍
+在撰寫規格前，捕捉模糊地帶、建立治理原則、解決歧義。
 
 ### 1. Create - 撰寫規格
 定義需求、技術設計、驗收條件和測試計畫。
@@ -35,6 +60,9 @@ CREATE ──► REVIEW ──► APPROVE ──► IMPLEMENT ──► VERIFY
 ### 5. Verify - 驗證
 確保實作符合規格，所有測試通過，驗收條件已滿足。
 
+### 6. Archive - 歸檔
+歸檔已完成的規格，連結至 commits/PRs。
+
 ## 規格狀態
 
 | 狀態 | 說明 | State | Description |
@@ -48,20 +76,52 @@ CREATE ──► REVIEW ──► APPROVE ──► IMPLEMENT ──► VERIFY
 ## 規格結構
 
 ```markdown
-# Feature: [Name]
+# [SPEC-ID] Feature: [Name]
+
 ## Overview
-Brief description.
+簡短描述提案變更。
+
+## Motivation
+為什麼需要這個變更？解決什麼問題？
+
 ## Requirements
-- REQ-001: [Description]
+### Requirement: [Name]
+系統 SHALL [行為描述]。
+
+#### Scenario: [成功案例]
+- **GIVEN** [初始情境]
+- **WHEN** [執行動作]
+- **THEN** [預期結果]
+
 ## Acceptance Criteria
 - AC-1: Given [context], when [action], then [result]
+
 ## Technical Design
-[Architecture, API changes, database changes]
+[架構、API 變更、資料庫變更]
+
 ## Test Plan
-- [ ] Unit tests for [component]
-- [ ] Integration tests for [flow]
+- [ ] [元件] 的單元測試
+- [ ] [流程] 的整合測試
 ```
 
+### 場景格式規則
+
+- 使用 `#### Scenario:` (h4 標題) 撰寫每個場景
+- 每個需求必須至少有一個場景
+- 使用 **GIVEN/WHEN/THEN** 格式描述結構化行為
+- 使用 **SHALL/MUST** 表達強制需求，**SHOULD** 表達建議
+
+## 變更操作
+
+修改現有規格時，使用 delta 區段：
+
+| 操作 | 說明 |
+|------|------|
+| `## ADDED Requirements` | 新增功能 |
+| `## MODIFIED Requirements` | 修改行為 |
+| `## REMOVED Requirements` | 移除功能 |
+| `## RENAMED Requirements` | 重新命名 |
+
 ## 使用方式
 
 - `/sdd` - 互動式規格建立精靈

package/bundled/locales/zh-TW/skills/spec-driven-dev/guide.md

@@ -2,27 +2,35 @@
 description: |
   引導規格驅動開發 (SDD) 工作流程，在實作前規劃變更。
   使用時機：建立規格、提案、規劃功能、使用 OpenSpec 或類似工具。
-  關鍵字：spec, specification, SDD, proposal, openspec, design doc, 規格, 提案, 設計文件。
-source: ../../../../skills/spec-driven-dev/SKILL.md
-source_version: 1.1.0
-translation_version: 1.1.0
-last_synced: 2026-01-25
+  關鍵字：spec, specification, SDD, proposal, openspec, spec-kit, design doc, 規格, 提案, 設計文件。
+source: ../../../../skills/spec-driven-dev/guide.md
+source_version: 1.2.0
+translation_version: 1.2.0
+last_synced: 2026-03-23
 status: current
 ---
 
 # 規格驅動開發指南
 
-> **語言**: [English](../../../../skills/spec-driven-dev/SKILL.md) | 繁體中文
+> **語言**: [English](../../../../skills/spec-driven-dev/guide.md) | 繁體中文
 
-**版本**: 1.0.0
-**最後更新**: 2025-12-30
+**版本**: 1.2.0
+**最後更新**: 2026-03-23
 **適用範圍**: Claude Code Skills
 
 ---
 
 ## 目的
 
-此技能引導您完成規格驅動開發 (SDD)，確保變更在實作前經過規劃、記錄和批准。
+本技能引導您完成規格驅動開發 (SDD)，確保變更在實作前經過規劃、文件化和核准。
+
+## 會話啟動協議
+
+每次會話開始時：
+
+1. **檢查進行中的規格**：搜尋 `docs/specs/`、`specs/`、`openspec/changes/` 或 `.specify/` 中的進行中工作
+2. **若發現進行中的規格** → 通知使用者並提供繼續的選項
+3. 在開始新工作前**檢閱上下文**
 
 ## 快速參考
 
@@ -30,12 +38,12 @@ status: current
 
 ```
 ┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
-│     討論     │───▶│     提案     │───▶│     審查     │───▶│     實作     │
+│   Discuss    │───▶│   Proposal   │───▶│    Review    │───▶│Implementation│
 └──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
                                                                    │
                                                                    ▼
                                         ┌──────────────┐    ┌──────────────┐
-                                        │     封存     │◀───│     驗證     │
+                                        │   Archive    │◀───│ Verification │
                                         └──────────────┘    └──────────────┘
 ```
 
@@ -43,25 +51,154 @@ status: current
 
 | 階段 | 說明 | 產出 |
 |------|------|------|
-| **討論** | 釐清需求與探索方案 | 討論紀錄 |
-| **提案** | 定義變更內容與原因 | `proposal.md` |
-| **審查** | 利害關係人批准 | 批准記錄 |
-| **實作** | 執行已批准的規格 | 程式碼、測試、文件 |
-| **驗證** | 確認實作符合規格 | 測試結果 |
-| **封存** | 關閉並封存 | 封存的規格及連結 |
+| **Discuss** | 捕捉模糊地帶、鎖定範圍、建立必讀清單 | 範圍定義、規範參考 |
+| **Proposal** | 定義要變更什麼以及為什麼 | `proposal.md` |
+| **Review** | 利害關係人核准 | 核准記錄 |
+| **Implementation** | 執行已核准的規格 | 程式碼、測試、文件 |
+| **Verification** | 確認實作符合規格（最多 3 次迭代） | 測試結果、追溯矩陣 |
+| **Archive** | 關閉並歸檔 | 帶連結的已歸檔規格 |
+
+### 工作流程強制閘門
+
+**重要**：執行任何工作流程階段前，必須檢查先決條件。
+
+| 階段 | 先決條件 | 失敗時 |
+|------|---------|--------|
+| Proposal | Discuss 完成、範圍鎖定 | → 先完成 Discuss 階段 |
+| Implementation | 規格狀態 = Approved | → 先取得核准 |
+| Verification | 所有 AC 都有程式碼 + 測試 | → 完成實作 |
+| Commit (feat/fix) | 檢查進行中的規格 | → 建議規格參考 (Refs: SPEC-XXX) |
+| Archive | 所有任務完成、已驗證 | → 完成剩餘任務 |
 
 ### 核心原則
 
 | 原則 | 說明 |
 |------|------|
-| **規格優先** | 沒有批准的規格就不能進行功能變更 |
-| **工具優先** | 有 SDD 工具時優先使用工具指令 |
-| **方法論 > 工具** | SDD 可搭配任何工具或手動流程運作 |
+| **先評估** | 建立規格前評估範圍和同步需求 |
+| **規格優先** | 沒有已核准的規格不進行功能性變更 |
+| **工具優先** | 有 SDD 工具時優先使用其命令 |
+| **方法論 > 工具** | SDD 可搭配任何工具或手動流程 |
+| **雙向同步** | 變更傳播到所有相關產物 |
+| **簡單優先** | 選擇最簡單的可行方案 |
+
+### 規格前評估
+
+建立規格前，回答以下問題：
+
+| 問題 | 選項 | 結果 |
+|------|------|------|
+| **範圍？** | 專案特定 / 通用 | 決定是否需要核心規範 |
+| **互動式？** | 是 / 否 | 決定是否需要技能 |
+| **使用者觸發？** | 是 / 否 | 決定是否需要命令 |
+
+### 建立規格前
+
+- 總是先檢查專案中是否已存在類似的規格
+- 建立新規格前先搜尋現有規格目錄
+- 優先修改現有規格而非建立重複的
+- 若需求不明確，先提出 1-2 個釐清問題
+
+### 「規格優先」的例外
+
+- 緊急修復（立即恢復服務，之後補文件）
+- 瑣碎變更（錯字、註解、格式）
+- 相依套件更新（不破壞相容性）
+- 設定變更
+
+## 詳細階段指引
+
+### Discuss 階段
+
+Discuss 階段確保在撰寫規格前解決所有歧義。
+
+#### 1. 建立治理原則
+
+預先定義專案慣例、約束和不可妥協的事項：
+
+- 專案的核心架構決策是什麼？
+- 不可妥協的約束是什麼（效能、安全、相容性）？
+- 記錄在 `project.md`、`CONTRIBUTING.md` 或等效文件中
+
+#### 2. 結構化釐清
+
+列出所有模糊點作為明確問題，逐一解決後再繼續：
+
+```markdown
+## 釐清記錄
+
+| # | 問題 | 選項 | 決定 | 理由 |
+|---|------|------|------|------|
+| 1 | 認證方式？ | OAuth2 / JWT / Session | OAuth2 | 業界標準，支援 SSO |
+| 2 | Token 儲存？ | Cookie / LocalStorage | HttpOnly Cookie | XSS 防護 |
+```
+
+#### 3. 鎖定範圍
 
-### 「規格優先」的例外情況
+- 定義什麼在範圍內、什麼在範圍外
+- 識別可能受影響的相關規格
+- 建立必讀的檔案/規格清單
 
-- 緊急修復（先恢復服務，之後再補文件）
-- 瑣碎變更（錯字、註解、格式調整）
+### Implementation 階段
+
+實作時遵循結構化方法：
+
+1. **仔細閱讀提案/規格** — 理解所有需求和 AC
+2. **建立任務清單** — 分解為循序任務（在 `tasks.md` 或規格內）
+3. **依序實作任務** — 按順序完成每個任務
+4. **完成後更新清單** — 標記任務為已完成
+5. **不要跳到下一階段** — 直到所有任務完成
+
+### 需求用語
+
+在規格中使用精確語言：
+
+| 關鍵字 | 含義 | 用法 |
+|--------|------|------|
+| **SHALL/MUST** | 強制需求 | 「系統 SHALL 驗證輸入」 |
+| **SHOULD** | 建議做法 | 「API SHOULD 在 200ms 內回應」 |
+| **MAY** | 選用功能 | 「UI MAY 顯示載入動畫」 |
+
+避免模糊用語：「should try」、「might need」、「could possibly」
+
+## 簡單優先
+
+### 預設原則
+
+- 每次變更預設少於 100 行新程式碼
+- 單一檔案實作直到證明不足
+- 沒有明確理由不引入框架
+- 選擇無聊但經過驗證的模式
+
+### 複雜度觸發條件
+
+只有在具體證據下才增加複雜度：
+
+| 觸發條件 | 需要的證據 |
+|---------|-----------|
+| 效能優化 | 分析數據顯示瓶頸 |
+| 抽象層 | 3+ 個具體使用案例需要 |
+| 外部相依 | 相較內建方案的明確理由 |
+| 多服務拆分 | 規模需求（>1000 使用者、>100MB 資料） |
+
+## 命名規範
+
+### 規格 ID
+
+- 格式：`SPEC-NNN`（例如 `SPEC-001`、`SPEC-042`）
+- 在專案內循序編號
+
+### 變更 ID
+
+- 格式：kebab-case，動詞開頭
+- 前綴：`add-`、`update-`、`remove-`、`refactor-`
+- 範例：`add-two-factor-auth`、`update-payment-flow`、`remove-legacy-api`
+
+### 功能名稱
+
+- 格式：動詞-名詞（例如 `user-auth`、`payment-capture`）
+- 每個功能單一目的
+- 10 分鐘可理解性規則：若需要更久才能理解，就拆分
+- 描述需要「而且」時就拆分
 
 ## 提案範本
 
@@ -69,139 +206,145 @@ status: current
 # [SPEC-ID] 功能標題
 
 ## 摘要
-簡要描述提案的變更。
+簡短描述提案變更。
 
 ## 動機
 為什麼需要這個變更？解決什麼問題？
 
 ## 詳細設計
-技術方案、受影響的元件、資料流程。
+技術方法、受影響的元件、資料流。
 
-## 驗收標準
-- [ ] 標準 1
-- [ ] 標準 2
+## 驗收條件
+- [ ] 條件 1
+- [ ] 條件 2
 
 ## 相依性
-列出對其他規格或外部系統的相依性。
+列出對其他規格或外部系統的相依。
 
 ## 風險
-潛在風險及緩解策略。
+潛在風險和緩解策略。
 ```
 
 ## 詳細指南
 
-完整標準請參考：
-- [規格驅動開發標準](../../core/spec-driven-development.md)
+完整標準請參閱：
+- [規格驅動開發標準](../../../../core/spec-driven-development.md)
 
-### AI 優化格式（節省 Token）
+### AI 優化格式（Token 效率）
 
-AI 助手可使用 YAML 格式檔案以減少 Token 使用量：
-- 基礎標準：`ai/standards/spec-driven-development.ai.yaml`
+AI 助手可使用 YAML 格式檔案以減少 token 用量：
+- 基本標準：`ai/standards/spec-driven-development.ai.yaml`
 
 ## 與其他標準的整合
 
-### 與提交訊息整合
+### 與 Commit 訊息
 
-在提交訊息中引用規格 ID：
+在 commit 訊息中參照規格 ID：
 
 ```
-feat(auth): implement login feature
+feat(auth): 實作登入功能
 
-Implements SPEC-001 login functionality with OAuth2 support.
+實作 SPEC-001 使用 OAuth2 支援的登入功能。
 
 Refs: SPEC-001
 ```
 
-### 與 Check-in 標準整合
+### 與提交規範
 
 為規格提交程式碼前：
 
-- [ ] 規格已批准
+- [ ] 規格已核准
 - [ ] 實作符合規格
-- [ ] 測試涵蓋驗收標準
-- [ ] PR 中引用規格 ID
+- [ ] 測試涵蓋驗收條件
+- [ ] PR 中參照規格 ID
 
-### 與程式碼審查整合
+### 與程式碼審查
 
 審查者應驗證：
 
-- [ ] 變更符合已批准的規格
-- [ ] 沒有超出規格的範圍擴張
-- [ ] 規格驗收標準已達成
+- [ ] 變更符合已核准的規格
+- [ ] 沒有超出規格的範圍蔓延
+- [ ] 規格的驗收條件已滿足
 
-## 範例
+## 常見 SDD 工具
 
-### ✅ 良好做法
+| 工具 | 說明 | 主要命令 |
+|------|------|---------|
+| **OpenSpec** | 規格管理 CLI | `openspec list`、`openspec show`、`openspec validate`、`openspec archive` |
+| **Spec Kit** | 斜線命令驅動的 SDD | `specify init`、`/specify`、`/clarify`、`/plan`、`/tasks`、`/implement` |
+| **手動** | 無工具，基於檔案 | 手動建立 `specs/SPEC-XXX.md` |
 
-```markdown
-# SPEC-001 新增 OAuth2 登入
+> **注意**：當專案中偵測到 SDD 工具時，優先使用其原生命令而非手動編輯檔案，以確保一致性和可追溯性。
 
-## 摘要
-新增 Google OAuth2 登入，讓使用者可以用 Google 帳號登入。
-
-## 動機
-- 減少新使用者註冊的摩擦
-- 不儲存密碼以提升安全性
+## 同步驗證
 
-## 驗收標準
-- [ ] 使用者可以點擊「使用 Google 登入」按鈕
-- [ ] 新使用者自動註冊
-- [ ] 現有使用者可連結 Google 帳號
-```
+完成規格後，驗證同步：
 
-### ❌ 不良做法
+### 同步清單
 
 ```markdown
-# 新增登入
+## 同步狀態
+
+### 範圍：[通用|專案|工具]
 
-新增登入功能。
+- [ ] 核心規範：[已建立|已更新|不適用]
+- [ ] 技能：[已建立|已更新|不適用]
+- [ ] 命令：[已建立|已更新|不適用]
+- [ ] 翻譯：[已同步|待處理|不適用]
 ```
-- 缺少規格 ID
-- 沒有動機說明
-- 沒有驗收標準
 
-## 常見 SDD 工具
+### 同步矩陣
 
-| 工具 | 說明 | 指令範例 |
-|------|------|----------|
-| **OpenSpec** | 規格管理 | `/openspec proposal`, `/openspec approve` |
-| **Spec Kit** | 輕量規格追蹤 | `/spec create`, `/spec close` |
-| **手動** | 無工具，檔案式 | 手動建立 `specs/SPEC-XXX.md` |
+| 變更來源 | 同步至 |
+|---------|--------|
+| 核心規範 | → 技能、命令、翻譯 |
+| 技能 | → 核心規範、命令、翻譯 |
+| 命令 | → 技能、翻譯 |
 
 ## 最佳實踐
 
-### 建議做法
+### 應該做的
 
-- ✅ 保持規格專注且原子化（一個規格一個變更）
-- ✅ 包含清晰的驗收標準
-- ✅ 將規格連結到實作 PR
-- ✅ 完成後封存規格
+- 建立規格前評估範圍
+- 建立新規格前檢查是否已存在
+- 保持規格聚焦且原子化（一個規格一個變更）
+- 包含使用 Given/When/Then 的明確驗收條件
+- 使用 SHALL/MUST 表達強制需求
+- 將規格連結到實作 PR
+- 完成後歸檔規格
+- 關閉前驗證同步狀態
 
-### 避免做法
+### 不應該做的
 
-- ❌ 在規格批准前開始寫程式
-- ❌ 實作期間修改範圍但不更新規格
-- ❌ 讓規格處於懸置狀態（務必關閉或封存）
-- ❌ 跳過驗證步驟
+- 規格核准前就開始寫程式
+- 跳過範圍評估或 Discuss 階段
+- 實作期間修改範圍而不更新規格
+- 讓規格處於懸而未決狀態（一定要關閉或歸檔）
+- 跳過驗證步驟
+- 忘記同步相關產物
+- 沒有具體證據就增加複雜度
 
 ---
 
 ## 設定偵測
 
-此技能支援專案特定設定。
+本技能支援專案特定的設定。
 
 ### 偵測順序
 
-1. 檢查工作區是否有 SDD 工具（OpenSpec、Spec Kit 等）
+1. 檢查工作區中的 SDD 工具：
+   - `openspec/` 目錄 → 偵測到 OpenSpec
+   - `.specify/` 目錄 → 偵測到 Spec Kit
+   - `specs/` 或 `docs/specs/` → 手動基於檔案的工作流程
 2. 檢查 `CONTRIBUTING.md` 中的規格工作流程文件
-3. 若無找到，**預設使用手動檔案式工作流程**
+3. 若未找到，**預設使用手動基於檔案的工作流程**
 
 ### 首次設定
 
 若未找到設定：
 
-1. 詢問使用者：「此專案尚未設定 SDD。您要設定 specs 目錄嗎？」
-2. 建議在 `CONTRIBUTING.md` 中記錄：
+1. 詢問使用者：「此專案尚未設定 SDD。是否要設定規格目錄？」
+2. 建議記錄在 `CONTRIBUTING.md`：
 
 ```markdown
 ## 規格驅動開發
@@ -210,21 +353,21 @@ Refs: SPEC-001
 
 ### 流程
 1. 在 `specs/` 目錄建立提案
-2. 取得團隊負責人批准
-3. 實作並在 PR 中引用規格
-4. 合併後封存規格
+2. 取得團隊負責人核准
+3. 實作並在 PR 中參照規格
+4. 合併後歸檔規格
 
 ### 規格範本
-請參考 `specs/TEMPLATE.md`
+請參閱 `specs/TEMPLATE.md`
 ```
 
 ---
 
 ## 相關標準
 
-- [規格驅動開發標準](../../core/spec-driven-development.md)
-- [提交訊息指南](../../core/commit-message-guide.md)
-- [程式碼審查檢查清單](../../core/code-review-checklist.md)
+- [規格驅動開發標準](../../../../core/spec-driven-development.md)
+- [Commit 訊息指南](../../../../core/commit-message-guide.md)
+- [程式碼審查清單](../../../../core/code-review-checklist.md)
 
 ---
 
@@ -232,12 +375,14 @@ Refs: SPEC-001
 
 | 版本 | 日期 | 變更 |
 |------|------|------|
-| 1.0.0 | 2025-12-30 | 初始發布 |
+| 1.2.0 | 2026-03-23 | 新增：會話啟動協議、工作流程強制閘門、Discuss 階段（治理原則 + 釐清）、簡單優先、命名規範、Implementation 階段強化、需求用語、搜尋指引、更新常見 SDD 工具 |
+| 1.1.0 | 2026-01-26 | 新增：規格前評估、同步驗證、同步矩陣、強化最佳實踐 |
+| 1.0.0 | 2025-12-30 | 初始版本 |
 
 ---
 
 ## 授權
 
-此技能採用 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權。
+本技能以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權釋出。
 
 **來源**: [universal-dev-standards](https://github.com/AsiaOstrich/universal-dev-standards)

package/bundled/locales/zh-TW/skills/tdd-assistant/SKILL.md

@@ -4,10 +4,7 @@ source_version: 1.0.0
 translation_version: 1.0.0
 last_synced: 2026-02-10
 status: current
-description: |
-  引導測試驅動開發（TDD）流程：紅-綠-重構。
-  使用時機：TDD 開發、撰寫測試先行的程式碼、學習 TDD。
-  關鍵字：TDD, test-driven, red-green-refactor, 測試驅動, 紅綠重構。
+description: "[UDS] 引導測試驅動開發（TDD）流程：紅-綠-重構"
 ---
 
 # TDD 助手

package/bundled/locales/zh-TW/skills/test-coverage-assistant/SKILL.md

@@ -4,10 +4,7 @@ source_version: 1.1.0
 translation_version: 1.1.0
 last_synced: 2026-02-10
 status: current
-description: |
-  多維度分析測試覆蓋率並提供可執行的建議。
-  使用時機：分析覆蓋率、識別測試缺口、制定測試策略。
-  關鍵字：coverage, test, analysis, dimension, 覆蓋率, 測試, 分析, 維度。
+description: "[UDS] 多維度分析測試覆蓋率並提供可執行的建議"
 ---
 
 # 測試覆蓋率助手

package/bundled/locales/zh-TW/skills/testing-guide/SKILL.md

@@ -5,11 +5,7 @@ translation_version: 1.2.0
 last_synced: 2026-02-10
 status: current
 name: testing
-description: |
-  Testing pyramid and test writing standards for UT/IT/ST/E2E.
-  Supports ISTQB and Industry Pyramid frameworks.
-  Use when: writing tests, discussing test coverage, test strategy, or test naming.
-  Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元, 整合, 端對端.
+description: "[UDS] 測試金字塔與 UT/IT/ST/E2E 測試撰寫標準"
 ---
 
 # 測試指南

package/bundled/skills/README.md

@@ -47,6 +47,17 @@ These skills provide standard guidance and workflows. They can be accessed via s
 | `changelog-guide` | `/changelog` | [UDS] Generate changelog entries |
 | `dev-workflow-guide` | `/dev-workflow` | [UDS] Map development phases to UDS commands |
 | `docs-generator` | `/docgen` | [UDS] Generate usage documentation |
+| `security-assistant` | `/security` | [UDS] Security review and vulnerability assessment |
+| `security-scan-assistant` | `/scan` | [UDS] Automated security scanning and dependency audit |
+| `api-design-assistant` | `/api-design` | [UDS] API design (REST, GraphQL, gRPC) |
+| `database-assistant` | `/database` | [UDS] Database design, migration, query optimization |
+| `ci-cd-assistant` | `/ci-cd` | [UDS] CI/CD pipeline design and optimization |
+| `incident-response-assistant` | `/incident` | [UDS] Incident response and post-mortem |
+| `pr-automation-assistant` | `/pr` | [UDS] Pull request creation and review automation |
+| `metrics-dashboard-assistant` | `/metrics` | [UDS] Development metrics and project health |
+| `durable-execution-assistant` | `/durable` | [UDS] Workflow fault recovery and rollback |
+| `migration-assistant` | `/migrate` | [UDS] Code migration and framework upgrades |
+| `audit-assistant` | `/audit` | [UDS] Standards compliance audit |
 
 > **Note**: For reference guides (e.g., Git Workflow, Logging, Error Codes), use the `/guide` command.