# Give the agent something it can prove.
> For engineering teams already using Claude, Codex, CI, and code review: turn one feature requirement into an observable check before calling the work done.

Canonical URL: https://rida.me/verification-kit/


A green test suite and a working feature answer different questions. In [The Agent Ran My Manual Tests](/blog/the-agent-ran-my-manual-tests/), I described a refactor that passed its tests while breaking the visible weather widgets. A human-readable browser check caught the regression.

This kit makes that distinction concrete. Use the example below, then adapt the brief to one change in your own development environment. It does not run a coding agent or connect to your repository.

## Start with one observable change

Write down the job, the boundary, and what would convince another engineer that it works:

| Part of the brief | A useful answer |
| --- | --- |
| Change | A person choosing two seats should see the total for two seats. |
| Starting state | A synthetic fixture, two seats, 25 credits per seat. |
| Action | Change the quantity or choose the supplied example. |
| Expected result | The visible total is 50 credits. |
| Evidence | Source revision, exact input, observed output, and the check result. |
| Boundary | No real checkout, account, payment, deployment, or external service. |
| Human decision | Review the evidence before deciding whether the change is ready. |

“The agent said it passed” is not an observed result. A screenshot without the starting state is hard to reproduce. An unrun check should say **not run**, rather than borrow a pass from a different test.

## Worked example {#worked-example}

The [synthetic seat-total fixture](/verification-kit/fixture.html) has two modes. Both use the same correct arithmetic. One deliberately presents the wrong value in the interface.

| Check | Regression mode | Corrected mode |
| --- | --- | --- |
| Arithmetic: 2 × 25 | 50 — passes | 50 — passes |
| Visible total | 25 — acceptance fails | 50 — acceptance passes |
| Meaning | Correct calculation, incorrect presentation | Both checks agree for this example |

1. [Open regression mode](/verification-kit/fixture.html?case=regression). Leave the quantity at two.
2. Read the visible total, then select **Check the visible result**. The fixture reports expected and observed values separately.
3. [Open corrected mode](/verification-kit/fixture.html?case=corrected) and repeat the same check.
4. Change the quantity. The example remains reproducible without an account, model call, or real order.

The result is a deliberately small, deterministic exercise. It is not a recording of an agent fixing a product, a customer outcome, or proof that a broader workflow is safe. The JSON shown by the fixture records this example's comparison only; attach a real source revision and environment when adapting the brief.

## Take the brief to your own change

[Download the Markdown verification brief](/verification-kit/manual-test.md). Fill in the change, allowed actions, prerequisites, source revision, exact steps, and expected result. Leave the observed result and evidence blank until someone actually runs it.

Keep the first exercise in a disposable development environment with fictional data. Supply credentials through your existing approved mechanism when a later test requires them; do not put secrets, customer records, or production tokens in a shared brief. A unit test, browser check, CI run, and human review each contribute different evidence.

My [notes on setting agents up to succeed](/blog/setting-agents-up-to-succeed/) explain the context and tool boundaries behind this approach. The [ConFoo talks and their public source](/talks/) show the wider environment and review workflow. These are accounts of my work, not a guarantee that the same setup fits every team.

## Choose the next step {#choose-next-step}

**You already have a repository, coding agents, CI, and a review process.** Review [Agentify’s software-engineering workflow](https://runagentify.com/software-engineer) and its current product evidence to see how tracked work, CI and human review fit together. This fixture does not connect to Agentify or run your workflow.

**The problem needs architecture and product decisions before a build.** The existing [AI Workflow Opportunity Sprint at Amidship](https://amidship.com/work-with-us/#ways-to-start) is a two-week starting engagement. Review its current scope before [asking Amidship about that Sprint](mailto:admin@amidship.com?subject=AI%20Workflow%20Opportunity%20Sprint). This kit does not promise an engagement, a delivery result, or availability.

For a technical question about this example or my writing, use the existing [contact page](/contact/). Include the outcome you need and the part of the verification boundary that is unclear. Product support belongs with the relevant product's official channel.