菜单
这个仓库中的 skills
SkillsMP 已收集 AsiaOstrich/universal-dev-standards 中的 211 个 Skill。打开任一 Skill 可查看来源和详情。
AsiaOstrich/universal-dev-standards已展示 40 / 211 个已收集 Skill。
[UDS] Guide contract testing strategy for APIs and microservices. Use when: API contracts, microservices, consumer-driven testing, provider verification. Not for: designing the API surface in the first place — use /api-design; user-visible flows through a UI…
原文语言：多语言混合
Guide observability setup, metrics design, and alerting configuration. Use when: new service instrumentation, SLO definition, alert design, maturity assessment. Not for: setting numeric targets and Error Budget policy — use /slo; log format and levels — use…
原文语言：英语
[UDS] Assess project health, architecture, and risks before adding features to an existing codebase. Use when: onboarding to an unfamiliar or legacy project, sizing risk before starting a feature, building a risk register. Not for: ongoing metric tracking on…
原文语言：英语
Guide for organizing project directories following language-specific best practices. Use when: creating projects, reorganizing structure, adding modules, setting up builds, deciding file placement. Not for: structuring specifically for AI navigation — use…
原文语言：英语
Guide runbook creation, maintenance, and drill exercises. Use when: writing runbooks, planning drills, auditing runbook coverage, post-incident runbook updates. Not for: responding to an incident already in progress — use /incident; the deployment procedure…
原文语言：英语
Guide SLI selection, SLO setting, and Error Budget management. Use when: defining service quality targets, setting up SLO-based alerting, Error Budget policy. Not for: instrumentation and metric collection — use /observability; responding to an active breach…
原文语言：英语
[UDS] 在規格出現之前執行的結構化多角色腦力激盪，並附帶評分品質關卡。 Use when: 想法還很模糊、在敲定方向前探索替代方案、需要多樣性而不是第一個看似合理的答案。 Not for: 方向已經定了的工作規劃——請用 /plan 或 /sdd；記錄已經做成的決策——請用 /adr。 Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 腦力激盪, 發想, 發散收斂, 多角色.
[UDS] 在规格出现之前执行的结构化多角色头脑风暴，并附带评分质量关卡。 Use when: 想法还很模糊、在敲定方向前探索替代方案、需要多样性而不是第一个看似合理的答案。 Not for: 方向已经定了的工作规划——请用 /plan 或 /sdd；记录已经做成的决策——请用 /adr。 Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 头脑风暴, 发想, 发散收敛, 多角色.
[UDS] 在規格出現之前執行的結構化多角色腦力激盪，並附帶評分品質關卡。 Use when: 想法還很模糊、在敲定方向前探索替代方案、需要多樣性而不是第一個看似合理的答案。 Not for: 方向已經定了的工作規劃——請用 /plan 或 /sdd；記錄已經做成的決策——請用 /adr。 Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 腦力激盪, 發想, 發散收斂, 多角色.
[UDS] Structured multi-persona brainstorming with a scored quality gate, run before a spec exists. Use when: an idea is still vague, exploring alternatives before committing to a direction, needing diversity rather than the first plausible answer. Not for:…
原文语言：多语言混合
[UDS] 分析驗收條件（AC）與測試之間的追蹤關係，並產生需求層級的覆蓋率報告。 Use when: 稽核哪些驗收條件已有測試、從 SPEC 檔建立追蹤矩陣、發布前找出尚未被覆蓋的 AC。 Not for: 程式碼層級的行／分支／函式覆蓋率——請用 /coverage；補寫缺少的測試——請用 /tdd 或 /spec-derive。 Keywords: AC coverage, traceability, acceptance criteria, SPEC, traceability matrix, 驗收條件,…
[UDS] 建立、管理並追蹤架構決策記錄（ADR）。 Use when: 架構決策、技術選型、設計取捨、模式選擇。 Not for: 不改變架構的決策——記在規格或 commit 裡即可；想法還沒成形到足以下決定——請用 /brainstorm。 Keywords: ADR, architecture decision, decision record, trade-off, 架構決策, 決策記錄, 設計取捨.
防止 AI 幻覺，確保分析程式碼或提出建議時給出以證據為基礎的回應。 Use when: 分析程式碼、提出建議、提供選項，或使用者詢問把握度／確定性時。 Not for: 撰寫 AI 指令檔本身——請用 /ai-instruction-standards；審查具體的 diff——請用 /code-review。 Keywords: certainty, assumption, inference, evidence, source, 證據, 假設, 推論, 確定性, 反幻覺.
設計 AI 友善架構，包含明確的模式、分層文件與語意邊界。 Use when: 為 AI 協作規劃專案結構、最佳化程式碼庫以利 AI 分析、建立 AI 上下文。 Not for: 撰寫指令檔本身——請用 /ai-instruction-standards；依語言慣例安排目錄配置——請用 /project-structure-guide。 Keywords: architecture, AI-friendly, context, modules, documentation layers,…
建立並維護 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,…
原文语言：多语言混合
引導 API 設計，遵循 REST、GraphQL 與 gRPC 最佳實踐。 Use when: 設計 API、審查端點、API 版本策略決策。 Not for: 驗證運行中的 API 是否符合消費端期待——請用 /contract-test；API 背後的 schema 設計——請用 /database。 Keywords: API, REST, GraphQL, gRPC, endpoint, versioning, 介面設計, 端點, 版本策略.
[UDS] 診斷 UDS 安裝的健康狀態，並向上游提交結構化回饋。 Use when: .standards/ 看起來壞掉或不同步、驗證 manifest 完整性、回報既有 UDS 標準用起來的摩擦點。 Not for: 稽核你自己應用程式的程式碼品質——請用 /metrics 或 /code-review；相依套件與機密掃描——請用 /scan。 Keywords: UDS audit, health check, manifest integrity, standards feedback,…
[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…
[UDS] 提交前品質關卡的參考資料：關卡定義、檢查清單項目，以及絕不可提交的規則。 Use when: 決定 commit 前必須通過哪些檢查、稽核專案實際強制了哪些品質關卡、確認是否已可簽入。 Not for: 執行關卡流程或中止 commit——該部分已移至採用層（XSPEC-095）；找出並清除除錯殘留——請用 /sweep。 Keywords: check-in, pre-commit, quality gate, commit readiness, never commit, 簽入, 提交前檢查,…
引導 CI/CD 管線的設計、設定與最佳化。 Use when: 建置管線、縮短建置時間、設定部署階段。 Not for: 沒有 CI/CD 平台的部署——請用 /deploy；版本號遞增與晉級——請用 /release。 Keywords: CI/CD, pipeline, GitHub Actions, deployment, build, 持續整合, 持續部署, 管線.
引導資料庫設計、遷移與查詢最佳化。 Use when: schema 設計、遷移規劃、查詢最佳化、索引策略。 Not for: 應用程式碼遷移或框架升級——請用 /migrate；資料之上的 API 合約——請用 /api-design。 Keywords: database, schema, migration, SQL, index, query, 資料庫, 遷移, 查詢, 索引策略.
引導在沒有 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,…
[UDS] 把目前的軟體開發階段對應到正確的 UDS 指令與 Skill。 Use when: 不確定手上的任務該用哪個 UDS 指令、初次上手 UDS、帶著一個功能從規劃走到發布。 Not for: 選擇或切換方法論——請用 /methodology；實際執行某階段的工作——請用該階段自己的 Skill。 Keywords: workflow, development phase, command routing, which command, UDS guide, 開發階段, 指令對照, 流程指南.
[UDS] 從專案原始檔產生使用文件（速查表、參考手冊、使用指南）。 Use when: 從 CLI 與 Skill 定義產出速查表或功能參考手冊、指令變更後重新產生文件、確認產生的文件是否為最新。 Not for: 決定專案需要哪些文件或手寫敘述性內容——請用 /documentation-guide；變更日誌條目——請用 /changelog。 Keywords: docgen, usage docs, cheatsheet, feature reference, generated…
引導文件結構、內容需求與專案文件的最佳實踐。 Use when: 建立 README、撰寫文件、規劃 docs 目錄、專案初始設定、技術文件。 Not for: 從原始碼機械式產生文件——請用 /docgen；變更日誌條目——請用 /changelog。 Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, ARCHITECTURE, API docs, 文件, 說明文件, 技術文件.
[UDS] 引導容錯工作流程設計，包含檢查點、重試策略與回滾計畫。 Use when: 長時間執行的工作流程總是中途失敗、設計檢查點的粒度、選擇重試或退避策略。 Not for: 處理正在發生中的線上事故——請用 /incident；部署回滾的實作機制——請用 /deploy。 Keywords: durable execution, checkpoint, retry, backoff, idempotency, rollback, 持久執行, 檢查點, 重試策略, 冪等.
[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…
設計一致的錯誤碼，遵循 PREFIX_CATEGORY_NUMBER 格式。 Use when: 定義錯誤碼、建立錯誤處理機制、設計 API。 Not for: 日誌格式與層級——請用 /logging-guide；處理已經到達正式環境的錯誤——請用 /incident。 Keywords: error code, error handling, error format, API errors, 錯誤碼, 錯誤處理, 錯誤格式.
引導 Git 分支策略、分支命名與合併操作。 Use when: 建立分支、合併、pull request、Git 工作流程相關問題。 Not for: 撰寫 commit message——請用 /commit；推送前的安全檢查——請用 /push。 Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow, 分支, 合併, 工作流程, 分支命名.
引導事故回應、根因分析與事後檢討文件撰寫。 Use when: 正式環境事故、服務中斷回應、撰寫事後檢討、根因分析（RCA）。 Not for: 在故障發生前設計重試與檢查點——請用 /durable；設定告警門檻與 Error Budget 政策——請用 /slo。 Keywords: incident, outage, post-mortem, RCA, root cause, 事故, 服務中斷, 事後檢討, 根因分析.
[UDS] 從專案描述產生連貫的使用者旅程測試計畫（TESTPLAN）與旅程 E2E 骨架。 Use when: 新專案從第一天就需要一條測試旅程、測試跨多個故事延續的狀態、建立以人物誌驅動的旅程計畫。 Not for: 單一 AC 的獨立 E2E 骨架——請用 /e2e；量測實際達成的程式碼覆蓋率——請用 /coverage。 Keywords: user journey, TESTPLAN, journey test, persona, cross-story state, 使用者旅程, 旅程測試,…
[UDS] 透過知識圖追蹤規格、決策與程式碼之間的影響鏈；沒有引擎時以 Markdown 後備方案運作。 Use when: 想知道某份規格或決策會影響到什麼、找出哪些程式碼實作了某個產物、追蹤規格、ADR 與模組之間的相依關係。 Not for: 沒有規格或決策錨點的純文字搜尋——請用 Grep；撰寫規格本身——請用 /sdd。 Keywords: knowledge graph, impact chain, traceability, spec impact, decision graph, 知識圖,…
實作結構化日誌，包含適當的日誌層級與敏感資料處理。 Use when: 加入日誌、除錯、建立可觀測性。 Not for: 指標、追蹤與告警設計——請用 /observability；錯誤碼分類體系——請用 /error-code-guide。 Keywords: logging, log level, structured logging, observability, 日誌, 結構化日誌, 日誌層級, 敏感資料.
[UDS] 長期追蹤開發指標、程式碼品質指標與技術債。 Use when: 評估專案的持續健康狀態、分類技術債並觀察其趨勢、向團隊回報程式碼品質。 Not for: 初次評估一個不熟悉的程式碼庫——請用 /discover；單看測試覆蓋率——請用 /coverage 或 /ac-coverage。 Keywords: metrics, code quality, technical debt, project health, debt trend, 開發指標, 技術債, 專案健康度, 品質趨勢.
[UDS] 引導系統性的程式碼遷移、框架升級與技術現代化。 Use when: 規劃框架或主版本升級、評估遷移風險、在 API 遷移前先擷取合約測試的固定樣本。 Not for: 維持同一套框架的原地改善——請用 /refactor；資料庫 schema 設計——請用 /database。 Keywords: migration, framework upgrade, modernization, breaking change, dependency upgrade, 遷移, 升級, 技術現代化, 破壞性變更.
以 Claude 原生 Agent tool 編排多任務執行計畫（以 DAG 為基礎，不需外部引擎）。 Use when: 執行帶有平行／循序任務相依關係的 plan.json 檔案。 Not for: 一開始產生計畫——請用 /plan；彼此之間沒有相依關係的單一任務。 Keywords: orchestrate, plan, execute, DAG, task plan, 編排, 執行計畫, 並行, 任務相依.
從 Spec 文件、OpenSpec 變更或自由文字需求生成 plan.json。 Use when: 把規格轉換成可供 /orchestrate 執行的任務計畫。 Not for: 執行產出的計畫——請用 /orchestrate；判斷這個想法值不值得做——請用 /brainstorm。 Keywords: plan, spec, task plan, plan.json, DAG, 計畫, 規格, 任務, 任務計畫.
引導 pull request 建立、審查自動化與合併策略。 Use when: 建立 PR、自動化審查流程、設定合併政策。 Not for: 審查本身的內容實質——請用 /code-review；分支命名與合併策略——請用 /git-workflow-guide。 Keywords: pull request, PR, merge, review, GitHub, GitLab, 合併請求, 審查自動化, 合併策略.
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, 推送, 保護分支,…
[UDS] 引導重構決策與策略選擇，包含「重構還是重寫」這個判斷。 Use when: 程式碼已經難以修改、在戰術性與架構性重構之間做選擇、要在老舊程式碼裡安全地動手。 Not for: 換到不同框架或主版本——請用 /migrate；清除除錯殘留與死碼——請用 /sweep。 Keywords: refactor, rewrite, strangler, legacy code, technical debt, code smell, 重構, 重寫, 技術債, 壞味道.