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

# Your first eval

> Ask your agent to run and report one bounded Stet evaluation

Your first eval turns a credible onboarding slice into one bounded measurement.
You set the question and the spend boundary; your agent proposes a plan, runs
it after you confirm, and reads the Trial Result for you.

## Say this

```text wrap theme={null}
Use the Stet skill and the existing onboarding receipt for this repository.
Propose one bounded first eval on the selected slice. State the treatment,
baseline, verifier, expected duration, expected model-token spend, Docker load,
and decision this can support. Confirm the plan with me before running anything
that spends model tokens. After I approve, run it and read the Trial Result.
```

## What happens

Your agent should turn the onboarding receipt into a narrow evaluation plan:
one declared harness change, one task slice, and the existing bounded verifier.
Time and cost depend on your slice and provider, so have it state estimates
before it starts. Spend draws on the provider account your agent already uses
— your existing usage limits, not a separate bill — and a full eval can
consume a substantial portion of a \$100 or \$200 monthly subscription tier's
limits, so treat the pre-launch estimate as a real gate. Docker-backed replay
is the normal setup for evidence you intend to act on. The agent should stop for your approval before any
model-spending launch and should not quietly broaden the task slice to get
more results.

## While it runs

If you want a check-in, ask for the run's recorded state rather than a guess:

```text wrap theme={null}
Use the Stet skill to check this eval's status and execute its next_action.
Tell me whether the run is healthy, and whether the next action spends model
tokens; ask before any spend. Do not restart a run that is waiting on quota,
and do not discard incomplete cells from the result.
```

If the run looks stuck or broken, use [Troubleshooting](/troubleshooting) — it
covers how your agent should classify and recover each failure state.

## What a good answer sounds like

When the eval finishes, ask for the decision:

```text wrap theme={null}
Read the canonical Trial Result and report the routing verdict, confidence, and
next_action. For each metric, say decision-grade, directional, or noise-band.
Give the denominator and coverage, validity, confounds, evidence posture,
observed spend and duration, and what claim this evidence does not support.
```

A good report-back reads like this, with every value taken from the actual
Trial Result:

> "Inspect, low confidence. All 16 matched tasks counted and all 11 graders
> covered them, but the corpus has no genuinely discriminating test cells, so
> no superiority claim is supported. Next action: generate grader-discrimination
> certification; no new coding-agent run required."

It names an action, says how many tasks counted, states the caveat plainly, and
claims no more than the evidence supports. If a metric is only directional,
treat it as a reason to iterate, not to promote. The full report-back contract
and the questions to ask next live in
[Read a Trial Result](/concepts/trial-result).