Your agent can't see
the app. Testers can.
TestGator's whole model — a plain checklist, PASS / PASS (with bug) / FAILED, a comment, and auto-captured context — was built for non-technical humans. Turns out that same structure is exactly what an AI agent needs too: something it can hand out, and something it can read back, without anyone translating in between.
- No jargon for testers
- Plain JSON for agents
- One shared source of truth
Why it fits
Nobody redesigned TestGator for AI.
It just turns out that "clear question in, structured answer out" is a good interface for a human tester and a good interface for an agent, at the same time.
The blind spot every agent has
An agent can write the code, but it can't see the running app the way a real person can. TestGator is the eyes it's missing — a way to ask real humans to look, and get a structured answer back.
Structured before agents even existed
PASS / PASS (with bug) / FAILED, a comment, and auto-captured browser/OS/device — that's not a format bolted on for AI. It's just what good bug reports look like, which happens to be exactly what a machine can parse too.
One CLI call away
testgator-cli turns that structure into plain JSON in, plain JSON out. No scraping a dashboard, no guessing at a raw API — just commands with a clear shape.
The loop
Plan it, ship it, read it back.
Four steps, and the agent only shows up at the start and the end — the middle belongs to real testers.
Agent plans it
Creates a release, a test plan, and plain-language questions.
Agent invites
Enrolls real testers by email — no account setup on their end.
Humans answer
PASS, PASS (with bug), or FAILED — plus a comment and auto-captured context.
Agent reads back
Summarizes it for you, or goes and fixes what broke.
In practice
What your agent can actually do.
This is exactly what's written down in the agent skill — a portable playbook any agent can pick up, not something specific to one assistant.
Decide what needs a human
New feature, edited code, anything downstream of it, or a bug that's come back before — all fair game for a test plan.
Write questions anyone can answer
No jargon, one check per question, phrased as "do this → you should see that."
Set up and invite, hands-off
Create the plan, add the questions, publish it, and invite testers by email — all from the command line.
Turn answers into a summary
Pull the results back and tell the user, in plain language, what passed, what didn't, and why.
Or turn them into a fix
Read a tester's comment and system info, trace it to the actual code, fix it — then close the loop with a retest.
Keep watch over time
Recurring checks on the flows that can't afford to quietly break again.
The two pieces
A skill to know how. A CLI to actually do it.
app-testing-manager (skill)
What to test, when to test it, and how to phrase a question a non-technical tester can actually answer — plus what to do once the results come back.
Read SKILL.md ⌨️testgator-cli (tool)
The hands: log in once, then create releases, plans, and questions, invite testers, and read answers back — all in plain JSON.
See the CLI pageLet your agent close its own loop.
Write the code, hand the testing to real people, read the results back — without leaving the terminal.