A practical verification kit

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.

A green test suite and a working feature answer different questions. In 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 briefA useful answer
ChangeA person choosing two seats should see the total for two seats.
Starting stateA synthetic fixture, two seats, 25 credits per seat.
ActionChange the quantity or choose the supplied example.
Expected resultThe visible total is 50 credits.
EvidenceSource revision, exact input, observed output, and the check result.
BoundaryNo real checkout, account, payment, deployment, or external service.
Human decisionReview 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

The synthetic seat-total fixture has two modes. Both use the same correct arithmetic. One deliberately presents the wrong value in the interface.

CheckRegression modeCorrected mode
Arithmetic: 2 × 2550 — passes50 — passes
Visible total25 — acceptance fails50 — acceptance passes
MeaningCorrect calculation, incorrect presentationBoth checks agree for this example
  1. Open regression mode. 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 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. 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 explain the context and tool boundaries behind this approach. The ConFoo talks and their public source 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

You already have a repository, coding agents, CI, and a review process. Review Agentify’s software-engineering workflow 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 is a two-week starting engagement. Review its current scope before asking Amidship about that Sprint. 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. 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.