Make and review your first change

A small improvement is a good way to learn discerndiscern↗A tool that installs and runs an agent development practice in a project.'s complete workflow. You can see whether the result helps, understand what your agent checked, and make a landing decision without needing to follow every line of code.

This tutorial uses a search page that says “No results” when it finds nothing. You will ask your agent to make that message more helpful, try the result, and decide whether to add it to the shared project. The same pattern works for a clearer button label or a short explanation beside a form.

Finish setup and open a fresh coding-agent session that can call discern's tools. Use a project where you can try a small change locally. If it has no search page, choose another small wording improvement you can see in the app or its documentation.

The time depends on your project's checks. Allow for your agent to make the change and run those checks, with a few minutes of your own time to try the result.

Tell your agent:

Make the message shown when search finds nothing more helpful. Suggest wording that tells people they can try a different search. Keep the search behavior the same. Show me how to try the result, explain what you checked, and wait for my review before landing it.

This request gives the agent a purpose and a clear limit. You want to help someone continue after an empty search; you are not asking for a new search system.

For another feature, keep those same ingredients: what should improve, what should stay the same, and how you want to review it.

Your agent checks the project state, creates an isolated workspace called a worktree, and makes the change there. The project's shared branch, called the trunk, stays apart from the unfinished work.

The agent then commits the change and runs the project's configured checks, collectively called the gate. The checks need a committed version, because their evidence has to describe something that can land. A check might confirm that the app builds or that searching still returns the expected items. If a check fails, the agent investigates and fixes the cause before reporting completion. Fix a red gate explains that path.

You should receive the changed wording, a way to try the right version, an account of the checks, and a Proof line. Proof records that the gateGate↗The configured checks a change must satisfy for ordinary completion. passed for one exact saved version of the change. It lets you connect the agent's report to the work that was checked.

A message such as “No results. Try a different word or a shorter search” offers a next step. Its usefulness still depends on your app: if it only searches exact item names, the wording should reflect that.

This is a review of the experience you requested. Your knowledge of the people using the app helps you notice things an automated check may not capture.

Ask:

Explain the Proof for this change. What checks cover the search behavior, what did you try directly, and what remains for me to assess?

Your agent can retrieve the full Proof through discern's status tool or discern status --verbose. The answer should distinguish checks recorded by the gate from observations the agent made separately. A passing build, for example, does not tell you whether a message is clear.

For this small change, you now have the requested result, your own experience of it, and the evidence available. If any of those are missing, ask for them before deciding. Larger changes may call for code review, independent review, or checks on another device; the depth should fit the consequences of the change.

If the wording is still unclear, give specific feedback:

The message should say that search only looks at saved items. Please revise it and bring the checked result back.

The agent continues the same task. Its revised files need fresh verification because the previous Proof covered a different version.

When the result is right, say:

I've reviewed the change. Land it.

Your agent uses discern's acceptance operation, which checks the evidence and your permission before moving the change onto the trunkTrunk↗The shared branch that accepted work joins, usually main.. Its result answers about this change first: landed, or not landed and why. Other finished tasks that already have your permission to land may land ahead of it, in order. It reports any cleanup still needed. If the shared project has changed in the meantime, the agent follows discern's instructions to bring the work together and verify it.

Landing makes the change part of the shared project. Publishing it to users is a separate step in your project's release process.

The small improvement is on the trunk, with a record of the checks that covered it. You have also practiced the part of the workflow that will stay useful as the work grows: give a clear purpose, try the result, understand the evidence, and decide what becomes shared.