
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 handoffAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 33 |
|---|---|
| repo stars | ★ 87 |
| Last updated | June 9, 2026 |
| Repository | owl-listener/inclusive-design-skills ↗ |
What it does
Helps with ai & agent building tasks during AI-assisted development.
Files
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