Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
owl-listener avatar

Handoff

  • 33 installs
  • 87 repo stars
  • Updated June 9, 2026
  • owl-listener/inclusive-design-skills

Helps with ai & agent building tasks during AI-assisted development.

About

handoff is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.

  • handoff
  • AI & Agent Building
  • AI-coding skill

Handoff by the numbers

  • 33 all-time installs (skills.sh)
  • +5 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #8,975 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/owl-listener/inclusive-design-skills --skill handoff

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs33
repo stars87
Last updatedJune 9, 2026
Repositoryowl-listener/inclusive-design-skills

What it does

Helps with ai & agent building tasks during AI-assisted development.

Files

SKILL.mdMarkdownGitHub ↗

Accessibility Decision Handoff

Package accessibility decisions into a clear specification that engineers can implement against — because "make it accessible" is not a specification.

Process

Step 1: Compile Decisions

Using decision-documentation, gather all accessibility decisions for the feature:

  • Interaction patterns and keyboard behaviour
  • Screen reader announcements and ARIA requirements
  • Visual specifications (contrast, colour independence, motion)
  • Content requirements (reading level, alt text, link text)
  • Adaptive behaviour (preferences, zoom, density)

Step 2: Map to Implementation

Using compliance-mapping, translate each design decision into specific implementation requirements:

For each interactive element specify:

  • HTML element or ARIA role
  • Keyboard behaviour (which keys do what)
  • Focus management (where focus goes after actions)
  • Screen reader name, role, and state announcements
  • Visual states (default, hover, focus, active, disabled, error)

For each content element specify:

  • Heading level
  • Alt text (exact text or strategy)
  • Link text
  • Language attributes if multilingual

For each adaptive behaviour specify:

  • Media query and expected response
  • Preference detected and what changes
  • Breakpoints and reflow behaviour

Step 3: Define Test Criteria

Using accessibility-testing-strategy, provide specific test cases for each requirement:

  • Keyboard test: "Tab to the submit button, press Enter,

verify focus moves to the confirmation message"

  • Screen reader test: "Navigate to the error, verify it

announces: 'Error: email address is required'"

  • Visual test: "Verify contrast ratio of body text is at

least 4.5:1 in both light and dark modes"

  • Zoom test: "At 200% zoom, verify the form reflows to

single column with no horizontal scroll"

Step 4: Flag Risks and Dependencies

Note anything engineers need to be aware of:

  • Components that need custom keyboard handling
  • Places where framework defaults aren't accessible
  • Third-party components that may need wrapping or replacing
  • Areas where automated testing won't catch the issue

Output

Deliver a handoff document containing:

1. Accessibility specification — element-by-element requirements with HTML, ARIA, keyboard, and visual specifications 2. Test cases — specific, executable test scenarios for keyboard, screen reader, visual, and zoom testing 3. WCAG mapping — which success criteria each requirement addresses 4. Risk register — known challenges and recommended approaches 5. Definition of done — the specific accessibility criteria that must pass before the feature ships

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.