Product
Accessibility remediation from your terminal
limena now speaks the Model Context Protocol. Your agent can find the component behind a finding, draft the fix, and open the pull request, without leaving your editor.
A finding names a node. Your repository has components.
An audit finding tells you that a button on the checkout page has no accessible name. It gives you the selector, the page, the rule it failed, and the markup as the browser rendered it. It does not tell you which file to open.
So remediation starts with translation. Someone reads the markup, guesses at the component, searches the repository, and confirms by eye. Twenty-six findings of the same kind mean twenty-six translations, and most of them land on the same file.
That step is the part of remediation nobody budgets for. It is also the part that does not need a person.
How it works
Three tools, chained by your agent.
limena now speaks the Model Context Protocol, so your editor can call it directly. Ask your agent to fix the missing button labels in the latest audit and it calls these in order. Each one is a separate call, so you can read the result and stop after any of them.
- youfix the missing button labels in the latest audit
- limenafind_component_filesrc/components/IconButton.tsx
- limenagenerate_a11y_fixdiff ready, confidence high
- limenaopen_a11y_prpull request opened as a draft
01
find_component_file
Takes the rendered markup from the finding and searches your repository for the component that produced it. A generic icon button resolves to the file that renders it, with the matching lines quoted back so you can see why it matched.
02
generate_a11y_fix
Drafts the change against the component you actually have, following its props and its structure rather than a textbook example. It returns a diff and a confidence rating, not a patched file, because the review is the point.
03
open_a11y_pr
Opens a branch and a pull request carrying that diff, with a body a reviewer can read. Ask for a different approach and it updates the same pull request rather than leaving a stale one open beside the new one.
The argument
One component, twenty-six findings.
The fix targets the component, not each node the component rendered. So one pull request closes every instance the audit found, and the pull request says so in its own body.
The count is not an estimate. It is the number of findings in that audit which this one component produced, which is the reason to review the change carefully once rather than approve the same change twenty-six times.
- Branchlimena/icon-button-label
- File changed+6 / -2IconButton.tsx
- ConfidenceHigh
- Resolves1.1.1, 4.1.226 instances
Opened as a draft because this workspace has draft mode on. A person promotes it, and the body carries the finding it came from.
Guardrails
Writing to a repository is a different kind of permission.
So it is scoped on its own, and the limits are enforced in the engine every route calls rather than in the client that happens to be asking.
A scope of its own
Repository writes need a key minted with the repo:write scope. Read, write, and admin do not carry it, and a key issued before the scope existed does not inherit it. Access to your source is granted deliberately, never retroactively.
Path allowlist
You name the directories a bot may edit. A path outside them is refused before any call reaches GitHub, so a disallowed path costs nothing and reveals nothing. A prefix names a directory: src/components does not also authorise src/components-legacy.
Line ceiling
A cap on how many lines one file’s change may touch. It is checked after the original file is read, because the size of a change is not knowable from the proposal alone.
Draft mode
Pull requests open as drafts, so a person promotes them. A blocked check is not an error either: you get the proposed content back and review it by hand, which is the outcome the setting was chosen to produce.
All four live below the front door, not in the CLI and not in the prompt. An agent cannot talk its way past them, because it is not the thing enforcing them.
Getting started
Three things to connect it.
Mint a key
Settings, then API Keys in the console, with the repo:write scope selected.
Add the connector
Point Claude Code, Cursor, or any MCP client at limena and paste the key in.
Set the limits
Path allowlist, line ceiling, and draft mode are per programme, in that programme’s settings.
What comes next
Your design system as context.
The same connection can carry more than findings. Design tokens, Figma variables, and the words your team has settled on for error messages are all context a fix could be written against.
A generic fix is correct. A fix that uses your spacing scale and your voice is one a reviewer merges without editing it first. That is the next thing we are building.
Give your agent the audit.
Bring one product. We will run it, show you which findings collapse into a single component, and you can open the first pull request from your own terminal.