Binclusive-Accessibility-Skills: Instructions file for GitHub Copilot

Binclusive Accessibility Workflow

Use the canonical Agent Skills in this repository as the source of truth:

• skills/onboard-binclusive-cli/SKILL.md configures the CLI and records non-secret onboarding status after either recommended dashboard CI delivery or a local-only scan.
• skills/map-project/SKILL.md inventories React/Next.js, Angular, React Native/Expo, ASP.NET/ASPX, iOS SwiftUI/UIKit, native Android (Jetpack Compose / Android Views/XML), or Flutter (Dart, Material/Cupertino) routes, screens, views, pages, controls, dependencies, localization, and inline UI for accessibility review.
• skills/audit-accessibility/SKILL.md audits only the mapped scope and writes actionable accessibility TODOs.
• skills/audit-runtime-accessibility/SKILL.md audits live pages and user flows through a connected browser, with step-level runtime evidence.
• skills/accessibility-test-journey-creator/SKILL.md derives requested web/mobile test flows from source into native Binclusive accessibility journey definitions and a local evidence/readiness review. Publishing and execution require a user request.
• skills/accessibility-runtime-journey-creator/SKILL.md creates runtime-verified, action-only journeys for Google Chrome, Android and iOS; guides device setup, saves binclusive-accessibility-test-journies.md and connects Binclusive MCP for user-selected organization/project delivery.
• skills/shopify-theme-audit/SKILL.md audits Shopify theme Liquid, JSON templates, sections, snippets, assets, config, and locales without requiring a prior map.
• skills/aftertestvalidation/SKILL.md validates fixed issues from Excel/PDF/text/tickets through launch-to-target aftertest journeys and selected Binclusive accessibility runs; records evidence and blockers in aftertest.md.
• skills/fix-accessibility/SKILL.md fixes selected TODO tasks with severity/risk controls and verification notes.

Follow the workflow in order:

1. Run map, audit, Shopify audit, fix, and journey skills directly. CLI onboarding, login, dashboard access, credentials, binclusive.json, and cli-onboarding.json are optional and must never gate local work. Offer onboard-binclusive-cli only for requested setup or connected delivery; an unavailable integration does not block local skill use.
   • Only when the user requests dashboard CI delivery, it requires BINCLUSIVE_API_KEY and BINCLUSIVE_PROJECT_ID in the same shell that runs binclusive ci. Have the user set them in their own terminal from the dashboard CI Access page; never accept a key pasted into chat and never write one to a repository file.
   • Being logged in does not authorize ci: the human lane (scan, whoami, audit) reads the session file and never the environment, while ci reads only BINCLUSIVE_API_KEY. With that variable unset, binclusive ci uploads nothing and reports no error, so a clean run proves nothing. Require one of the two stderr confirmations — binclusive ci — uploaded <N> finding(s) to the dashboard. or binclusive ci — clean scan reported to the dashboard (0 findings). — before treating dashboard onboarding as complete. A zero-finding run does upload and does complete onboarding.
2. Map app projects: create or reuse Binclusive-auditing/*_project-map.md. For Shopify themes, use shopify-theme-audit directly.
3. Audit: create Binclusive-auditing/accessibility-todo.md from the selected map or Shopify theme source.
4. After TODO creation, offer the optional recommended Binclusive MCP dashboard sync; authenticate if needed, ask for organization/project, follow audit-accessibility/references/dashboard-ticket-sync.md, and map each finding into the live create_ticket fields with plain-text evidence, description, and recommendation. Never upload the Markdown report or paste raw finding sections; keep exact code and report-only metadata locally.
5. Fix: remediate only user-selected task IDs, SAFE tasks, severities, components, pages, screens, controls, or paths.

Shard Mode (large-scope map and audit fan-out) is portable: when the scope is large and this Copilot runtime can dispatch parallel sub-tasks/agents, fan out one worker per shard — per skills/map-project/SKILL.md for mapping and skills/audit-accessibility/SKILL.md for auditing ("Harness capability" / "Fan-out procedure" in each) — then merge deterministically. When no parallel-subtask primitive is available, run single-agent — the coverage ledger keeps either path honest, so the fallback costs throughput, not coverage.