All authors
Claude Skills by AsiaOstrich
github.com/AsiaOstrich272 skills0 installs398 views
- Reverse Engineer[UDS] 系統考古——從邏輯、資料、執行環境三個維度對既有系統做反向工程。 Use when: 為沒有文件的系統補上文件、從既有程式碼回推規格、繪製未知的資料模型或執行環境拓樸。 Not for: 動工前評估健康度與風險——請用 /discover；從已核准的規格正向推導測試——請用 /spec-derive。 Keywords: reverse engineering, system archeology, legacy code, spec extraction, data model, runtime, 反向工程, 系統考古, 規格提取, 資料模型.Votes: 0GitHub stars: 75
- Security Scan Assistant引導自動化安全掃描、相依套件稽核與機密偵測。 Use when: 相依套件稽核、CVE 掃描、機密偵測、授權條款合規。 Not for: 人工的威脅建模與安全設計審查——請用 /security；一般的程式碼整潔度——請用 /sweep。 Keywords: scan, audit, CVE, dependency, secret, SBOM, vulnerability, 掃描, 稽核, 相依套件, 機密偵測.Votes: 0GitHub stars: 75
- Skill Builder[UDS] 把重複的手動流程轉成範圍界定得宜的 Skill，過程中拿捏恰當的流程份量。 Use when: 同一段多步驟流程已經手動做過三次以上、把臨時湊出來的 Skill 正式化、決定某個 Skill 該放在哪一層。 Not for: 記錄歷史事實或專案狀態——那屬於記憶，不是 Skill；不會再發生的一次性任務。 Keywords: skill, skill builder, process knowledge, repeated process, automation, 技能建立, 流程知識, 自動化, 重複流程.Votes: 0GitHub stars: 75
- Slo Assistant引導 SLI 選取、SLO 設定與 Error Budget 管理。 Use when: 定義服務品質目標、建立以 SLO 為基礎的告警、Error Budget 政策。 Not for: 埋點與指標收集——請用 /observability；處理正在違反目標的狀況——請用 /incident。 Keywords: SLI, SLO, SLA, Error Budget, burn rate, service level, 服務等級, 錯誤預算, 燃燒率, 服務品質目標.Votes: 0GitHub stars: 75
- Spec Derivation[UDS] 從已核准的規格推導出 BDD 場景、TDD 骨架、整合與 E2E 測試，以及 ATDD 表格。 Use when: 規格已核准且需要產出測試產物、從驗收條件產生帶標籤的測試骨架、從規格產生合約樁。 Not for: 從既有程式碼回推規格——請用 /reverse；撰寫或審查規格本身——請用 /sdd。 Keywords: forward derivation, spec to test, BDD scenario, TDD skeleton, ATDD table, 正向推演, 規格衍生, 測試生成, 合約樁.Votes: 0GitHub stars: 75
- Spec Driven Dev[UDS] 在寫程式碼之前建立並審查規格文件——規格格式、狀態與差異操作。 Use when: 某項變更需要先有書面規格、審查規格的完整性、用 delta 區段修訂既有規格。 Not for: 執行帶關卡的 SDD 生命週期——該部分已移至採用層（XSPEC-095）；快速迭代用的輕量微規格——請用 uds spec 指令。 Keywords: SDD, spec, specification, design document, delta operation, spec review, 規格驅動開發, 規格文件, 變更操作, 規格審查.Votes: 0GitHub stars: 75
- Tdd Assistant[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, 測試驅動開發, 紅綠重構, 單元測試.Votes: 0GitHub stars: 75
- Test Coverage Assistant[UDS] 以八維度框架分析程式碼層級的測試覆蓋率，並建議該優先補上哪些缺口。 Use when: 覆蓋率數字看起來很健康但缺陷照樣流出、要在行覆蓋率之外判斷測試完整性、設定覆蓋率目標。 Not for: 需求層級的 AC 與測試追蹤——請用 /ac-coverage；補寫缺少的測試——請用 /tdd 或 /spec-derive。 Keywords: test coverage, eight dimensions, line coverage, branch coverage, test quality, 測試覆蓋率, 八維度, 測試完整性, 覆蓋缺口.Votes: 0GitHub stars: 75
- Testing Guide測試金字塔，以及 UT/IT/ST/E2E 的測試撰寫標準。 支援 ISTQB 與業界通行金字塔兩種框架。 Use when: 撰寫測試、討論測試覆蓋率、測試策略或測試命名時。 Not for: 驅動紅-綠-重構循環——請用 /tdd；量測實際達成的覆蓋率——請用 /coverage。 Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元測試, 整合測試, 端對端.Votes: 0GitHub stars: 75
- Ac Coverage[UDS] Analyze AC-to-test traceability and generate requirement-level coverage reports. Use when: auditing which acceptance criteria have tests, building a traceability matrix from a SPEC file, finding uncovered AC before release. Not for: code-level line/branch/function coverage — use /coverage; writing the missing tests — use /tdd or /spec-derive. Keywords: AC coverage, traceability, acceptance criteria, SPEC, traceability matrix, 驗收條件, 需求追蹤, 覆蓋率矩陣.Votes: 0GitHub stars: 75
- Adr Assistant[UDS] Create, manage, and track Architecture Decision Records (ADR). Use when: architecture decisions, technology choices, design trade-offs, pattern selection. Not for: decisions that do not change architecture — record them in the spec or commit; ideas not yet formed enough to decide — use /brainstorm. Keywords: ADR, architecture decision, decision record, trade-off.Votes: 0GitHub stars: 75
- Ai Collaboration StandardsPrevent AI hallucination and ensure evidence-based responses when analyzing code or making suggestions. Use when: analyzing code, making recommendations, providing options, or when user asks about confidence/certainty. Not for: authoring the AI instruction files themselves — use /ai-instruction-standards; reviewing a concrete diff — use /code-review. Keywords: certainty, assumption, inference, evidence, source.Votes: 0GitHub stars: 75
- Ai Friendly ArchitectureDesign AI-friendly architecture with explicit patterns, layered documentation, and semantic boundaries. Use when: structuring projects for AI collaboration, optimizing codebase for AI analysis, setting up AI context. Not for: writing the instruction files — use /ai-instruction-standards; language-conventional directory layout — use /project-structure-guide. Keywords: architecture, AI-friendly, context, modules, documentation layers, .ai-context.yaml.Votes: 0GitHub stars: 75
- Ai Instruction StandardsCreate and maintain AI instruction files (CLAUDE.md, AGENTS.md, .cursor/rules/, etc.) with proper structure. Use when: creating AI instruction files, separating universal vs project-specific rules, configuring AI tools. Not for: shaping the codebase so AI can navigate it — use /ai-friendly-architecture; enforcing evidence-based answers — use /ai-collaboration-standards. Keywords: CLAUDE.md, AGENTS.md, cursorrules, windsurfrules, clinerules, AI instructions, system prompt.Votes: 0GitHub stars: 75
- Api Design AssistantGuide API design following REST, GraphQL, and gRPC best practices. Use when: designing APIs, reviewing endpoints, API versioning decisions. Not for: verifying a running API against its consumers — use /contract-test; schema design behind the API — use /database. Keywords: API, REST, GraphQL, gRPC, endpoint, versioning.Votes: 0GitHub stars: 75
- Atdd Assistant[UDS] Reference for Acceptance Test-Driven Development: INVEST criteria, Gherkin AC format, and Three Amigos structure. Use when: defining acceptance criteria with a product owner, running a specification workshop, checking a user story against INVEST. Not for: executing the ATDD lifecycle or enforcing PO sign-off gates — that moved to the adoption layer (XSPEC-095); writing unit tests — use /tdd. Keywords: ATDD, acceptance test, acceptance criteria, INVEST, specification workshop, Three Amig...Votes: 0GitHub stars: 75
- Audit Assistant[UDS] Diagnose UDS installation health and submit structured feedback upstream. Use when: .standards/ looks broken or out of sync, verifying manifest integrity, reporting friction with an existing UDS standard. Not for: auditing your own application code quality — use /metrics or /code-review; dependency and secret scanning — use /scan. Keywords: UDS audit, health check, manifest integrity, standards feedback, friction, 安裝健康, 標準稽核, 回饋.Votes: 0GitHub stars: 75
- Bdd Assistant[UDS] Reference for Behavior-Driven Development: Gherkin Given-When-Then format and Three Amigos structure. Use when: writing or reviewing .feature scenarios, choosing ubiquitous language, running a discovery conversation about behaviour. Not for: executing the BDD lifecycle or RED/GREEN automation — that moved to the adoption layer (XSPEC-095); turning .feature files into E2E skeletons — use /e2e. Keywords: BDD, Gherkin, Given When Then, feature file, scenario, Three Amigos, 行為驅動開發, 場景, 特性檔.Votes: 0GitHub stars: 75
- Brainstorm Assistant[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: planning work whose direction is already decided — use /plan or /sdd; recording a decision already made — use /adr. Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 腦力激盪, 發想, 發散收斂.Votes: 0GitHub stars: 75
- Changelog Guide[UDS] Generate and maintain CHANGELOG.md entries in Keep a Changelog format. Use when: writing changelog entries from commit history, filling the Unreleased section, categorising changes as Added/Changed/Fixed. Not for: choosing the next version number or running the release — use /release; writing the commit messages themselves — use /commit. Keywords: changelog, CHANGELOG.md, Keep a Changelog, release notes, unreleased, 變更日誌, 發布說明, 版本紀錄.Votes: 0GitHub stars: 75
- Checkin Assistant[UDS] Reference for pre-commit quality gates: gate definitions, checklist items, and never-commit rules. Use when: deciding what must pass before a commit, auditing which quality gates a project enforces, checking readiness to check in. Not for: executing the gate sequence or aborting a commit — that moved to the adoption layer (XSPEC-095); finding and removing debug artifacts — use /sweep. Keywords: check-in, pre-commit, quality gate, commit readiness, never commit, 簽入, 提交前檢查, 品質關卡.Votes: 0GitHub stars: 75
- Ci Cd AssistantGuide CI/CD pipeline design, configuration, and optimization. Use when: setting up pipelines, optimizing build times, configuring deployment stages. Not for: deploying without a CI/CD platform — use /deploy; version bumps and promotion — use /release. Keywords: CI/CD, pipeline, GitHub Actions, deployment, build.Votes: 0GitHub stars: 75
- Code Review Assistant[UDS] Reference for systematic code review: eight review categories and BLOCKING/IMPORTANT/SUGGESTION comment prefixes. Use when: reviewing a pull request or diff, deciding how to phrase and prioritise review comments, agreeing review scope with a team. Not for: executing a gated review workflow — that moved to the adoption layer (XSPEC-095); pre-commit gate verification — use /checkin. Keywords: code review, pull request review, review checklist, BLOCKING, comment prefix, 程式碼審查, 審查類別, 評論前綴.Votes: 0GitHub stars: 75
- Commit Standards[UDS] Generate commit messages that follow Conventional Commits, including the bilingual format. Use when: writing a commit message for staged changes, choosing a type and scope, producing a bilingual English and 中文 subject and body. Not for: deciding whether the change is ready to commit — use /checkin; aggregating commits into release notes — use /changelog. Keywords: commit message, Conventional Commits, feat, fix, refactor, scope, bilingual, 提交訊息, 雙語 commit, 提交規範.Votes: 0GitHub stars: 75
- Contract Test Assistant[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 — use /e2e. Keywords: contract test, Pact, OpenAPI, consumer-driven, provider.Votes: 0GitHub stars: 75
- Database AssistantGuide database design, migration, and query optimization. Use when: schema design, migration planning, query optimization, index strategy. Not for: application code migration or framework upgrades — use /migrate; the API contract over the data — use /api-design. Keywords: database, schema, migration, SQL, index, query.Votes: 0GitHub stars: 75
- Deploy AssistantGuide reliable deployments without CI/CD platforms (GitHub Actions / GitLab CI). Use when: deploying to VPS, air-gapped servers, or environments without CI/CD infrastructure. Not for: pipelines on GitHub Actions or GitLab CI — use /ci-cd; version bumps and release promotion — use /release. Keywords: deployment, no-cicd, shell script, blue-green, smoke test, rollback.Votes: 0GitHub stars: 75
- Dev Methodology[UDS] Select and track the active development methodology (SDD, BDD, TDD) for a project. Use when: deciding which methodology a project should follow, switching methodology, checking which phase the current methodology is in. Not for: finding which command to run at a given development stage — use /dev-workflow; executing a methodology itself — use /sdd, /bdd, or /tdd. Keywords: methodology, SDD, BDD, TDD, phase tracking, methodology selection, 方法論, 開發方法選擇, 階段追蹤.Votes: 0GitHub stars: 75
- Dev Workflow Guide[UDS] Map the current software development phase to the right UDS commands and skills. Use when: unsure which UDS command fits the task at hand, onboarding to UDS, walking a feature from planning through release. Not for: choosing or switching a methodology — use /methodology; doing the actual work of a phase — use that phase own skill. Keywords: workflow, development phase, command routing, which command, UDS guide, 開發階段, 指令對照, 流程指南.Votes: 0GitHub stars: 75
- Docs Generator[UDS] Generate usage documentation (cheatsheets, references, guides) from project sources. Use when: producing a cheatsheet or feature reference from CLI and skill definitions, regenerating docs after commands change, checking generated docs are current. Not for: deciding what documentation a project needs or writing prose by hand — use /documentation-guide; changelog entries — use /changelog. Keywords: docgen, usage docs, cheatsheet, feature reference, generated documentation, 使用文件, 速查表, 文件產生.Votes: 0GitHub stars: 75
- Documentation GuideGuide documentation structure, content requirements, and project documentation best practices. Use when: creating README, documentation, docs folder, project setup, technical docs. Not for: generating docs mechanically from source — use /docgen; changelog entries — use /changelog. Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, ARCHITECTURE, API docs.Votes: 0GitHub stars: 75
- Durable Execution Assistant[UDS] Guide fault-tolerant workflow design with checkpoints, retry policies, and rollback plans. Use when: a long-running workflow keeps failing partway, designing checkpoint granularity, choosing a retry or backoff strategy. Not for: responding to a production incident already in progress — use /incident; deployment rollback mechanics — use /deploy. Keywords: durable execution, checkpoint, retry, backoff, idempotency, rollback, 持久執行, 檢查點, 重試策略.Votes: 0GitHub stars: 75
- E2e Assistant[UDS] Generate E2E test skeletons from BDD .feature scenarios, with framework detection and coverage gap analysis. Use when: turning finished .feature scenarios into runnable E2E skeletons, detecting the project E2E framework, finding AC with no E2E coverage. Not for: multi-story journeys with shared state — use the journey-test skill; writing the .feature scenarios themselves — use /bdd. Keywords: E2E, end-to-end test, feature file, test skeleton, framework detection, 端對端測試, 測試骨架, 場景轉測試.Votes: 0GitHub stars: 75
- Error Code GuideDesign consistent error codes following the PREFIX_CATEGORY_NUMBER format. Use when: defining error codes, creating error handling, designing APIs. Not for: log format and levels — use /logging-guide; handling errors that already reached production — use /incident. Keywords: error code, error handling, error format, API errors.Votes: 0GitHub stars: 75
- Git Workflow GuideGuide Git branching strategies, branch naming, and merge operations. Use when: creating branches, merging, pull requests, Git workflow questions. Not for: composing the commit message — use /commit; the safety checks around pushing — use /push. Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow.Votes: 0GitHub stars: 75
- Incident Response AssistantGuide incident response, root cause analysis, and post-mortem documentation. Use when: production incident, outage response, post-mortem writing, RCA. Not for: designing retries and checkpoints before failure — use /durable; setting alert thresholds and Error Budget policy — use /slo. Keywords: incident, outage, post-mortem, RCA, root cause.Votes: 0GitHub stars: 75
- Journey Test Assistant[UDS] Generate coherent user-journey test plans (TESTPLAN) and journey E2E skeletons from a project description. Use when: a new project needs a test journey from day one, testing state carried across multiple stories, building persona-driven journey plans. Not for: isolated per-AC E2E skeletons — use /e2e; measuring achieved code coverage — use /coverage. Keywords: user journey, TESTPLAN, journey test, persona, cross-story state, 使用者旅程, 旅程測試, 測試計畫.Votes: 0GitHub stars: 75
- Knowledge Graph[UDS] Trace impact chains across specs, decisions, and code via a knowledge graph, with a Markdown fallback when no engine is present. Use when: asking what a spec or decision affects, finding which code implements an artifact, tracing dependencies between specs, ADRs, and modules. Not for: plain text search with no spec or decision anchor — use Grep; authoring the spec itself — use /sdd. Keywords: knowledge graph, impact chain, traceability, spec impact, decision graph, 知識圖, 影響鏈, 規格追蹤.Votes: 0GitHub stars: 75
- Logging GuideImplement structured logging with proper log levels and sensitive data handling. Use when: adding logging, debugging, setting up observability. Not for: metrics, traces, and alerting design — use /observability; error code taxonomy — use /error-code-guide. Keywords: logging, log level, structured logging, observability.Votes: 0GitHub stars: 75
- Metrics Dashboard Assistant[UDS] Track development metrics, code quality indicators, and technical debt over time. Use when: assessing ongoing project health, classifying and trending technical debt, reporting code quality to a team. Not for: first-time assessment of an unfamiliar codebase — use /discover; test coverage specifically — use /coverage or /ac-coverage. Keywords: metrics, code quality, technical debt, project health, debt trend, 開發指標, 技術債, 專案健康度.Votes: 0GitHub stars: 75
- Migration Assistant[UDS] Guide systematic code migration, framework upgrades, and technology modernization. Use when: planning a framework or major-version upgrade, assessing migration risk, capturing contract-test fixtures before an API migration. Not for: in-place improvement that keeps the same framework — use /refactor; database schema design — use /database. Keywords: migration, framework upgrade, modernization, breaking change, dependency upgrade, 遷移, 升級, 技術現代化.Votes: 0GitHub stars: 75
- Observability AssistantGuide 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 /logging-guide. Keywords: observability, metrics, traces, golden signals, alerting, SLO.Votes: 0GitHub stars: 75
- OrchestrateOrchestrate 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. Not for: producing the plan in the first place — use /plan; single tasks with no dependencies between them. Keywords: orchestrate, plan, execute, DAG, task plan.Votes: 0GitHub stars: 75
- PlanGenerate plan.json from Spec documents, OpenSpec changes, or free-text requirements. Use when: converting specifications into executable task plans for /orchestrate. Not for: executing the resulting plan — use /orchestrate; deciding whether the idea is worth doing — use /brainstorm. Keywords: plan, spec, task plan, plan.json, DAG.Votes: 0GitHub stars: 75
- Pr Automation AssistantGuide pull request creation, review automation, and merge strategies. Use when: creating PRs, automating reviews, configuring merge policies. Not for: the substance of the review itself — use /code-review; branch naming and merge strategy — use /git-workflow-guide. Keywords: pull request, PR, merge, review, GitHub, GitLab.Votes: 0GitHub stars: 75
- Project Discovery[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 a codebase you already know — use /metrics; recovering specs from code — use /reverse. Keywords: discovery, project assessment, legacy onboarding, risk register, technical debt, 現況評估, 專案盤點, 風險登記簿.Votes: 0GitHub stars: 75
- Project Structure GuideGuide 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 /ai-friendly-architecture; restructuring existing code in place — use /refactor. Keywords: project, structure, directory, layout, gitignore, scaffold, file placement, utils, helpers, shared, where to put.Votes: 0GitHub stars: 75
- PushAI-assisted safety layer for git push operations with quality gates and collaboration guardrails. Use when: pushing commits, force pushing, pushing to protected branches, pushing feature branches. Not for: composing the commit — use /commit; branch and merge strategy decisions — use /git-workflow-guide. Keywords: git push, force push, protected branch, quality gate, push receipt, PR automation.Votes: 0GitHub stars: 75
- Refactoring Assistant[UDS] Guide refactoring decisions and strategy selection, including the refactor-versus-rewrite call. Use when: code has become hard to change, choosing between tactical and architectural refactoring, working safely inside legacy code. Not for: moving to a different framework or major version — use /migrate; clearing debug artifacts and dead code — use /sweep. Keywords: refactor, rewrite, strangler, legacy code, technical debt, code smell, 重構, 重寫, 技術債.Votes: 0GitHub stars: 75
- Release Standards[UDS] Guide the release process — semantic versioning, release modes, and the start/finish/promote/deploy sequence. Use when: cutting a release, deciding a semantic version bump, promoting a release candidate to stable, recording a deployment. Not for: writing the changelog entries themselves — use /changelog; the deployment mechanics — use /deploy. Keywords: release, semantic versioning, version bump, release candidate, promote, 發布, 語意化版本, 發版流程.Votes: 0GitHub stars: 75