> ## Documentation Index
> Fetch the complete documentation index at: https://predev.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Agents: start with https://docs.pre.dev/agents.md, which has complete recipes, plan access, polling rules, errors and limits.
> Authenticate with the workspace API key (pdk_…) from Integrations → Built-in, sent as Authorization: Bearer <key>.
> REST API: https://api.pre.dev (OpenAPI: https://docs.pre.dev/api-reference/openapi.json). AI Gateway: https://api.pre.dev/v1, OpenAI-compatible (OpenAPI: https://docs.pre.dev/api-reference/ai-gateway.openapi.json).
> pre.dev MCP server: npx -y @predotdev/mcp setup adds it to every local coding agent with every pre.dev tool plus the user's own Chrome; the hosted server is https://api.pre.dev/mcp. Search these docs over MCP at https://docs.pre.dev/mcp.

# Verification

> Define acceptance criteria and read how an independent judge checks the work before a build finishes.

Acceptance criteria describe observable behavior that should hold when the work is complete. Include them in the task or specification so implementation and review use the same definition of success.

```text theme={null}
A team member can export only the invoices they can access.
The CSV preserves currency and timezone information.
An empty result shows a useful message.
A failed request leaves the export button usable for retry.
```

## How a build is verified

Before a build that changed code finishes, the agent submits the work to an independent judge. The judge reads the recorded commands, tool results, and browser checks from the run, never the agent's own summary, and scores every acceptance criterion. For criteria it cannot prove, a separate QA agent checks the app live. The agent then fixes what is still unproven and submits again.

The **Verify** card in the chat reads "Verifying…" while the judge runs and then shows the verdict, for example 13/15 proven and 2 needing proof, with each unproven criterion and why. Each judge call uses credits like a turn and appears in the project's credit breakdown as the verification judge.

## Evidence to inspect

| Check | Useful evidence |
| - | - |
| Types and lint | Actual commands, exit results, and relevant failures |
| Tests | Which behavior and regression cases were exercised |
| Browser flows | The user action and its observed result in the same flow |
| Screenshots | Captured state, viewport, and the feature being reviewed |
| Design review | Specific layout, accessibility, or component-state findings |

Browser tools can navigate, interact, assert outcomes, and capture screenshots. A screenshot establishes visible state; a passing interaction assertion establishes more about behavior. Both can be useful in review.

## Make the checks reproducible

Provide the project's setup commands, test accounts or role requirements, and any services needed to run the application. Ask the agent to identify skipped checks and blockers such as missing configuration or an unavailable preview.

For permissions-sensitive features, verify both allowed and denied cases. For UI changes, include the relevant screen sizes and interaction states. Review test data and external side effects as part of the task scope.

## Before shipping

Read the diff and the verification result. A passed verification covers the criteria the judge scored, not every possible behavior. Repository CI and your review process still decide whether a change is ready to merge or publish.

Continue with [pull requests](https://predev.mintlify.site/coding-agent/building/pull-requests.md), [preview](https://predev.mintlify.site/coding-agent/building/preview-and-hosting.md), and [publish](https://predev.mintlify.site/coding-agent/building/publish.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.