universal-dev-standards 5.4.0 → 5.6.0

package/bundled/skills/orchestrate/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: orchestrate
+version: 2.0.0
+scope: universal
+description: |
+  Orchestrate multi-task execution plans using Claude's native Agent tool (DAG-based, no external engine).
+  Use when: executing a plan.json file with parallel/sequential task dependencies.
+  Keywords: orchestrate, plan, execute, DAG, task plan, 編排, 執行計畫, 並行.
+argument-hint: "<plan.json> [--dry-run]"
+---
+
+# /orchestrate — 任務計畫編排 Skill
+
+## 用法
+
+```
+/orchestrate <plan.json>           # 執行計畫
+/orchestrate <plan.json> --dry-run # 僅驗證，不執行
+```
+
+---
+
+## 執行流程
+
+### Step 1: 讀取與解析計畫（Claude-native）
+
+使用 Read tool 讀取 plan.json，直接由 Claude 解析：
+
+1. 讀取 JSON 檔案，解析為任務清單
+2. 驗證結構：`tasks` 非空、每個 task 含 `id`、`title`、`spec`
+3. 安全掃描：檢查 `task.spec` 是否含危險指令（`rm -rf /`、`DROP DATABASE`、`git push --force`）
+   - 若發現安全問題，列出所有問題並**詢問使用者是否繼續**
+4. 拓撲排序：依 `depends_on` 欄位將 tasks 分組為執行層（layers）
+   - Layer 0：沒有依賴的 tasks（可並行）
+   - Layer N：依賴全部在 Layer 0..N-1 中的 tasks
+
+若 `validation.valid` 為 false，輸出錯誤訊息並停止。
+
+---
+
+### Step 2: 呈現執行計畫
+
+向使用者顯示解析結果：
+
+```
+計畫：<project>  品質：<quality>
+──────────────────────────────────
+Layer 0 (並行)：T-001, T-002
+Layer 1 (序列)：T-003 (依賴 T-001)
+Layer 2 (序列)：T-004 (依賴 T-002, T-003)
+──────────────────────────────────
+共 4 個任務，3 個執行層
+```
+
+若使用 `--dry-run`：顯示以上摘要後**立即停止**，不啟動任何 Agent。
+
+---
+
+### Step 3: 逐層執行
+
+對 `layers` 陣列中的每一層：
+
+1. **同層並行**：同一層的 tasks 在同一訊息中啟動多個 Agent tool
+2. **Agent tool 參數**：
+   - `prompt`：task.spec + acceptance_criteria + user_intent 組合而成的執行提示
+   - `isolation: "worktree"`：每個 task 在獨立 git worktree 執行
+   - `description`：`"Task {task.id}: {task.title}"`
+3. **等待完成**：所有同層 agents 完成後，才進入下一層
+
+**Agent 提示範本**：
+```
+Task: {task.title}
+
+Spec:
+{task.spec}
+
+Acceptance Criteria:
+{task.acceptance_criteria 逐條列出}
+
+User Intent:
+{task.user_intent}
+
+After completing the task, run: {task.verify_command}
+```
+
+---
+
+### Step 4: 依賴失敗處理
+
+如果某個 task 的 agent 回報失敗：
+- 標記該 task 為 `failed`
+- 後續層中 `depends_on` 包含該 task ID 的所有 tasks 標記為 `skipped`
+- 繼續執行不受影響的 tasks
+- 最終報告中標示失敗原因
+
+---
+
+### Step 5: Quality Gate
+
+每個 task 完成後，若 task 定義了 `verify_command`：
+
+1. 使用 Bash tool 執行 `verify_command`
+2. **成功**：記錄 `status: "success"`
+3. **失敗**：
+   - 若 `quality` 為 `"strict"` 或 `"standard"`：啟動 Fix Loop
+   - Fix Loop：將錯誤輸出回傳給 agent，重新執行（最多 3 次）
+   - 超過重試上限：標記為 `failed`
+
+---
+
+### Step 6: Judge 審查（選用）
+
+如果 task 定義了 `judge: true`：
+- 啟動一個額外的 Agent tool 進行審查
+- 提示：`審查 task {id} 的 git diff，依照 code-review 標準檢查`
+- Judge 結果附加到最終報告
+
+---
+
+### Step 7: 產出報告
+
+彙整所有 task 結果，輸出執行報告：
+
+```json
+{
+  "summary": {
+    "total_tasks": 4,
+    "succeeded": 3,
+    "failed": 1,
+    "skipped": 0,
+    "total_duration_ms": 120000
+  },
+  "tasks": [
+    { "task_id": "T-001", "status": "success", "duration_ms": 30000 },
+    { "task_id": "T-002", "status": "failed",  "error": "..." },
+    { "task_id": "T-003", "status": "skipped", "reason": "依賴任務失敗" }
+  ]
+}
+```
+
+---
+
+## 品質設定檔
+
+| Profile | 行為 |
+|---------|------|
+| `strict` | 全部檢查 + Fix Loop 最多 5 次 |
+| `standard` | lint + test + Fix Loop 最多 3 次（預設） |
+| `minimal` | 僅跑 verify_command，不 Fix Loop |
+| `none` | 不執行任何驗證 |
+
+---
+
+## 重要注意事項
+
+- 每個 Agent tool 的 `isolation: "worktree"` 會自動建立 git worktree
+- `depends_on: []` 的 tasks 在同一層內全部並行
+- 使用繁體中文回覆使用者
+
+---
+
+## 版本歷程
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 2.0.0 | 2026-04-28 | 升格為 UDS 正式 Skill；Step 1 改為 Claude-native 解析（移除 plan-resolver-cli.js 依賴）；新增 Quality Gate / Fix Loop 章節（XSPEC-097 Phase 3） |
+| 1.0.0 | 2026-04-09 | 初始發布（DevAP packages/cli/skills/） |

package/bundled/skills/plan/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: plan
+version: 2.0.0
+scope: universal
+description: |
+  Generate plan.json from Spec documents, OpenSpec changes, or free-text requirements.
+  Use when: converting specifications into executable task plans for /orchestrate.
+  Keywords: plan, spec, task plan, 計畫, 規格, 任務, plan.json, DAG.
+argument-hint: "[spec-file.md | openspec-dir/ | \"requirement text\" | (interactive)]"
+---
+
+# /plan — 從 Spec 自動生成 plan.json
+
+## 用法
+
+```
+/plan <spec-file.md>              # Spec 模式（自有格式 / SpecKit）
+/plan <openspec-change-dir/>      # OpenSpec 模式
+/plan "需求描述文字"               # 需求模式
+/plan                             # 互動模式（自動偵測）
+```
+
+---
+
+## 執行流程
+
+### Step 1: 輸入辨識與格式偵測
+
+根據引數類型判斷使用模式：
+
+**引數是 .md 檔案：**
+1. 讀取檔案內容
+2. 偵測格式：
+   - 含 `## Requirements` **且** `## Technical Design` → **自有格式**（SPEC-NNN-*.md）
+   - 含 `## Summary` **且** `## Detailed Design` → **SpecKit 格式**
+   - 其他 .md → 嘗試解析為通用 Spec（按自有格式處理，缺少的欄位由 AI 補充）
+
+**引數是目錄：**
+1. 檢查是否含 `proposal.md` + `tasks.md` → **OpenSpec 格式**
+2. 否則報錯：「此目錄不符合 OpenSpec 結構」
+
+**引數是字串描述（非檔案路徑）：**
+→ **需求模式**
+
+**無引數：**
+→ **互動模式**
+1. 偵測 `openspec/` 目錄存在？ → 列出 changes 讓使用者選擇
+2. 偵測 `specs/*.md` 存在？ → 列出可用 Spec 讓使用者選擇
+3. 都沒有 → 進入需求模式問答
+
+---
+
+### Step 2: 專案 Context 收集
+
+讀取目標專案的關鍵資訊：
+
+1. **CLAUDE.md / AGENTS.md** — 語言、框架、測試工具、開發規範
+2. **package.json / pyproject.toml** — 可用 scripts（build, test, lint）
+
+從 Context 推斷：
+- 主要語言（TypeScript / Python / 其他）
+- 預設 verify_command（如 `pnpm build && pnpm test`、`pytest -x`）
+- 預設 lint_command（如 `pnpm lint`、`ruff check .`）
+
+---
+
+### Step 3: Spec 解析
+
+依偵測到的格式，解析 Spec 內容：
+
+#### 自有格式（SPEC-NNN-*.md）
+
+提取以下區段：
+- **Summary / Motivation** → 理解背景與需求動機
+- **Requirements (REQ-NNN)** → 功能需求列表
+- **Acceptance Criteria (AC-N)** → Given/When/Then 驗收條件
+- **Technical Design** → Phase 分層、每個 Phase 的實作項目
+- **Test Plan** → 測試清單
+- **Risks** → 風險評估
+
+#### OpenSpec（change 目錄）
+
+讀取以下檔案：
+- `proposal.md` → Why（動機）、What Changes（變更項目）、Impact
+- `tasks.md` → `- [ ]` checklist 項目
+- `design.md`（若存在）→ 技術決策
+- `specs/*/spec.md`（若存在）→ Requirements（SHALL/MUST 語句）、Scenarios
+
+#### SpecKit（SPEC-ID.md）
+
+提取以下區段：
+- **Summary / Motivation** → 背景
+- **Detailed Design** → 技術實作步驟
+- **Acceptance Criteria** → checkbox 驗收條件
+- **Dependencies** → 外部依賴
+- **Risks** → 風險
+
+---
+
+### Step 4: Task 切分
+
+依格式套用不同映射規則：
+
+#### 自有格式映射規則
+
+| Spec 區段 | plan.json 欄位 | 映射規則 |
+|-----------|---------------|----------|
+| Technical Design > Phase | 一組 tasks | 每個 Phase 的每個實作項目 = 1 個 task |
+| Phase 實作項目描述 | `task.spec` | 合併：項目描述 + 相關 REQ + 技術細節 |
+| Acceptance Criteria (AC-N) | `task.acceptance_criteria` | 分配到最相關的 task |
+| Summary / Motivation | `task.user_intent` | 萃取與 task 最相關的意圖 |
+| Test Plan | `task.verify_command` | 推斷測試指令 |
+
+#### OpenSpec 映射規則
+
+| OpenSpec 檔案 | plan.json 欄位 | 映射規則 |
+|--------------|---------------|----------|
+| `tasks.md` 的 checklist 項目 | tasks | 每個 `- [ ]` 項目 = 1 個 task |
+| `proposal.md` > Why | `task.user_intent` | 所有 tasks 共用 |
+| `proposal.md` > What Changes | 融入 `task.spec` | 提供變更脈絡 |
+| `design.md` 技術細節 | 融入 `task.spec` | 補充實作指引 |
+| `specs/*/spec.md` > Scenarios | `task.acceptance_criteria` | 每個 Scenario 映射為一條 criteria |
+| `specs/*/spec.md` > Requirements | 融入 `task.spec` | SHALL/MUST 語句轉為具體實作指引 |
+
+---
+
+### Step 5: 依賴推斷
+
+為 tasks 建立 `depends_on` 關係：
+
+1. **Phase/Stage 順序**：後面的 Phase 的第一個 task depends_on 前面 Phase 的最後一個 task
+2. **同 Phase 內順序**：型別定義 → 實作 → 整合 → 測試
+3. **檔案依賴**：A 建立的檔案被 B import → B depends_on A
+4. **無依賴的 tasks**：`depends_on: []`（可並行）
+
+---
+
+### Step 6: verify_command 推斷
+
+依以下優先順序推斷：
+
+1. **Test Plan / Scenarios 有明確測試項** → 對應測試指令
+2. **TypeScript 專案** → `pnpm build && pnpm test`
+3. **Python 專案** → `pytest -x`
+4. **其他** → 使用 Step 2 收集的專案 scripts
+5. **無法推斷** → 不設（後續品質警告會提醒）
+
+---
+
+### Step 7: 品質設定
+
+- 預設 `quality: "standard"`
+- 使用者可在互動確認時調整
+
+---
+
+### Step 8: 組裝 plan.json
+
+```json
+{
+  "project": "<專案名稱>",
+  "quality": "standard",
+  "defaults": {
+    "max_turns": 30,
+    "max_budget_usd": 2.0,
+    "verify_command": "<推斷的預設驗證指令>"
+  },
+  "tasks": [
+    {
+      "id": "T-001",
+      "title": "<task 標題>",
+      "spec": "<詳細的 task 規格說明>",
+      "depends_on": [],
+      "verify_command": "<task 層級驗證指令（可選）>",
+      "acceptance_criteria": ["<驗收條件 1>"],
+      "user_intent": "<使用者意圖>"
+    }
+  ]
+}
+```
+
+**注意事項：**
+- Task ID 格式：`T-NNN`（如 T-001, T-002）
+- `spec` 欄位應詳盡——它是 agent 執行任務的唯一規格輸入
+- `acceptance_criteria` 每條都必須是可觀察、可驗證的
+
+---
+
+### Step 9: 驗證（Claude-native）
+
+Claude 對 plan.json 執行以下驗證（無需外部引擎）：
+
+1. **結構驗證**：`tasks` 陣列存在且非空、每個 task 含必填欄位（id, title, spec）
+2. **DAG 合法性**：`depends_on` 中的所有 ID 均存在、無循環依賴
+3. **安全掃描**：task.spec 不含危險指令（`rm -rf /`、`DROP DATABASE`、`git push --force`）
+4. **品質警告**：task 缺少 verify_command、spec 過短（< 20 字）等
+
+若發現問題，在呈現前先自動修正（若可修正）或標示警告。
+
+---
+
+### Step 10: 呈現與確認
+
+向使用者呈現生成結果：
+
+1. **摘要表格**：
+   ```
+   | Task ID | 標題 | 依賴 | 驗證指令 |
+   |---------|------|------|----------|
+   | T-001   | ...  | -    | ...      |
+   | T-002   | ...  | T-001| ...      |
+   ```
+
+2. **DAG 拓撲**：
+   ```
+   Layer 0: T-001, T-002（並行）
+   Layer 1: T-003（依賴 T-001）
+   Layer 2: T-004（依賴 T-002, T-003）
+   ```
+
+3. **品質設定**：`quality: standard`
+
+4. **品質警告**（若有）
+
+5. **詢問使用者**：確認或修改？確認後寫入檔案（預設路徑：`plans/<spec-name>.plan.json`）
+
+---
+
+## 版本歷程
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 2.0.0 | 2026-04-28 | 升格為 UDS 正式 Skill；移除 [DEVAP] 標記；Step 9 改為 Claude-native 驗證（XSPEC-097 Phase 3） |
+| 1.0.0 | 2026-04-09 | 初始發布（DevAP packages/cli/skills/） |

package/bundled/skills/pr-automation-assistant/SKILL.md

@@ -8,6 +8,14 @@ description: |
 allowed-tools: Read, Grep, Glob, Bash(git:*, gh:*)
 argument-hint: "[branch name or PR number | 分支名稱或 PR 編號]"
 ---
+<!-- DEPRECATION NOTICE (XSPEC-086 Phase 4, 2026-04-28):
+  PR lifecycle orchestration (5-step: CREATE→REVIEW→APPROVE→MERGE→CLEANUP,
+  size gate >400 lines block, CI gate, squash/merge strategy, gh CLI integration) extracted to:
+  - DevAP flow: dev-autopilot/.devap/flows/pr.flow.yaml
+  - DevAP CLI:  devap pr (packages/cli/src/commands/pr.ts)
+  This Skill retains: PR description template, merge strategy decision matrix, auto-review trigger rules.
+  Use `devap pr` for enforced lifecycle; this Skill for template and rule reference.
+-->
 
 # PR Automation Assistant | PR 自動化助手
 

package/bundled/skills/push/SKILL.md

@@ -8,12 +8,11 @@ description: |
 allowed-tools: Read, Bash(git:*), Bash(npm:*), Bash(pnpm:*), Bash(yarn:*), Bash(bun:*)
 argument-hint: "[--force] [--target <branch>] [--skip-gates] [--no-pr]"
 ---
-
 # Push Assistant | 推送助手
 
 > **Language**: English | 繁體中文
 
-**Version**: 1.0.0
+**Version**: 2.0.0
 **Created**: 2026-04-23
 **Applicability**: Claude Code Skills
 
@@ -29,6 +28,53 @@ This skill implements [`.standards/push-standards.ai.yaml`](../../.standards/pus
 
 ---
 
+## Workflow | 執行工作流程
+
+When `/push` is invoked, Claude executes the following steps natively:
+
+### Step 1: Detect Protected Branch
+Run `git rev-parse --abbrev-ref HEAD` to get current branch.
+Compare against `protected_branches` list (default: main, master, release/*, hotfix/*).
+If protected: show warning + pending commits, require explicit user confirmation before proceeding.
+
+### Step 2: Detect Force Push
+If `--force` or `--force-with-lease` flag detected:
+Run `git log origin/<branch>..HEAD --oneline` to find commits that will be overwritten.
+Show count and author list. Require user to type `yes, force push` to proceed.
+
+### Step 3: Run Pre-Push Quality Gates
+Run each configured gate in sequence using Bash tool:
+- `lint`: detect and run project lint command
+- `test`: detect and run project test command
+- `type-check` (optional): TypeScript type check
+- `ac-coverage` (optional): acceptance criteria coverage
+- `security-scan` (optional): security vulnerability scan
+
+If any required gate fails: abort with error message.
+
+### Step 4: Execute Push
+Run `git push <remote> <branch> [--force]`.
+If push fails: show git error and suggest remediation.
+
+### Step 5: Emit Push Receipt
+Output structured receipt to console (and optionally to `~/.uds/push-history.jsonl`):
+```json
+{
+  "branch": "<branch>",
+  "commit_sha": "<sha>",
+  "gates_passed": ["lint", "test"],
+  "force_push": false,
+  "timestamp": "<ISO8601>",
+  "target_remote": "origin"
+}
+```
+
+### Step 6: PR Integration
+If `auto_pr=true` AND `repo_mode=team` AND no open PR exists for this branch:
+Suggest running `/pr-automation-assistant` to create a Pull Request.
+
+---
+
 ## Features | 功能說明
 
 ### 1. Push Target Risk Detection | 推送目標風險偵測
@@ -192,6 +238,7 @@ After `/push` completes, the AI assistant should suggest:
 
 | Version | Date | Changes |
 |---------|------|---------|
+| 2.0.0 | 2026-04-28 | Restore workflow execution steps (DevAP decomposition XSPEC-097); remove deprecation notice |
 | 1.0.0 | 2026-04-23 | Initial release — XSPEC-081 Phase 1 |
 
 ---

package/bundled/skills/{process-automation → skill-builder}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: process-to-skill
+name: skill-builder
 scope: universal
 description: "[UDS] Identify repeated processes and build Skills with the right development depth"
 allowed-tools: Read, Glob, Grep, Write, Edit, Bash

package/bundled/skills/{forward-derivation → spec-derivation}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: derive
+name: spec-derive
 scope: partial
 description: "[UDS] Derive BDD scenarios, TDD skeletons, or ATDD tables from specifications"
 allowed-tools: Read, Write, Grep, Glob

package/bundled/skills/spec-driven-dev/SKILL.md

@@ -5,6 +5,13 @@ description: "[UDS] Create or review specification documents for Spec-Driven Dev
 allowed-tools: Read, Write, Grep, Glob, Bash(git:*)
 argument-hint: "[spec name or feature | 規格名稱或功能]"
 ---
+<!-- DEPRECATION NOTICE (XSPEC-086 Phase 4, 2026-04-28):
+  SDD lifecycle orchestration (7-phase state machine, phase transitions, gate checks) extracted to:
+  - DevAP flow: dev-autopilot/.devap/flows/sdd.flow.yaml
+  - DevAP CLI:  devap sdd (packages/cli/src/commands/sdd.ts) with --phase jump support
+  This Skill retains: spec format definition, state descriptions, delta operations, decision tree.
+  Use `devap sdd` for enforced lifecycle; this Skill for spec structure reference.
+-->
 
 # Spec-Driven Development Assistant | 規格驅動開發助手
 

package/bundled/skills/sweep/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: sweep
+scope: universal
+description: |
+  Scan codebase for debug artifacts and code quality issues; optionally auto-fix safe patterns.
+  Use when: before committing, during PR review, or periodic codebase cleanup.
+  Keywords: sweep, debug cleanup, console.log, debugger, TODO, ts-any, code quality, 掃描, 清理.
+allowed-tools: Read, Grep, Glob, Bash(find:*), Edit, Write
+argument-hint: "[--fix] [--report] [--path <dir>] [--exclude <pattern>]"
+---
+
+# Sweep Assistant | 掃碼助手
+
+> **Language**: English | 繁體中文
+
+Scan the codebase for debug artifacts, code quality issues, and technical debt markers.
+Optionally auto-fix safe patterns (console.log, debugger statements).
+
+---
+
+## Scan Patterns | 掃描模式
+
+| Pattern ID | Label | Auto-fixable | Description |
+|------------|-------|-------------|-------------|
+| `console-log` | console.log / console.debug / console.trace | ✅ Yes | Debug output left in production code |
+| `debugger` | debugger statement | ✅ Yes | Debugger breakpoints left in code |
+| `todo-fixme` | TODO / FIXME / HACK / XXX | ❌ Report only | Technical debt markers |
+| `ts-any` | TypeScript `any` type | ❌ Report only | Type safety violations |
+
+---
+
+## Usage | 使用方式
+
+```bash
+/sweep                        # Scan current directory, report findings
+/sweep --fix                  # Scan and auto-fix fixable patterns
+/sweep --report               # Scan and save report to .devap/sweep-report.json
+/sweep --path src/            # Scan specific directory
+/sweep --exclude "**/*.test.ts"  # Exclude patterns (glob)
+```
+
+---
+
+## Workflow | 執行工作流程
+
+### Step 1: Discover Files
+Use Glob tool to find all source files under the target path.
+Default excludes: `node_modules/`, `dist/`, `.git/`, `*.min.js`, `coverage/`.
+
+### Step 2: Scan Each Pattern
+For each pattern, use Grep to find matches across all files.
+Collect findings: `{ file, line, column, pattern_id, label, fixable, content }`.
+
+### Step 3: Report Findings
+Output a structured summary:
+```
+📊 Sweep Results
+─────────────────────────────────────
+console-log:   12 findings  (auto-fixable)
+debugger:       2 findings  (auto-fixable)
+todo-fixme:    28 findings  (report only)
+ts-any:         5 findings  (report only)
+─────────────────────────────────────
+Total: 47 findings  |  Fixable: 14
+```
+
+### Step 4: HITL Gate (if --fix and findings > 20)
+If `--fix` flag is set AND total fixable findings exceed 20:
+**Pause and require explicit user confirmation** before applying fixes.
+Show the list of files that will be modified.
+
+### Step 5: Apply Fixes (if --fix confirmed)
+For each fixable finding:
+- `console-log`: Remove the line if it contains only the console statement
+- `debugger`: Remove the line if it contains only the debugger statement
+
+Use Edit tool to apply changes file by file.
+Report: "Fixed N findings in M files."
+
+### Step 6: Save Report (if --report)
+Write findings to `.devap/sweep-report.json`:
+```json
+{
+  "timestamp": "<ISO8601>",
+  "total_findings": 47,
+  "fixable": 14,
+  "fixed": 14,
+  "findings_by_pattern": { "console-log": 12, "debugger": 2, "todo-fixme": 28, "ts-any": 5 },
+  "files_modified": ["src/auth.ts", "src/utils.ts"]
+}
+```
+
+---
+
+## Configuration | 設定
+
+Configure via `uds.project.yaml`:
+
+```yaml
+sweep:
+  default_path: "src/"
+  exclude_patterns:
+    - "**/*.test.ts"
+    - "**/*.spec.ts"
+    - "**/fixtures/**"
+  hitl_threshold: 20       # Require confirmation if fixable findings exceed this
+  patterns:
+    enabled:
+      - console-log
+      - debugger
+      - todo-fixme
+      - ts-any
+```
+
+---
+
+## Next Steps Guidance | 下一步引導
+
+After `/sweep` completes, suggest:
+
+> - Run `/checkin` to verify overall code quality before committing
+> - Run `/review` to review the cleaned-up changes
+> - Run `/commit` to commit the fixes
+
+---
+
+## Related Standards | 相關標準
+
+- [Checkin Standards](../../.standards/checkin-standards.ai.yaml) — Pre-commit quality gates
+- [Code Review](../code-review-assistant/SKILL.md) — Code review assistant
+- [Testing Guide](../testing-guide/SKILL.md) — Testing standards
+
+---
+
+## Version History | 版本歷程
+
+| Version | Date | Changes |
+|---------|------|---------|
+| 1.0.0 | 2026-04-28 | Initial release — XSPEC-097 Phase 1 (from DevAP sweep module) |
+
+---
+
+## License | 授權
+
+This skill is released under [MIT License](https://opensource.org/licenses/MIT) and [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

package/bundled/skills/tdd-assistant/SKILL.md

@@ -5,6 +5,13 @@ description: "[UDS] Guide through Test-Driven Development workflow"
 allowed-tools: Read, Write, Grep, Glob, Bash(npm test:*), Bash(npx vitest:*)
 argument-hint: "[feature or file | 功能或檔案]"
 ---
+<!-- DEPRECATION NOTICE (XSPEC-086 Phase 4, 2026-04-28):
+  TDD flow orchestration (RED→GREEN→REFACTOR cycle, test execution gates) extracted to:
+  - DevAP flow: dev-autopilot/.devap/flows/tdd.flow.yaml
+  - DevAP CLI:  devap tdd (packages/cli/src/commands/tdd.ts)
+  This Skill retains: TDD principles, FIRST rules, AAA format, language examples, workflow guide.
+  Use `devap tdd` for enforced interactive cycle; this Skill for practice reference.
+-->
 
 # TDD Assistant | TDD 助手