asiaostrich-universal-dev-standards

Plugin asiaostrich-universal-dev-standards from marketplace cascade-code-general-misc-3 in joshuarweaver/cascade-code-general-misc-3. Commands read from the repo's manifest — 1 month ago.

Skills (55)

• ac-coverage

  [UDS] 分析驗收條件（AC）與測試之間的追蹤關係，並產生需求層級的覆蓋率報告。 Use when: 稽核哪些驗收條件已有測試、從 SPEC 檔建立追蹤矩陣、發布前找出尚未被覆蓋的 AC。 Not for: 程式碼層級的行／分支／函式覆蓋率——請用 /coverage；補寫缺少的測試——請用 /tdd 或 /spec-derive。 Keywords: AC coverage, traceability, acceptance criteria, SPEC, traceability matrix, 驗收條件, 需求追蹤, 覆蓋率矩陣, 追蹤矩陣.

• adr

  [UDS] 建立、管理並追蹤架構決策記錄（ADR）。 Use when: 架構決策、技術選型、設計取捨、模式選擇。 Not for: 不改變架構的決策——記在規格或 commit 裡即可；想法還沒成形到足以下決定——請用 /brainstorm。 Keywords: ADR, architecture decision, decision record, trade-off, 架構決策, 決策記錄, 設計取捨.

• ai-collaboration-standards

  防止 AI 幻覺，確保分析程式碼或提出建議時給出以證據為基礎的回應。 Use when: 分析程式碼、提出建議、提供選項，或使用者詢問把握度／確定性時。 Not for: 撰寫 AI 指令檔本身——請用 /ai-instruction-standards；審查具體的 diff——請用 /code-review。 Keywords: certainty, assumption, inference, evidence, source, 證據, 假設, 推論, 確定性, 反幻覺.

• ai-friendly-architecture

  設計 AI 友善架構，包含明確的模式、分層文件與語意邊界。 Use when: 為 AI 協作規劃專案結構、最佳化程式碼庫以利 AI 分析、建立 AI 上下文。 Not for: 撰寫指令檔本身——請用 /ai-instruction-standards；依語言慣例安排目錄配置——請用 /project-structure-guide。 Keywords: architecture, AI-friendly, context, modules, documentation layers, .ai-context.yaml, 架構, AI 友善, 上下文, 語意邊界.

• ai-instruction-standards

  建立並維護 AI 指令檔（CLAUDE.md、AGENTS.md、.cursor/rules/ 等），並採用適當結構。 Use when: 建立 AI 指令檔、區分通用規則與專案特定規則、設定 AI 工具。 Not for: 調整程式碼庫結構讓 AI 好導覽——請用 /ai-friendly-architecture；要求以證據為基礎的回答——請用 /ai-collaboration-standards。 Keywords: CLAUDE.md, AGENTS.md, cursorrules, windsurfrules, clinerules, AI instructions, system

• api-design

  引導 API 設計，遵循 REST、GraphQL 與 gRPC 最佳實踐。 Use when: 設計 API、審查端點、API 版本策略決策。 Not for: 驗證運行中的 API 是否符合消費端期待——請用 /contract-test；API 背後的 schema 設計——請用 /database。 Keywords: API, REST, GraphQL, gRPC, endpoint, versioning, 介面設計, 端點, 版本策略.

• atdd

  [UDS] 驗收測試驅動開發（ATDD）的參考資料：INVEST 準則、Gherkin 驗收條件格式與 Three Amigos 結構。 Use when: 與 Product Owner 一起定義驗收條件、進行規格工作坊、用 INVEST 檢視使用者故事。 Not for: 執行 ATDD 生命週期或強制 PO 簽核關卡——該部分已移至採用層（XSPEC-095）；撰寫單元測試——請用 /tdd。 Keywords: ATDD, acceptance test, acceptance criteria, INVEST, specification workshop, Three Amigos

• audit

  [UDS] 診斷 UDS 安裝的健康狀態，並向上游提交結構化回饋。 Use when: .standards/ 看起來壞掉或不同步、驗證 manifest 完整性、回報既有 UDS 標準用起來的摩擦點。 Not for: 稽核你自己應用程式的程式碼品質——請用 /metrics 或 /code-review；相依套件與機密掃描——請用 /scan。 Keywords: UDS audit, health check, manifest integrity, standards feedback, friction, 安裝健康, 標準稽核, 回饋, 完整性檢查.

• bdd

  [UDS] 行為驅動開發（BDD）的參考資料：Gherkin 的 Given-When-Then 格式與 Three Amigos 結構。 Use when: 撰寫或審查 .feature 場景、選定通用語言、針對行為進行探索式對話。 Not for: 執行 BDD 生命週期或 RED/GREEN 自動化——該部分已移至採用層（XSPEC-095）；把 .feature 檔轉成 E2E 骨架——請用 /e2e。 Keywords: BDD, Gherkin, Given When Then, feature file, scenario, Three Amigos, 行為驅動開發, 場景, 特

• brainstorm

  [UDS] 在規格出現之前執行的結構化多角色腦力激盪，並附帶評分品質關卡。 Use when: 想法還很模糊、在敲定方向前探索替代方案、需要多樣性而不是第一個看似合理的答案。 Not for: 方向已經定了的工作規劃——請用 /plan 或 /sdd；記錄已經做成的決策——請用 /adr。 Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 腦力激盪, 發想, 發散收斂, 多角色.

• changelog

  [UDS] 以 Keep a Changelog 格式產生並維護 CHANGELOG.md 條目。 Use when: 從 commit 歷史撰寫變更日誌條目、填寫 Unreleased 區段、將變更分類為 Added/Changed/Fixed。 Not for: 決定下一個版本號或執行發版——請用 /release；撰寫 commit message 本身——請用 /commit。 Keywords: changelog, CHANGELOG.md, Keep a Changelog, release notes, unreleased, 變更日誌, 發布說明, 版本紀錄.

• checkin

  [UDS] 提交前品質關卡的參考資料：關卡定義、檢查清單項目，以及絕不可提交的規則。 Use when: 決定 commit 前必須通過哪些檢查、稽核專案實際強制了哪些品質關卡、確認是否已可簽入。 Not for: 執行關卡流程或中止 commit——該部分已移至採用層（XSPEC-095）；找出並清除除錯殘留——請用 /sweep。 Keywords: check-in, pre-commit, quality gate, commit readiness, never commit, 簽入, 提交前檢查, 品質關卡, 檢查清單.

• ci-cd

  引導 CI/CD 管線的設計、設定與最佳化。 Use when: 建置管線、縮短建置時間、設定部署階段。 Not for: 沒有 CI/CD 平台的部署——請用 /deploy；版本號遞增與晉級——請用 /release。 Keywords: CI/CD, pipeline, GitHub Actions, deployment, build, 持續整合, 持續部署, 管線.

• code-review

  [UDS] 系統性程式碼審查的參考資料：八大審查類別，以及 BLOCKING/IMPORTANT/SUGGESTION 評論前綴。 Use when: 審查 pull request 或 diff、決定審查意見的措辭與優先序、與團隊議定審查範圍。 Not for: 執行有關卡的審查流程——該部分已移至採用層（XSPEC-095）；提交前的關卡驗證——請用 /checkin。 Keywords: code review, pull request review, review checklist, BLOCKING, comment prefix, 程式碼審查, 審查類別, 評論前綴, 審查清單

• commit

  [UDS] 產生符合 Conventional Commits 規範的 commit message，包含雙語格式。 Use when: 為已暫存的變更撰寫 commit message、選擇 type 與 scope、產出英文與中文並列的主旨與內文。 Not for: 判斷這份變更是否已可提交——請用 /checkin；把多個 commit 彙整成發布說明——請用 /changelog。 Keywords: commit message, Conventional Commits, feat, fix, refactor, scope, bilingual, 提交訊息, 雙語 commit,

• contract-test

  [UDS] 引導 API 與微服務的合約測試策略。 Use when: API 合約、微服務、消費者驅動測試、提供者驗證。 Not for: 一開始的 API 介面設計——請用 /api-design；經由 UI 的使用者可見流程——請用 /e2e。 Keywords: contract test, Pact, OpenAPI, consumer-driven, provider, 合約測試, 消費者驅動, 提供者驗證.

• database

  引導資料庫設計、遷移與查詢最佳化。 Use when: schema 設計、遷移規劃、查詢最佳化、索引策略。 Not for: 應用程式碼遷移或框架升級——請用 /migrate；資料之上的 API 合約——請用 /api-design。 Keywords: database, schema, migration, SQL, index, query, 資料庫, 遷移, 查詢, 索引策略.

• deploy

  引導在沒有 CI/CD 平台（GitHub Actions／GitLab CI）的情況下完成可靠部署。 Use when: 部署到 VPS、離線隔離的伺服器，或任何沒有 CI/CD 基礎設施的環境。 Not for: 建立在 GitHub Actions 或 GitLab CI 上的管線——請用 /ci-cd；版本號遞增與發布晉級——請用 /release。 Keywords: deployment, no-cicd, shell script, blue-green, smoke test, rollback, 無 CI/CD, 部署, 藍綠部署, 回滾.

• methodology

  [UDS] 為專案選擇並追蹤當前採用的開發方法論（SDD、BDD、TDD）。 Use when: 決定專案該遵循哪一套方法論、切換方法論、查詢目前方法論處於哪個階段。 Not for: 查詢某個開發階段該執行哪個指令——請用 /dev-workflow；執行方法論本身——請用 /sdd、/bdd 或 /tdd。 Keywords: methodology, SDD, BDD, TDD, phase tracking, methodology selection, 方法論, 開發方法選擇, 階段追蹤.

• dev-workflow

  [UDS] 把目前的軟體開發階段對應到正確的 UDS 指令與 Skill。 Use when: 不確定手上的任務該用哪個 UDS 指令、初次上手 UDS、帶著一個功能從規劃走到發布。 Not for: 選擇或切換方法論——請用 /methodology；實際執行某階段的工作——請用該階段自己的 Skill。 Keywords: workflow, development phase, command routing, which command, UDS guide, 開發階段, 指令對照, 流程指南.

• docgen

  [UDS] 從專案原始檔產生使用文件（速查表、參考手冊、使用指南）。 Use when: 從 CLI 與 Skill 定義產出速查表或功能參考手冊、指令變更後重新產生文件、確認產生的文件是否為最新。 Not for: 決定專案需要哪些文件或手寫敘述性內容——請用 /documentation-guide；變更日誌條目——請用 /changelog。 Keywords: docgen, usage docs, cheatsheet, feature reference, generated documentation, 使用文件, 速查表, 文件產生, 參考手冊.

• documentation-guide

  引導文件結構、內容需求與專案文件的最佳實踐。 Use when: 建立 README、撰寫文件、規劃 docs 目錄、專案初始設定、技術文件。 Not for: 從原始碼機械式產生文件——請用 /docgen；變更日誌條目——請用 /changelog。 Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, ARCHITECTURE, API docs, 文件, 說明文件, 技術文件.

• durable

  [UDS] 引導容錯工作流程設計，包含檢查點、重試策略與回滾計畫。 Use when: 長時間執行的工作流程總是中途失敗、設計檢查點的粒度、選擇重試或退避策略。 Not for: 處理正在發生中的線上事故——請用 /incident；部署回滾的實作機制——請用 /deploy。 Keywords: durable execution, checkpoint, retry, backoff, idempotency, rollback, 持久執行, 檢查點, 重試策略, 冪等.

• e2e

  [UDS] 從 BDD 的 .feature 場景產生 E2E 測試骨架，並支援框架偵測與覆蓋缺口分析。 Use when: 把已完成的 .feature 場景轉成可執行的 E2E 骨架、偵測專案使用的 E2E 框架、找出沒有 E2E 覆蓋的 AC。 Not for: 跨多個故事且帶有共用狀態的旅程——請用 journey-test Skill；撰寫 .feature 場景本身——請用 /bdd。 Keywords: E2E, end-to-end test, feature file, test skeleton, framework detection, 端對端測試, 測試骨架, 場景轉測

• error-code-guide

  設計一致的錯誤碼，遵循 PREFIX_CATEGORY_NUMBER 格式。 Use when: 定義錯誤碼、建立錯誤處理機制、設計 API。 Not for: 日誌格式與層級——請用 /logging-guide；處理已經到達正式環境的錯誤——請用 /incident。 Keywords: error code, error handling, error format, API errors, 錯誤碼, 錯誤處理, 錯誤格式.

• git-workflow-guide

  引導 Git 分支策略、分支命名與合併操作。 Use when: 建立分支、合併、pull request、Git 工作流程相關問題。 Not for: 撰寫 commit message——請用 /commit；推送前的安全檢查——請用 /push。 Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow, 分支, 合併, 工作流程, 分支命名.

• incident

  引導事故回應、根因分析與事後檢討文件撰寫。 Use when: 正式環境事故、服務中斷回應、撰寫事後檢討、根因分析（RCA）。 Not for: 在故障發生前設計重試與檢查點——請用 /durable；設定告警門檻與 Error Budget 政策——請用 /slo。 Keywords: incident, outage, post-mortem, RCA, root cause, 事故, 服務中斷, 事後檢討, 根因分析.

• journey-test-assistant

  [UDS] 從專案描述產生連貫的使用者旅程測試計畫（TESTPLAN）與旅程 E2E 骨架。 Use when: 新專案從第一天就需要一條測試旅程、測試跨多個故事延續的狀態、建立以人物誌驅動的旅程計畫。 Not for: 單一 AC 的獨立 E2E 骨架——請用 /e2e；量測實際達成的程式碼覆蓋率——請用 /coverage。 Keywords: user journey, TESTPLAN, journey test, persona, cross-story state, 使用者旅程, 旅程測試, 測試計畫, 人物誌.

• knowledge-graph

  [UDS] 透過知識圖追蹤規格、決策與程式碼之間的影響鏈；沒有引擎時以 Markdown 後備方案運作。 Use when: 想知道某份規格或決策會影響到什麼、找出哪些程式碼實作了某個產物、追蹤規格、ADR 與模組之間的相依關係。 Not for: 沒有規格或決策錨點的純文字搜尋——請用 Grep；撰寫規格本身——請用 /sdd。 Keywords: knowledge graph, impact chain, traceability, spec impact, decision graph, 知識圖, 影響鏈, 規格追蹤, 相依關係.

• logging-guide

  實作結構化日誌，包含適當的日誌層級與敏感資料處理。 Use when: 加入日誌、除錯、建立可觀測性。 Not for: 指標、追蹤與告警設計——請用 /observability；錯誤碼分類體系——請用 /error-code-guide。 Keywords: logging, log level, structured logging, observability, 日誌, 結構化日誌, 日誌層級, 敏感資料.

• metrics

  [UDS] 長期追蹤開發指標、程式碼品質指標與技術債。 Use when: 評估專案的持續健康狀態、分類技術債並觀察其趨勢、向團隊回報程式碼品質。 Not for: 初次評估一個不熟悉的程式碼庫——請用 /discover；單看測試覆蓋率——請用 /coverage 或 /ac-coverage。 Keywords: metrics, code quality, technical debt, project health, debt trend, 開發指標, 技術債, 專案健康度, 品質趨勢.

• migrate

  [UDS] 引導系統性的程式碼遷移、框架升級與技術現代化。 Use when: 規劃框架或主版本升級、評估遷移風險、在 API 遷移前先擷取合約測試的固定樣本。 Not for: 維持同一套框架的原地改善——請用 /refactor；資料庫 schema 設計——請用 /database。 Keywords: migration, framework upgrade, modernization, breaking change, dependency upgrade, 遷移, 升級, 技術現代化, 破壞性變更.

• observability

  引導可觀測性建置、指標設計與告警設定。 Use when: 新服務的埋點、SLO 定義、告警設計、成熟度評估。 Not for: 設定數值目標與 Error Budget 政策——請用 /slo；日誌格式與層級——請用 /logging-guide。 Keywords: observability, metrics, traces, golden signals, alerting, SLO, 可觀測性, 指標, 追蹤, 告警.

• orchestrate

  以 Claude 原生 Agent tool 編排多任務執行計畫（以 DAG 為基礎，不需外部引擎）。 Use when: 執行帶有平行／循序任務相依關係的 plan.json 檔案。 Not for: 一開始產生計畫——請用 /plan；彼此之間沒有相依關係的單一任務。 Keywords: orchestrate, plan, execute, DAG, task plan, 編排, 執行計畫, 並行, 任務相依.

• plan

  從 Spec 文件、OpenSpec 變更或自由文字需求生成 plan.json。 Use when: 把規格轉換成可供 /orchestrate 執行的任務計畫。 Not for: 執行產出的計畫——請用 /orchestrate；判斷這個想法值不值得做——請用 /brainstorm。 Keywords: plan, spec, task plan, plan.json, DAG, 計畫, 規格, 任務, 任務計畫.

• pr

  引導 pull request 建立、審查自動化與合併策略。 Use when: 建立 PR、自動化審查流程、設定合併政策。 Not for: 審查本身的內容實質——請用 /code-review；分支命名與合併策略——請用 /git-workflow-guide。 Keywords: pull request, PR, merge, review, GitHub, GitLab, 合併請求, 審查自動化, 合併策略.

• discover

  [UDS] 在既有程式碼庫新增功能之前，評估專案健康度、架構與風險。 Use when: 接手不熟悉或老舊的專案、動工前先估算風險、建立風險登記簿。 Not for: 對已經熟悉的程式碼庫做持續指標追蹤——請用 /metrics；從程式碼回推規格——請用 /reverse。 Keywords: discovery, project assessment, legacy onboarding, risk register, technical debt, 現況評估, 專案盤點, 風險登記簿, 老舊系統.

• project-structure-guide

  依各語言的最佳實踐組織專案目錄結構的指南。 Use when: 建立專案、重整結構、新增模組、設定建置流程、決定檔案該放哪裡。 Not for: 專門為 AI 導覽而設計的結構——請用 /ai-friendly-architecture；原地重整既有程式碼——請用 /refactor。 Keywords: project, structure, directory, layout, gitignore, scaffold, file placement, utils, helpers, shared, 專案結構, 目錄配置, 檔案擺放.

• push

  AI 輔助的 git push 安全層，提供品質關卡與協作護欄。 Use when: 推送 commit、強制推送、推送到受保護分支、推送 feature 分支。 Not for: 撰寫 commit 內容——請用 /commit；分支與合併策略的決策——請用 /git-workflow-guide。 Keywords: git push, force push, protected branch, quality gate, push receipt, PR automation, 推送, 保護分支, 品質閘門, 強制推送.

• refactor

  [UDS] 引導重構決策與策略選擇，包含「重構還是重寫」這個判斷。 Use when: 程式碼已經難以修改、在戰術性與架構性重構之間做選擇、要在老舊程式碼裡安全地動手。 Not for: 換到不同框架或主版本——請用 /migrate；清除除錯殘留與死碼——請用 /sweep。 Keywords: refactor, rewrite, strangler, legacy code, technical debt, code smell, 重構, 重寫, 技術債, 壞味道.

• release

  [UDS] 引導發布流程——語意化版本、發布模式，以及 start/finish/promote/deploy 的順序。 Use when: 切一個發布版本、決定語意化版本要升哪一位、把 release candidate 晉級為穩定版、記錄一次部署。 Not for: 撰寫變更日誌條目本身——請用 /changelog；部署的實作機制——請用 /deploy。 Keywords: release, semantic versioning, version bump, release candidate, promote, 發布, 語意化版本, 發版流程, 版本晉級.

• requirement

  [UDS] 撰寫符合 INVEST 準則的使用者故事與需求。 Use when: 把一個功能構想轉成使用者故事、定義可測試的驗收條件、檢視待辦項目的品質。 Not for: 帶有設計與差異操作的完整規格文件——請用 /sdd；判斷這個構想本身對不對——請用 /brainstorm。 Keywords: requirement, user story, INVEST, acceptance criteria, backlog refinement, 需求, 使用者故事, 驗收條件, 待辦整理.

• retrospective

  [UDS] 引導 Sprint 與 Release 週期的結構化團隊回顧。 Use when: Sprint 結束、發布後檢討、迭代審視、流程改善。 Not for: 正式環境事故的事後檢討——請用 /incident；追蹤兩次回顧之間的指標趨勢——請用 /metrics。 Keywords: retrospective, retro, sprint review, lessons learned, action items, 回顧, 復盤, 迭代審視, 流程改善.

• reverse

  [UDS] 系統考古——從邏輯、資料、執行環境三個維度對既有系統做反向工程。 Use when: 為沒有文件的系統補上文件、從既有程式碼回推規格、繪製未知的資料模型或執行環境拓樸。 Not for: 動工前評估健康度與風險——請用 /discover；從已核准的規格正向推導測試——請用 /spec-derive。 Keywords: reverse engineering, system archeology, legacy code, spec extraction, data model, runtime, 反向工程, 系統考古, 規格提取, 資料模型.

• runbook

  引導 Runbook 的撰寫、維護與演練。 Use when: 撰寫 Runbook、規劃演練、稽核 Runbook 覆蓋範圍、事故後更新 Runbook。 Not for: 處理正在進行中的事故——請用 /incident；部署程序本身——請用 /deploy。 Keywords: runbook, operations, drill, on-call, procedure, 維運手冊, 演練, 待命, 標準程序.

• security

  引導安全審查與弱點評估，遵循 OWASP 標準。 Use when: 安全稽核、弱點檢查、安全程式碼審查、威脅建模。 Not for: 自動化的相依套件、CVE 與機密掃描——請用 /scan；處理正在發生的資安事件——請用 /incident。 Keywords: security, OWASP, vulnerability, authentication, authorization, 資訊安全, 弱點, 認證, 授權, 威脅建模.

• scan

  引導自動化安全掃描、相依套件稽核與機密偵測。 Use when: 相依套件稽核、CVE 掃描、機密偵測、授權條款合規。 Not for: 人工的威脅建模與安全設計審查——請用 /security；一般的程式碼整潔度——請用 /sweep。 Keywords: scan, audit, CVE, dependency, secret, SBOM, vulnerability, 掃描, 稽核, 相依套件, 機密偵測.

• skill-builder

  [UDS] 把重複的手動流程轉成範圍界定得宜的 Skill，過程中拿捏恰當的流程份量。 Use when: 同一段多步驟流程已經手動做過三次以上、把臨時湊出來的 Skill 正式化、決定某個 Skill 該放在哪一層。 Not for: 記錄歷史事實或專案狀態——那屬於記憶，不是 Skill；不會再發生的一次性任務。 Keywords: skill, skill builder, process knowledge, repeated process, automation, 技能建立, 流程知識, 自動化, 重複流程.

• slo

  引導 SLI 選取、SLO 設定與 Error Budget 管理。 Use when: 定義服務品質目標、建立以 SLO 為基礎的告警、Error Budget 政策。 Not for: 埋點與指標收集——請用 /observability；處理正在違反目標的狀況——請用 /incident。 Keywords: SLI, SLO, SLA, Error Budget, burn rate, service level, 服務等級, 錯誤預算, 燃燒率, 服務品質目標.

• spec-derive

  [UDS] 從已核准的規格推導出 BDD 場景、TDD 骨架、整合與 E2E 測試，以及 ATDD 表格。 Use when: 規格已核准且需要產出測試產物、從驗收條件產生帶標籤的測試骨架、從規格產生合約樁。 Not for: 從既有程式碼回推規格——請用 /reverse；撰寫或審查規格本身——請用 /sdd。 Keywords: forward derivation, spec to test, BDD scenario, TDD skeleton, ATDD table, 正向推演, 規格衍生, 測試生成, 合約樁.

• sdd

  [UDS] 在寫程式碼之前建立並審查規格文件——規格格式、狀態與差異操作。 Use when: 某項變更需要先有書面規格、審查規格的完整性、用 delta 區段修訂既有規格。 Not for: 執行帶關卡的 SDD 生命週期——該部分已移至採用層（XSPEC-095）；快速迭代用的輕量微規格——請用 uds spec 指令。 Keywords: SDD, spec, specification, design document, delta operation, spec review, 規格驅動開發, 規格文件, 變更操作, 規格審查.

• sweep

  掃描程式碼庫中的除錯殘留與程式碼品質問題；可選擇自動修正安全的模式。 Use when: 提交前、PR 審查期間，或定期清理程式碼庫。 Not for: 結構性的程式碼改善——請用 /refactor；針對安全的專門掃描——請用 /scan。 Keywords: sweep, debug cleanup, console.log, debugger, TODO, ts-any, code quality, 掃描, 清理, 除錯殘留.

• tdd

  [UDS] 測試驅動開發（TDD）的參考資料：紅-綠-重構循環、FIRST 原則與 Arrange-Act-Assert 結構。 Use when: 在實作前先寫一個會失敗的測試、用 Arrange-Act-Assert 組織測試、以 FIRST 檢視既有測試。 Not for: 互動式地驅動 RED/GREEN 循環——該部分已移至採用層（XSPEC-095）；量測測試涵蓋了多少程式碼——請用 /coverage。 Keywords: TDD, test first, Red Green Refactor, FIRST, Arrange Act Assert, unit test, 測試驅動

• coverage

  [UDS] 以八維度框架分析程式碼層級的測試覆蓋率，並建議該優先補上哪些缺口。 Use when: 覆蓋率數字看起來很健康但缺陷照樣流出、要在行覆蓋率之外判斷測試完整性、設定覆蓋率目標。 Not for: 需求層級的 AC 與測試追蹤——請用 /ac-coverage；補寫缺少的測試——請用 /tdd 或 /spec-derive。 Keywords: test coverage, eight dimensions, line coverage, branch coverage, test quality, 測試覆蓋率, 八維度, 測試完整性, 覆蓋缺口.

• testing-guide

  測試金字塔，以及 UT/IT/ST/E2E 的測試撰寫標準。 支援 ISTQB 與業界通行金字塔兩種框架。 Use when: 撰寫測試、討論測試覆蓋率、測試策略或測試命名時。 Not for: 驅動紅-綠-重構循環——請用 /tdd；量測實際達成的覆蓋率——請用 /coverage。 Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元測試, 整合測試, 端對端.

Similar plugins