# Working with your agent

> Choose what to test, how long to spend and when to stop.

Web page: https://supercov.com/docs/agent-loop
All Supercov pages for agents: https://supercov.com/llms.txt · Full text: https://supercov.com/llms-full.txt

Once you've tried [one test](https://supercov.com/docs/getting-started.md), give your agent an area to
work on and a stopping point. Supercov supplies the coverage data; your agent
decides which tests to write and edits them in your repository.

## Choose what matters

Start with code where a missed case would matter: checkout, permissions,
data changes or error handling. You can name a feature or a folder. The agent
doesn't need to work through the whole repository in order of coverage percentage.

For a longer run, paste this and add your area and time budget:

```text supercov-prompt
Use `npx supercov` to improve coverage. Read its agent-loop instructions
before starting. Work on one useful gap at a time and only change tests.
Do not weaken existing checks or change application code to raise coverage.
Begin and end with the same full test suite. Stop at the time budget,
when no useful gap remains, or when a measurement limit blocks progress.
Show the tests changed, what they check, suite results and coverage changes.
```

For example, add: “Focus on checkout failures. Spend up to 30 minutes.”
If the agent finds an application bug, ask it to report the failing case and
wait before changing the implementation.

## Include assertion coverage

Running tests records execution. Assertion coverage also needs the agent to
map what those tests check. Ask it to follow [the assertion workflow](https://supercov.com/docs/assertions.md)
and update the map after changing tests. Without that work, an unmapped
statement doesn't necessarily mean a test is missing.

## Overnight runs and software factories

Supercov is a tool for your agent, not a scheduler or another agent. Start a
long-running task using your agent's normal workflow, and give it a time budget
and the same boundaries you'd use for a short run.

If several agents work in parallel, use separate worktrees so they don't
overwrite each other's tests. Each should return its changes and the run IDs
it compared. After combining changes, run the full suite again.

## Review before moving on

Ask for a summary of the behavior each new test checks, not just the number of
tests added. Compare runs of the same full suite; a smaller focused run is useful
while writing a test but isn't a before-and-after comparison for the whole project.

Want a pull request? Add: “Open a PR with the test changes and a short summary
of the results.” Supercov doesn't create a commit or PR itself.

## Know when to stop

Some code can't be reached through the behavior your project supports. Some
results are limited by what the runner can record. Neither is a reason to
invent a test or weaken an assertion to reach 100%.

Your agent should leave those cases in its summary so you can decide what to
do next. [Reading the results](https://supercov.com/docs/verification.md) explains the distinction.

## Example

The [MC/DC guide](https://supercov.com/docs/mcdc.md#example) shows how to find a missing expired-session
test. It includes runnable examples in five languages, actual output and the
completed tests. You can follow the commands yourself or ask your agent to
work through the example.

For a broader walkthrough of unit tests, browser checks and regression tests,
see [Testing with Claude Code](https://supercov.com/blog/claude-code-testing.md).