How the verifier loop works
Your coding agent writes the code and runs the tests. Test Maze keeps the test plan, records every result against the exact commit and returns a pass/fail verdict computed by fixed rules, not by the agent that wrote the code.
Best for: Vibe coders & founders
You ask in plain English.No test framework to learn.
AI coding agents are great writers.
They're terrible judges.
When the same agent that writes the code also decides whether it works, every CI green-light is a self-graded exam. You ship faster — and you ship more bugs.
Self-grading drift
Agent edits the assertion until the test passes. The diff looks clean. The bug ships.
No shared quality bar
Every agent invents its own KPI. Selector-failure share, snippet quality, reliability — none of it is enforced.
Hidden flakiness
Retries hide real regressions. "Transient" failures pile up until the suite is unrunnable.
One protocol. Six states. One source of truth.
Optionally track each piece of work as a PdlcSession — a state machine the MCP server advances as plans, tests and verdicts land, so your agent always knows the next step. The agent drives; the server keeps score.
Your agent surveys the repo with the product-init prompt and writes back the vision, problem and target users. A session opens, scoped to the workspace your token belongs to.
Your agent checks feature.list for an existing feature, then the feature-spec prompt expands the idea into user stories and acceptance criteria across 8 testing facets — rendered locally by your IDE’s LLM.
The ac-to-testcase prompt turns every acceptance criterion under the feature and its user stories into a complete test case. Prompts run client-side via prompts/get; only the resulting test cases are saved.
Your coding agent writes the code that satisfies each acceptance criterion. The tests are already on record, so the target cannot quietly move.
Your agent runs the tests and records pass/fail per case with testrun.create or testrun.record_results, plus optional screenshots. pdlc.verify grades the run — failure buckets, reliability KPI, deterministic nextStep.
A passing verdict pinned to a clean commit moves the session to SHIP. Mark the release shipped and freeze the run as a regression baseline so it stays green.
From feature spec to shipped — the same loop, every time.
Whether you're starting a fresh project in Claude Code or pushing a new feature into an existing repo with Codex, the workflow is the same: hand over the description, get back a tested, graded build.
Drop the feature description in
A PRD, a Linear ticket, a back-of-napkin one-pager — whatever you fed your agent. Fresh project? Use the high-level spec. New branch? Hand us just the delta.
It becomes a feature with user stories
Each feature is saved as a suite in your workspace, with its user stories under it — the contract your agent is building toward. Existing repo? Your agent lists what is already there first, so nothing is created twice.
Extensive test cases — every facet covered
Test cases are generated for every facet of how the feature can be used, abused and broken — by your agent through Test Maze prompts, or in the web app from an uploaded PRD. coverage.gap_for_feature then shows which facets are still missing.
Your agent codes and runs the tests
Claude Code or Cursor implements the acceptance criteria and runs the tests. It records the results with testrun.create against the current commit, then pdlc.verify grades them — failure buckets, reliability KPI, deterministic nextStep — and feeds the result back into your IDE.
A quality grade you can defend
Every test run gets a verdict pinned to a specific commit. Pass — merge it and freeze the run as a baseline. Fail — the next step tells your agent whether the code or the test is wrong. You ship with a reliability score, not a green CI badge you can't explain in standup.
> project.initialize { repoRoot: "/Users/me/checkout-v2" }
# new feature on an existing product
> feature.implement { title: "Apple Pay button", sessionId: "pdlc_…" }
# after your agent codes — grade the work
> pdlc.verify { testRunId: "tr_…", sessionId: "pdlc_…" }
Every verify call returns the same contract.
No LLM in the pass/fail decision path. Failure buckets are machine-categorised. Every run carries gitSha, branch, and workingTreeClean — so the verdict is bound to exactly the code that ran.
// pdlc.verify → returns
{
"verdict": "fail",
"passed": 14,
"failed": 2,
"waived": 0,
"waivedCaseIds": [],
"failureBuckets": {
"selector-not-found": 1,
"text-mismatch": 1
},
"reliabilityKpi": {
"passRateMet": false,
"selectorShareMet": true,
"passRate": 0.875,
"selectorFailureShare": 0.5
},
"gitSha": "a4f9e2c",
"branch": "feat/checkout-v2",
"workingTreeClean": true,
"testRunId": "tr_a4f9e2c-001",
"sessionId": "pdlc_q4-checkout-v2",
"nextStep": {
"action": "repair_code",
"caseId": "tc_204",
"failureBucket": "text-mismatch",
"hint": null
}
}Everything your agent can reach for.
You don't call these tools yourself — ask your agent in plain English and it picks the right one. Every tool, with example requests, is listed on the MCP Tools page inside the app.
Explore your running app
exploration.start · observe · to_casesYour agent clicks through the app in its own browser (for example Playwright MCP). Test Maze verifies each step, suggests what to try next, tracks coverage and turns the journey into test cases. It never opens a browser itself.
Find what is not tested yet
coverage.gap_for_featureSorts a feature’s test cases into 8 facets — happy path, edge cases, errors, permissions, accessibility, performance, browsers, unusual data — and names the gaps, including missing acceptance-criterion numbers.
Keep fixed things fixed
regression.freeze_run · case.waive_acFreeze a fully passing run as a baseline: any later run that drops or breaks one of its cases fails the verdict. Deliberately skip a criterion with a recorded waiver instead of leaving it silently untested.
Keep the code healthy
quality.smell_check · architecture.adviseA code-smell check with fixed rules — same code, same findings — mapped to the refactorings that fix each smell, plus design advice that ranks proven patterns against your problem. Your agent still makes the call.
Always on the right project
project.whoami · npx @testmaze/mcp whoamiEach project folder keeps its own token in .env.testmaze, so two repos on one laptop never write into each other’s workspace. Your agent checks which workspace and user it is connected as before changing anything.
Watch it happen
Agent SessionsEvery prompt, tool call, test run and verdict appears live on Agent Sessions as a feed, a graph and a timeline — in plain English, scoped to your workspace.
Wire your coding agent
to a real verifier.
Five minutes to install. Deterministic verdicts from the first run. Test Maze never reads your repository — your agent sends results, and verdicts come back. Start on the free Basic plan; upgrade when your team scales.