메뉴
Accessibility-first design workflow for specifying semantics, keyboard/focus behavior, readability, and assistive-technology expectations. Use when UI accessibility behavior must be defined before implementation or design sign-off; do not use for backend data modeling or deployment pipeline decisions.
Systematic debugging workflow for isolating software root causes, implementing proportional fixes, and verifying recovery with reproducible evidence. Use when application/runtime failures, regressions, or flaky behavior are observed and the task requires both diagnosis and remediation. When specialized skills are available in the environment, defer GitHub Actions failure triage to `github-fix-ci`, commit-introduction isolation to `git-bisect-debugging`, profiler-led hotspot analysis to `performance-profiling`, active security incident command to `security-incident-response`, and postmortem-only reporting to `incident-postmortem`. Do not use for broad feature implementation or speculative hardening without evidence.
Resource-oriented REST/OpenAPI contract design for URI/method semantics, idempotency, pagination, and HTTP status behavior. Trigger when REST contract diffs are detected in paths, methods, schemas, or status semantics, or when request-response transport choice is still unresolved before implementation. Do not use for GraphQL schema authoring, error-taxonomy-only changes, version lifecycle governance, or consumer-provider contract test implementation.
Controlled online experiment workflow for product changes with causal inference, randomization integrity checks, and pre-registered decision criteria. Trigger when ship/no-ship decisions require causal evidence under uncertainty and KPI trade-offs must be quantified. Do not use for feature-flag rollout policy without experiment design, deterministic functional verification, or observability-only analysis.
Provider-consumer compatibility testing for service interface changes. Use when APIs or event schemas evolve and executable contract checks must guard compatibility before release; do not use for UI-only validation or architecture topology decisions.
End-to-end test planning for critical user journeys across integrated systems. Use when release confidence depends on browser/API/dependency behavior as one flow; do not use for isolated unit behavior or pure contract checks.
Risk-based regression suite curation for release gating under time and budget limits. Use when teams must decide what runs always versus conditionally by impact and risk; do not use for implementing a single test type in isolation.
| name | accessibility-design |
| description | Accessibility-first design workflow for specifying semantics, keyboard/focus behavior, readability, and assistive-technology expectations. Use when UI accessibility behavior must be defined before implementation or design sign-off; do not use for backend data modeling or deployment pipeline decisions. |
Use this skill to define concrete accessibility behavior that implementation teams can build and verify without ambiguity.
assets/accessibility-spec-template.mdassets/accessibility-review-checklist.md