Teach the agent. Then check its work.
Each pack is written for machines to read. Eval harnesses are used to check everything is working correctly. Every release is attorney-reviewed, signed, and dated.
Not a prompt pack. Four parts:
What your agents read
A folder built on the open SKILL.md standard — checklists, code snippets, linter configs, decision trees. Loads wherever your agents run, so switching stacks doesn't mean rewriting the pack.
How you know it worked
A test suite that measures how often agents pass compliance checks with the pack and without — scored against answers written by hand. It's the same harness behind our published numbers.
What you can point to later
Semver releases, changelogs, signed artifacts, version pinning. wcag@2.2.1 means exactly one reviewed state — so when someone asks what you had in place last March, there's an answer with a date on it.
How you hear about changes
Regulatory-change monitors → diff → attorney review → new release → your notification. Rules move, so every change arrives as a release, not a scramble.
Don't believe the pack. Run it.
Most compliance claims are assertions. Ours is a measurement — and the harness is free, so you can point it at your own pages before you pay us anything.
Mechanical checks run on axe-core: same answer every run. The judgment calls are scored by a model against answers written by hand. Every number we publish is yours to reproduce, anytime.
See the benchmark- pages
- 14 (as shipped)
- graders
- axe-core + model judge
- baseline
- 41% pass
- with pack
- 99% pass
- +58 pts
- artifact
- signed · dated · diffed
Drop it in your repo. Or call it over the wire.
Static files
Drop the pack into your repo for your agents to read on every build. Frictionless: no auth, no network call, no integration work. The fastest path from decision to compliant output.
Served over MCP
Always the current release, with every call logged. When someone asks which version was live in March, the answer is in the log instead of your git history.
Static is the faster start. The API is what you want if you think someone will someday ask for records. Both are supported, and moving between them is just a config change.
A gate in your pipeline, not a report you file.
Just two lines in CI. After that, an agent can't merge pages with failing criterion. Nobody has to remember to check on it, and nobody has to be the person who blocks the PR.
# .ci — gate agent output on the verified pack
bellbriar add wcag@2.2.1
bellbriar eval ./dist --min-pass 95
report written · signed · diffed against last releaseIllustrative. Exact invocation varies by CI provider.
From first audit to every build.
-
01
Free sample audit
We score up to ten of your recent shipped pages and send back the findings: every criterion that fails, named the way a demand letter names them, with the same pages re-scored under the pack.
-
02
Baseline
On signup we score your full portfolio to establish the starting number. From there your agents load the pinned pack on every build, so compliant patterns become the default output.
-
03
Evidence, automatically
Every gated build leaves a signed, dated record of what passed and what version was pinned. When someone asks what you had in place six months ago, you're not reconstructing it from git history.
-
04
Update
Whenever the rules change, you get a reviewed release and your portfolio re-scored against it. A dependency bump, not a fire drill.
Find out what your pages are carrying.
Send up to ten links. We run the same harness and send back every criterion that fails, within one business day.