Claude Skills by zivtech

Use when you have an existing component, flow, or interface and need an evidence-backed accessibility design review after basic checks pass. Best for WCAG 2.2 compliance, focus management, ARIA pattern quality, semantics, and state communication gaps automated tools miss.

Use when you know what component, flow, or interface you need but not yet the right accessibility approach. Best for turning WCAG 2.2 requirements into an accessible implementation plan with WAI-ARIA APG patterns before code hardens bad interaction and state patterns.

ARRM-based accessibility role audit — responsibility-based review lenses

Use when you need to run real accessibility tests — Playwright keyboard interactions, axe-core scanning, visual regression, and WCAG 2.2 compliance checks. The measurement layer that feeds evidence into a11y-critic reviews.

Load this skill whenever you are converting a finished audit-scope accessibility evaluation into an Accessibility Conformance Report (ACR) draft in the OpenACR format, validating or rendering OpenACR YAML, or preparing the handoff to GSA's ACR Editor (https://acreditor.section508.gov/). Report-level companion to bug-reporting: findings→issues is bug-reporting; evaluation-report→ACR is this skill. Output is always a DRAFT for human review and sign-off — never a final or signed ACR. Under no ci...

Load this skill whenever you are filing, reviewing, or generating accessibility bug reports — whether from automated tool output, manual testing, or AI agent scans. The purpose of this skill is to make accessibility errors easier to report accurately, so that developers can reproduce, understand, and fix them without additional back-and-forth. Absolutely always include the required fields (URL, XPath, HTML snippet, WCAG SC, rule ID, severity, frequency) in every report. Under no circumstances...

Safely maintain the public accessibility-skills repository. Use when adding tracked-file hygiene scanners, proving whether reset or rebase work was lost, splitting mixed changes into focused commits, or recovering review-worthy commits made on the local default branch.

Deep accessibility review from 7 access perspectives — activated by escalation from a11y-planner or a11y-critic when one or more perspectives are flagged at MEDIUM or HIGH alarm level.

Use when you have an existing component, flow, or interface and need an evidence-backed accessibility design review after basic checks pass. Best for WCAG 2.2 compliance, focus management, ARIA pattern quality, semantics, and state communication gaps automated tools miss.

Use when you know what component, flow, or interface you need but not yet the right accessibility approach. Best for turning WCAG 2.2 requirements into an accessible implementation plan with WAI-ARIA APG patterns before code hardens bad interaction and state patterns.

ARRM-based accessibility role audit — runs responsibility-based review lenses (visual design, UX design, front-end dev, content authoring, business analysis, testing) to produce role-attributed findings. Complements the access-method perspectives in perspective-audit.

Use when you need to run real accessibility tests — Playwright keyboard interactions, axe-core scanning, visual regression, and WCAG 2.2 compliance checks. The measurement layer that feeds evidence into a11y-critic reviews.

Orchestrate the a11y accessibility lifecycle: scout → plan → critique → [perspective audit] → test → critique. Dual-mode: full lifecycle automation or step-by-step dispatch. Spawns specialist agents at depth-1 from the main session.

Load this skill whenever you are converting a finished audit-scope accessibility evaluation into an Accessibility Conformance Report (ACR) draft in the OpenACR format, validating or rendering OpenACR YAML, or preparing the handoff to GSA's ACR Editor (https://acreditor.section508.gov/). Report-level companion to bug-reporting: findings→issues is bug-reporting; evaluation-report→ACR is this skill. Output is always a DRAFT for human review and sign-off — never a final or signed ACR. Under no ci...

Load this skill whenever you are filing, reviewing, or generating accessibility bug reports — whether from automated tool output, manual testing, or AI agent scans. The purpose of this skill is to make accessibility errors easier to report accurately, so that developers can reproduce, understand, and fix them without additional back-and-forth. Absolutely always include the required fields (URL, XPath, HTML snippet, WCAG SC, rule ID, severity, frequency) in every report. Under no circumstances...

Evaluate a Drupal accessibility patch end-to-end: baseline evidence, patch hygiene, after-patch verification, manual/AT checks, critic gate, and upstream handoff. Evidence-gated — never VERIFIED without before/after proof under the same conditions.

Safely maintain the public accessibility-skills repository. Use when adding tracked-file hygiene scanners, proving whether reset or rebase work was lost, splitting mixed changes into focused commits, or recovering review-worthy commits made on the local default branch.

Deep accessibility review from 7 access perspectives — activated by escalation from a11y-planner or a11y-critic when one or more perspectives are flagged at MEDIUM or HIGH alarm level.

How to verify changes in this prompt-only repo: reproduce committed evidence-harness recipes from scratch, don't re-run CI. Covers the evals/results/* harness pattern.

> **Executor instructions**: Follow this plan step by step. Run every > verification command and confirm the expected result before moving to the > next step. If anything in the "STOP conditions" section occurs, stop and > report — do not improvise. This plan AUTHORS A PROMPT ARTIFACT (a SKILL.md) > from existing protocol documents — it does not run Drupal, DDEV, or any > patch evaluation. When done, update the status row for this plan in > `plans/README.md`. > > **Drift check (run first)**: ...