GIT Going with GitHub

Appendix Episode 55 12-15 min

Advanced Agent Patterns

Using agents for code review, pair programming, CI/CD integration, and team workflows.

Workshop docs

advanced agent patterns

Listen

Download MP3 Subscribe via RSS

Transcript

Alex: Welcome back. Today we're in an advanced companion appendix for the Accessibility Agents material, alongside the agents reference and the installation setup notes. The big idea is moving from one-off agent help to repeatable workflows that a team can use again and again. The appendix also points learners toward learning cards and reference links, so it works well as something you revisit while building.

Jamie: I like that framing, because advanced agent work can sound mysterious fast. But if we're talking about repeatable workflows, that feels more practical.

Alex: Exactly. In agent work, a pattern is a coordinated way to get a result, not a magic command. It might be an agent scanning first and a human reviewing after, or one agent delegating to several specialists, or a hook that runs a check before a pull request is ready to merge.

Jamie: So a pattern is the part you can reuse: who does what, when it runs, what gets checked, and what output you trust.

Alex: Let's start with agents and subagents. An agent is a standalone AI helper with a domain, like an ARIA specialist or a contrast checker. A subagent is another agent called by the first agent, usually through something like a runSubagent function in the parent agent's instructions or prompt file.

Jamie: That's the part I always want to ask about. If one agent can already answer, why bring in several?

Alex: Because deep audits have multiple kinds of questions. A web accessibility wizard might ask an ARIA specialist to check roles, a contrast agent to check colors, a keyboard navigation agent to check focus order, an image and headings agent to check structure, and a table specialist to inspect table markup. Then the parent agent collects the results into one report instead of making the user juggle five separate answers.

Jamie: That sounds powerful, but also like it could get messy. What keeps the agents from bouncing work around forever?

Alex: Good architecture. The parent delegates to specialists, but specialists should not call other specialists. If one subagent fails, the parent logs that failure and continues with the rest. The parent also passes enough context, like the HTML, CSS, document content, or issue description, so each specialist can reason from the same evidence.

Jamie: So subagents are best for deep audits, code review across several domains, document audits with platform-specific checks, and markdown audits where links and heading hierarchy both matter.

Alex: Skills are the next layer. A skill is a reusable multi-step workflow, usually bundled with reference files, templates, and sometimes scripts. Agents can call skills, and users can often invoke them directly with slash commands.

Jamie: So a skill is bigger than a prompt. It might include how to crawl pages, how to score severity, or how to export a report.

Alex: Right. The appendix describes a broad skills catalog, and the Accessibility Agents collection is a living catalog, so don't treat any count as permanent. The examples include web scanning, web severity scoring, remediation, CSV reporting, document scanning and remediation, markdown accessibility, CI/CD scanners, framework-specific patterns for React or Vue, Python development tools, testing support, and WCAG reference material.

Jamie: And using one could be as direct as typing a slash command in chat, like asking for web scanning with a URL, or report generation with findings data.

Alex: Yes. Custom agents can invoke skills too. If you're authoring your own skill, the pattern is usually a SKILL.md file inside a .github/skills folder, with a clear purpose, expected inputs, a workflow, output format, and references. Supporting folders often hold templates, scripts, and reference data, such as compliance mappings or example reports.

Jamie: That reuse matters. If a web wizard, an issue fixer, and a link checker all call the same scanning skill, the behavior stays more consistent and nobody has to copy the same workflow into three different agents.

Alex: Hooks are where agent help becomes automatic. A hook is a JSON configuration that triggers an agent action at a lifecycle event, such as file edit, file save, commit, pull request creation, or a scheduled nightly run.

Jamie: This is where my cautious side wakes up. Automatic checks can be helpful, but they can also interrupt people if they're too aggressive.

Alex: They need to be designed with care. A hook file might live at .github/hooks/accessibility.hooks.json and define items with a name, event, file pattern, agent, condition, action, severity, message, and labels. One hook might highlight ARIA violations while editing JSX, another might run a broader scan on save, another might append findings to a commit message, and a nightly markdown audit might create issues with accessibility labels.

Jamie: So the settings are not just technical. The team is deciding what becomes a warning, what blocks work, and what gets filed for later.

Alex: Exactly. Use blocking actions sparingly, especially while people are drafting. Warnings, scan-and-report actions, and created issues are often better early in a workflow. Also, hook support can vary by platform and tool, so check the current Copilot documentation, custom instruction support details, and custom agent documentation before depending on a hook in a real team process.

Alex: Browser tools let agents examine behavior, not just source code. Depending on the environment, that can include opening a page, taking a page snapshot, inspecting the DOM, moving focus, clicking controls, typing into fields, or running a controlled script to gather page state.

Jamie: That seems especially useful for accessibility, because a lot of problems only show up when someone actually interacts with the page.

Alex: Exactly. An audit can load a page, inspect headings and landmarks, check form labels, test keyboard movement, and gather evidence for a report. A smarter audit can look at the page content first and choose checks that fit the page, like spending more time on tables when the page contains data grids, or on form behavior when the page contains inputs.

Jamie: But this still isn't the same as a person testing with their own assistive technology, right?

Alex: Right. Browser tools can miss timing issues, authentication states, pop-ups, dynamic content, and the lived experience of a screen reader user. Workarounds include narrowing the test scope, giving the agent the exact state to inspect, saving snapshots, retrying flaky steps, and marking anything uncertain for manual verification. Automated behavior scanning is evidence, not a final verdict.

Jamie: This is where orchestration comes in, isn't it? The appendix has several patterns for coordinating the work instead of asking one giant question.

Alex: Yes. One pattern is parallel scanning, where a web accessibility wizard sends different parts of the audit to specialists and aggregates the findings. Another is cascading fixes, where an issue fixer applies one fix, checks the result, then moves to the next related problem. A third is skill-first work, where something like a testing coach starts with a known testing skill before giving advice. A fourth is report aggregation, where a cross-page analyzer gathers results across several pages and looks for repeated problems.

Jamie: That connects directly to code review. I would not want an agent approving my pull request, but I would love it to scan before a human review starts.

Alex: That's the right balance. In code review, the agent can do an initial pass for ARIA mistakes, contrast risk, missing labels, fragile focus behavior, test gaps, and documentation changes. Then the human reviewer decides what matters, checks the context, and asks follow-up questions. The agent can make the review faster, but it should not replace accountability.

Jamie: What about real-time pair programming? I hear people say the agent becomes a pair, but sometimes it feels more like a very talkative third person in the room.

Alex: That's a healthy way to treat it. Let the agent propose options, explain unfamiliar code, draft tests, or compare approaches, but keep the human conversation in charge. For accessibility work, ask it to explain the user impact of a choice, not just whether the code compiles. If it suggests a pattern, ask for the tradeoffs and what evidence would prove it works.

Alex: Advanced team use is where custom skills and shared preferences become valuable. A team can create a skill such as .github/skills/our-pattern-library/SKILL.md that captures its accessibility pattern library. That skill can define its purpose, included patterns, inputs, expected output, and usage examples.

Jamie: So instead of every developer asking the agent in a slightly different way, the team shares the prompt style, report format, severity language, and preferred fixes.

Alex: Exactly. The appendix also describes continuous evaluation hooks, platform-specific skill variants, and result caching. Continuous evaluation hooks can run checks in CI/CD so regressions are caught during the pipeline. Platform-specific variants let a React team and a Vue team share principles while using different code examples. Caching can keep repeated scans faster when the same pages, files, or reference data are inspected again.

Jamie: I want to add one team habit there: keep a log of what the agent suggested and what the team did with it.

Alex: Yes. A lightweight log can record the prompt, the suggestion, whether it was accepted, changed, or rejected, and why. Over time, that tells the team which prompts are useful, which checks are noisy, and where training or custom skills would help. It also gives maintainers a clearer audit trail when accessibility decisions come up later.

Jamie: How do you decide when to rely on an agent suggestion and when to override it?

Alex: Rely on it more when it points to verifiable evidence: a failing test, a WCAG mapping, a specific line of code, a reproducible keyboard path, or a screenshot and DOM snapshot that match what you can inspect. Override it when it conflicts with user needs, project requirements, security rules, maintainer guidance, or your own test results. Also be wary when the agent sounds confident but cannot show where the claim came from.

Jamie: So the agent can help you notice, compare, draft, and organize, but the team still owns the decision.

Alex: Exactly. If you're using this in the course flow, remember that Challenge 15, Discover Accessibility Agents, is browse-first and does not require forking the Accessibility Agents repository. Completing it unlocks Challenge 16, Capstone Project, plus Bonus Challenges A through E as a structured path. The capstone can contribute to Accessibility Agents, GLOW, or another meaningful repository, and review-ready drafts or contribution plans can be valid evidence. For Day 1 GitHub practice, the learner's provisioned Learning Room repository is still where the issue, branch, commit, pull request, and merge workflow happens.

Jamie: That brings it back to the practical goal. Use advanced patterns to make the work clearer, more consistent, and more accessible, but keep humans responsible for the final judgment.

Workshop Content

Full chapter content from the Git Going with GitHub workshop guide.

Companion Podcast and Transcript

Use audio and transcript companions to review concepts in a conversational format.

Advanced Agent Patterns

Companion audio: this episode reinforces key ideas and may not be a word-for-word reading of this page.

Open audio file (external) Full transcript source (external)

Transcript preview

Alex: Welcome back. Today we're in an advanced companion appendix for the Accessibility Agents material, alongside the agents reference and the installation setup notes. The big idea is moving from one-off agent help to repeatable workflows that a team can use again and again. The appendix also points learners toward learning cards and reference links, so it works well as something you revisit while building.

Jamie: I like that framing, because advanced agent work can sound mysterious fast. But if we're talking about repeatable workflows, that feels more practical.

Alex: Exactly. In agent work, a pattern is a coordinated way to get a result, not a magic command. It might be an agent scanning first and a human reviewing after, or one agent delegating to several specialists, or a hook that runs a check before a pull request is ready to merge.

Jamie: So a pattern is the part you can reuse: who does what, when it runs, what gets checked, and what output you trust.

Appendix AB: Advanced Agent Patterns & Skills

Reference companion to: Chapter 19: Accessibility Agents | Appendix L: Agents Reference | Appendix AA: Installation & Setup

Authoritative source: Accessibility Agents Repository - Skills | Skills Documentation

Architecture, Skills, Hooks, and Advanced Patterns for AI Agents

This appendix covers how to build sophisticated agent workflows using subagent delegation, lifecycle hooks, reusable skills, and browser automation tools. These patterns scale beyond single-agent use to orchestrate complex accessibility audits and remediation workflows.

Table of Contents

  1. Architecture: Agents and Subagents
  2. Skills: Reusable Multi-Step Workflows
  3. Hooks: Lifecycle Automation
  4. Browser Tools for Behavioral Scanning
  5. Orchestration: Delegation Patterns
  6. Advanced Techniques

1. Architecture: Agents and Subagents

What Are Subagents?

An agent is a standalone AI system (like @aria-specialist) that understands one domain (ARIA patterns). A subagent is an agent invoked by another agent to delegate work.

Example workflow:

User: @web-accessibility-wizard [audit this page]
  ↓ (orchestrates multiple specialists)
  ├─→ @aria-specialist (check ARIA roles)
  ├─→ @contrast-master (check colors)
  ├─→ @keyboard-navigator (check tab order)
  ├─→ @alt-text-headings (check images and headings)
  └─→ @tables-specialist (check table markup)
  ↓ (aggregates results)
Output: [consolidated audit report]

How to Use Subagents

In your agent's instructions or a custom prompt, invoke subagents with the runSubagent() function:

<!-- In your .agent.md or .prompt.md file -->

## Use Subagents for Deep Audits

When you need to audit multiple aspects of a page, use subagents:

```javascript
// Pseudo-code - how agents invoke subagents
const results = await runSubagent({
  agentName: '@aria-specialist',
  prompt: 'Check this component for ARIA compliance: <component HTML>',
  description: 'ARIA pattern review'
});

const contrastResults = await runSubagent({
  agentName: '@contrast-master',
  prompt: 'Audit these colors: <CSS rules>',
  description: 'Color contrast verification'
});

When to Use Subagents

Scenario Primary Agent Subagents Benefit
Full page audit @web-accessibility-wizard All specialists Parallel scanning, consolidated report
Code review @web-issue-fixer @aria-specialist, @contrast-master Verify fixes across multiple domains
Document audit @document-accessibility-wizard Platform-specific agents Single entry point for Word/PDF/Excel
Markdown audit @markdown-a11y-assistant @link-checker Cross-check link text and heading hierarchy

Subagent Architecture Principles

  1. Delegation over monoliths: One agent calls specialists; specialists don't call other specialists (avoid infinite loops)
  2. Error recovery: If a subagent fails, the parent agent logs it and continues with other subagents
  3. Context preservation: Parent passes full context (HTML, CSS, document) to subagents
  4. Result aggregation: Parent collects results and produces a single consolidated report

2. Skills: Reusable Multi-Step Workflows

What Are Skills?

A skill is a reusable, multi-step workflow bundled with reference files, templates, and automation scripts. Skills are invoked by agents or directly by users via slash commands.

Example: The web-scanning skill contains:

  • Step-by-step crawling logic
  • URL inventory templates
  • Browser automation code
  • Reference documentation

Example: The report-generation skill contains:

  • Severity scoring algorithms
  • Scorecard templates
  • CSV export logic
  • WCAG mapping reference data

The 25+ Core Skills

Accessibility Agents includes a library of reusable skills organized by capability:

Skill Category Skills Purpose
Web Scanning web-scanning, web-severity-scoring Page inventory, audit scope, severity calculation
Web Remediation web-issue-fixer, web-csv-reporter Apply fixes, export findings to CSV
Document Scanning document-scanning, document-accessibility-rules Audit Word/Excel/PDF/EPUB; map to WCAG
Document Remediation document-remediation, document-csv-reporter Fix documents; generate compliance reports
Markdown markdown-accessibility, markdown-fixer, markdown-csv-reporter Audit .md files; fix links, headings, emoji
CI/CD Integration lighthouse-scanner, github-accessibility-scanner Parse CI reports; track regressions
Framework Specifics framework-accessibility, react-patterns, vue-patterns Framework-specific accessibility patterns
Python Dev Tools python-fact-grounded-coding, pylance-refactoring Python code analysis, accessibility linting
Testing testing-coach, accessibility-testing-setup Screen reader testing, test automation, CI/CD setup
Compliance wcag-guide, accessibility-rules-reference, help-url-reference WCAG 2.2 AA reference, remediation links

How to Use a Skill

From Copilot Chat:

/web-scanning [URL]
/report-generation [findings JSON]
/python-fact-grounded-coding my_script.py

From a Custom Agent:

## Invoke Skills

When you need to audit a webpage, use the web-scanning skill:

"Scan the following URL for accessibility issues and generate a severity score."

- URL: https://example.com
- Severity model: WCAG 2.2 AA
- Output: JSON report

Skill Authoring Pattern

If you are writing a custom skill, follow this structure:

File: .github/skills/my-skill-name/SKILL.md

# My Skill Name

## Purpose
What problem does this skill solve?

## Inputs
- URL or file path
- Configuration (optional)

## Workflow
1. Parse input
2. Execute steps
3. Collect results
4. Format output

## Output
- Report format (JSON, Markdown, CSV)
- Example output

## References
- Links to related agents
- Links to external docs

Supporting files:

  • templates/ - Templates for input/output
  • scripts/ - Automation scripts (shell, Python)
  • reference/ - Reference data (lookup tables, compliance mappings)

Skill Reuse Across Agents

Skills are designed to be called by multiple agents. For example:

  • @web-accessibility-wizard uses web-scanning + web-severity-scoring
  • @web-issue-fixer uses web-scanning + web-issue-fixer
  • @link-checker uses web-scanning + a link-validation subset

This prevents code duplication and ensures consistent behavior across agents.

3. Hooks: Lifecycle Automation

What Are Hooks?

A hook is a JSON configuration that triggers agent actions automatically at specific lifecycle events. Hooks enforce accessibility standards without requiring the user to remember to ask for an audit.

Lifecycle events:

  • On file edit (before save)
  • On file save (after save)
  • On commit (before push)
  • On PR creation (before merge)
  • On scheduled interval (nightly, weekly)

Hook Configuration Format

File: .github/hooks/accessibility.hooks.json

{
  "hooks": [
    {
      "name": "proactive-detection",
      "event": "on-file-edit",
      "pattern": "**/*.{html,jsx,tsx,vue}",
      "agent": "@aria-specialist",
      "condition": "file.includes('aria')",
      "action": "highlight-violations",
      "severity": "warning"
    },
    {
      "name": "edit-gate",
      "event": "on-file-save",
      "pattern": "src/**/*.tsx",
      "agent": "@web-accessibility-wizard",
      "condition": "severity >= 'error'",
      "action": "block-save",
      "message": "Accessibility violations detected. Use @web-issue-fixer to resolve."
    },
    {
      "name": "commit-check",
      "event": "on-commit",
      "pattern": "**/*",
      "agent": "@accessibility-lead",
      "condition": "true",
      "action": "scan-and-report",
      "output": "commit-message-append"
    },
    {
      "name": "nightly-audit",
      "event": "on-schedule",
      "schedule": "0 2 * * *",
      "pattern": "docs/**/*.md",
      "agent": "@markdown-a11y-assistant",
      "action": "create-issue",
      "labels": ["accessibility", "auto-audit"]
    }
  ]
}

Hook Properties

Property Type Description
name string Unique hook identifier
event enum on-file-edit, on-file-save, on-commit, on-pr-create, on-schedule
pattern glob File path pattern (e.g., **/*.tsx)
agent string Agent name (e.g., @aria-specialist)
condition string When to trigger (e.g., file.size > 5000)
action enum highlight, block-save, scan-and-report, create-issue
severity enum info, warning, error
message string Custom message to show user
labels array Labels for auto-created issues

Hook Examples

Example 1: Proactive ARIA Detection

{
  "name": "aria-proactive-check",
  "event": "on-file-edit",
  "pattern": "src/**/*.jsx",
  "agent": "@aria-specialist",
  "condition": "true",
  "action": "highlight-violations",
  "severity": "warning"
}

Behavior: As you type in a .jsx file, violations are highlighted in real time.

Example 2: Block Non-Accessible Commits

{
  "name": "accessibility-commit-gate",
  "event": "on-commit",
  "pattern": "**/*",
  "agent": "@web-accessibility-wizard",
  "condition": "severity >= 'error'",
  "action": "block-save",
  "message": "Critical accessibility issues detected. Run @web-issue-fixer to resolve."
}

Behavior: Commits are blocked if critical accessibility violations are found.

Example 3: Nightly Document Audits

{
  "name": "nightly-markdown-audit",
  "event": "on-schedule",
  "schedule": "0 2 * * *",
  "pattern": "docs/**/*.md",
  "agent": "@markdown-a11y-assistant",
  "action": "create-issue",
  "labels": ["a11y", "auto-audit", "documentation"]
}

Behavior: Every night at 2 AM, markdown files are audited and issues are created automatically.

Enabling Hooks by Platform

GitHub Copilot (VS Code):

  • Place accessibility.hooks.json in .github/hooks/
  • Hooks are read on workspace open
  • View hook status: Settings Gear → Accessibility Hooks

Claude Code:

  • Configure in .claude-code.toml:

    [hooks]
enabled = true
config_file = ".github/hooks/accessibility.hooks.json"

Claude Desktop (MCP):

  • Configure in .mcp.json:

    {
  "accessibility-agents": {
    "hooks": {
      "enabled": true,
      "config": ".github/hooks/accessibility.hooks.json"
    }
  }
}

4. Browser Tools for Behavioral Scanning

Available Browser Tools

Accessibility Agents includes browser automation tools for interactive scanning:

Tool What It Does When to Use
scan-page Single page audit (static + dynamic) Quick single-page check
scan-pages Crawl URL and audit all pages Site audit, scope definition
scan-dom Live DOM inspection Debug dynamic content
scan-with-lighthouse Lighthouse accessibility audit Performance + a11y scoring
scan-with-playwright Playwright automated testing Interactive flows, form testing
get-page-outline Extract page structure Understand heading hierarchy
detect-color-contrast CSS color analysis Find contrast violations
find-aria-roles ARIA role inventory Understand ARIA implementation

Using Browser Tools in Agents

Pattern 1: Direct Tool Invocation

## Audit Page Accessibility

When the user provides a URL, use the scan-page tool:

1. Call `scan-page(url)` to get accessibility findings
2. Filter findings by severity
3. Group by category (ARIA, contrast, keyboard, etc.)
4. Present results in a prioritized table

Example:
**User:** Audit https://example.com for accessibility issues
**Agent:**
- Calls `scan-page("https://example.com")`
- Receives findings JSON
- Groups by category and severity
- Reports top 10 issues

Pattern 2: Conditional Scanning

## Smart Audit Based on Page Content

1. Call `get-page-outline(url)` to understand structure
2. If heading hierarchy is broken:
   - Recommend structure fixes (use @alt-text-headings)
3. If many interactive components detected:
   - Recommend ARIA review (use @aria-specialist)
4. If dynamic content detected:
   - Recommend behavioral testing (use @testing-coach)

Pattern 3: Playwright for Complex Workflows

// Pseudo-code: Test a multi-step form
const browser = await playwright.launch();
const page = await browser.newPage();

await page.goto('https://example.com/form');
await page.fill('#name', 'Jane Doe');
await page.fill('#email', 'jane@example.com');
await page.click('button:has-text("Submit")');

// Check for error messages (accessibility of feedback)
const errorMessage = await page.locator('[role="alert"]');
const text = await errorMessage.innerText();

console.log(`Error announced: ${text}`);

await browser.close();

Browser Tool Limitations and Workarounds

Limitation Workaround
Cannot test with actual screen readers Use @testing-coach guidance instead; CLI offers NVDA integration
JavaScript-heavy pages may be incomplete Increase wait time: waitForNavigation()
Some dynamic content misses ARIA updates Use Playwright to trigger updates and re-scan
Cannot test keyboard without manual intervention Use @keyboard-navigator for structural analysis

5. Orchestration: Delegation Patterns

Pattern 1: Parallel Scanning (Web Accessibility Wizard)

Goal: Audit multiple aspects of a page simultaneously for speed.

User request: Audit this page
  │
  ├─ @aria-specialist (scan ARIA)
  ├─ @contrast-master (scan colors)
  ├─ @keyboard-navigator (scan keyboard flow)
  ├─ @alt-text-headings (scan images/headings)
  └─ @tables-specialist (scan tables)
  │
  ↓ (all run in parallel, results aggregated)
  │
  Consolidated Report:
  - Severity: 12 errors, 8 warnings
  - Priority issues (blocking top 5)
  - Detailed findings per agent

Agent code pattern:

## Parallel Audit

Invoke all specialist agents in parallel:

1. Gather all findings simultaneously (not sequentially)
2. Deduplicate issues across agents
3. Sort by severity
4. Present top 10 blocking issues first
5. Link to detailed fix guidance per agent

Pattern 2: Cascading Fixes (Web Issue Fixer)

Goal: Fix issues in order of severity and dependency.

Findings identified:
  1. Missing alt text (3 images)
  2. Poor color contrast (5 elements)
  3. Missing form labels (2 inputs)
  4. ARIA misuse (1 element)

Remediation order:
  1. Fix ARIA misuse first (foundational)
  2. Add form labels (unblocks testing)
  3. Add alt text (content layer)
  4. Fix contrast (visual layer)

Output: Numbered PR suggestions, 1 fix per commit message

Pattern 3: Skill-First Workflows (Testing Coach)

Goal: Guide users through testing workflows without assuming prior knowledge.

User: How do I test keyboard navigation?

Agent (@testing-coach) response:

1. Ask clarifying questions:
   - Have you used NVDA before?
   - What platform (Windows/Mac/Linux)?
   - What component type (form/menu/modal)?

2. Recommend testing path:
   - Step 1: Learn Tab order basics (video link)
   - Step 2: Test with keyboard-only (no mouse)
   - Step 3: Verify focus indicators visible
   - Step 4: Check against WCAG 2.5.4

3. Provide interactive test:
   - Code snippet to inject focus indicators
   - Keyboard test checklist
   - Screenshot comparison guide

Pattern 4: Report Aggregation (Cross-Page Analyzer)

Goal: Consolidate findings across multiple pages into systemic issues.

Input: 50 pages audited

Output:
- Systemic issues (found on 10+ pages):
  - Color contrast: 45 instances across 18 pages
  - Missing alt text: 120 instances across 32 pages

- Page-specific issues (found on 1-2 pages):
  - Modal focus trap broken (page 15)
  - ARIA combobox pattern error (page 3)

- Severity scorecard:
  - Overall score: 62/100 (D grade)
  - Top 3 fixes: address these to reach 75/100
  - Estimated effort: 8-12 hours

6. Advanced Techniques

Technique 1: Custom Skills for Your Organization

If your organization has repeated accessibility patterns, bundle them as a custom skill:

# .github/skills/our-pattern-library/SKILL.md

## Our Accessibility Pattern Library

### Purpose
Codify internal accessibility standards and patterns used across all projects.

### Patterns Included
1. Form validation messaging
2. Accessible modal templates
3. Color palette compliance
4. Data table best practices

### Inputs
- HTML snippet or component name
- Pattern ID (e.g., "form-validation-v2")

### Output
- Remediation code
- Compliance checklist
- Testing steps

### Usage
@custom-agent check-pattern "form-validation-v2" [HTML]

Technique 2: Continuous Evaluation Hooks

Set up automated evaluation to measure improvement over time:

{
  "name": "continuous-accessibility-eval",
  "event": "on-schedule",
  "schedule": "0 0 * * 0",
  "pattern": "src/**/*",
  "agent": "@accessibility-lead",
  "action": "create-eval-report",
  "track": {
    "metrics": ["page-score", "error-count", "warning-count"],
    "baseline": "2026-01-01",
    "frequency": "weekly"
  }
}

Technique 3: Platform-Specific Skill Variants

Create platform-specific implementations of the same skill:

.github/skills/form-accessibility/
  ├── SKILL.md (base description)
  ├── implementations/
  │   ├── react/form-pattern.tsx
  │   ├── vue/form-pattern.vue
  │   ├── svelte/form-pattern.svelte
  │   └── vanilla/form-pattern.js

Agents select the implementation matching the detected framework.

Technique 4: Result Caching for Performance

For repeated audits (e.g., nightly checks), cache results to speed up analysis:

{
  "name": "smart-audit-with-cache",
  "event": "on-schedule",
  "schedule": "0 2 * * *",
  "pattern": "docs/**/*.md",
  "cache": {
    "enabled": true,
    "ttl": 86400,
    "key": "filepath + git-commit-hash"
  },
  "action": "compare-to-previous"
}

Behavior: Only re-audited files that changed since the last run; unchanged files use cached results.

Learning Cards: Advanced Patterns

Screen reader users
  • Subagent delegation is explained through example workflows; use the tables to understand which agents delegate to which subagents
  • Hooks are configured in JSON files; the JSON structure is explained line-by-line, so you can edit .github/hooks/accessibility.hooks.json with confidence
  • Skills are organized by category in a table; navigate to the category that matches your need (Web Scanning, Document, etc.)
  • Browser tools are listed with clear descriptions; copy the tool name and use it with your chosen agent
Low vision users
  • Workflow diagrams are presented both visually and in text form (with indentation showing hierarchy); read the text version if visual ASCII doesn't render clearly
  • Code examples are formatted in clearly marked code blocks with syntax highlighting
  • Tables can be magnified independently; zoom in on the "Purpose" or "When to Use" columns for quick reference
  • The JSON hook format includes comments explaining each property; copy the template and modify values for your use case
Sighted users
  • Use the Table of Contents to jump to the pattern you need (Subagents, Skills, Hooks, etc.)
  • Skim the workflow diagrams to understand orchestration; dive into code examples for implementation details
  • The hook examples section shows 3 practical configurations you can copy and adapt
  • Read the "When to Use" column in tables to find the right pattern for your task

References

Authoritative Sources

Use these official references when you need the current source of truth for facts in this chapter.

Section-Level Source Map

Use this map to verify facts for each major section in this file.