List issues

Ask your agent to read the accessibility issues for a connected repo.

"List the open accessibility issues on acme/dashboard." "Which WCAG criteria are failing in the dashboard repo?"

Each issue leads with its tag — a short, stable, human-readable reference like GLA-12 (a per-project prefix plus a number, like a Linear or Jira ticket) that you and the agent use to talk about the same issue in a commit message, a PR description, or a follow-up question. The same issue keeps its tag from one scan to the next.

Alongside the tag, each issue carries everything the agent needs to fix it: the file and the failing WCAG criterion, a severity, a snippet of the offending markup, a GitHub deep-link to the exact line (pinned to the scanned commit, so it stays valid after later pushes), and a fix hint with a link to guidance. Issues come most severe first.

"Fix GLA-12 and reference it in the commit."

Filtering

• By default you get the open and reopened issues — the ones that still need work.
• Filter by status (open, reopened, fixed, ignored) or ask for them all:

  "Show the issues you've already marked fixed on acme/dashboard."

• Filter by a failing WCAG criterion — the natural drill-down from the conformance summary:

  "List the issues for criterion 1.1.1 on acme/dashboard."

• Filter by severity (critical, serious, moderate, minor), or look one issue up by its tag:

  "Show only the critical issues on acme/dashboard." "What's the status of GLA-12?"

• Large repos are capped per request (50 issues by default, up to 200). When the list is truncated, the agent is told the true total so it can ask for more or narrow the filter.