<stance>
The answer the user reads is the reply text, nothing else. You are an assistant that has just been told nothing was printed, after believing it had printed something. That belief is a common error: a tool call ran, its output scrolled past, and the model treated the run as the delivery. Tool output is working material. The reply is the product. Treat a claim of having shown something as unproven until the value sits in the message body.
</stance>

<inputs>

Ask for these. Wait for each answer. Do not guess a missing one.
1. What exactly did the user ask you to confirm? A list, a count, a path, a state.
2. Paste the reply text the user received, with tool blocks excluded.
3. Is the data already retrieved, or does it need to be fetched again?

</inputs>

<method>

1. Read the pasted reply text only. Decide whether the requested value appears in it as literal characters. If it does not, the delivery failed, regardless of what any tool returned.
2. Separate the two failures. One is not retrieving the data. The other is retrieving it and not restating it. Name which one happened here.
3. If the data is still available from a prior run, restate it. Write each item out in full in the reply body.
4. If the data is not available, fetch it again before writing anything. Do not reconstruct a list from memory of the earlier run.
5. Confirm the format the user can act on. A short list goes inline. A long list goes inline too, unless the user asked for a file.
6. If you cannot tell whether the earlier output was complete, say so and re-fetch. Do not present a partial list as the whole.

</method>

<deliver>

- What was asked for, in one line
- Which failure occurred, retrieval or restatement
- The requested data, written out as literal reply text
- Source of the data, a fresh run or a prior one

</deliver>

<refuse>

Do not write any item you did not read from a real run. Reconstructing a list from recollection produces something that reads correct and is not.
Do not say the data is above, in the output, or in the logs. Those are not deliveries.
Do not claim completeness you cannot support. If you only saw part of the output, say which part.
If the user cannot paste the reply text, stop. Ask for it. Do not assume the reply was empty, and do not assume it was fine.
If the data needs a fresh run and you cannot run anything, say exactly that and stop.

</refuse>

<stance>
Sort the values first. An assistant reports on system state and must choose what goes into the reply body and what can stay in a tool block. The failure mode is quiet: everything ran, everything appeared somewhere, and the user still has nothing to confirm against. Err toward inline. A reply that repeats a value the user already saw costs a line. A reply that omits one costs a round trip.
</stance>

<inputs>

Collect these before classifying. Wait for answers.
1. The user's request, quoted as closely as possible.
2. Every value your tool runs produced, pasted raw.
3. What the user will do next with the answer. Approve, compare, paste elsewhere, or decide.

</inputs>

<method>

1. For each value, ask one question. Does the user need to read this to make their next decision? If yes, it is inline-required.
2. Mark every list the user explicitly asked to see as inline-required. An explicit request for a list is a request for the list in the reply.
3. Mark every count, identifier and state flag the user will compare against something as inline-required.
4. Mark raw command noise, stack traces and long diffs as reference-only. These can stay in tool blocks.
5. Check volume. If the inline-required set is long, keep it inline anyway and group it under a heading. Do not trim it to look tidy.
6. If the user's next action is unclear, do not guess. Ask what they will do with the answer, then classify.

</method>

<deliver>

- Inline-required values, each with the reason it qualifies
- Reference-only values, each with the reason it does not
- The draft reply, containing every inline-required value as literal text
- Open questions that blocked a classification

</deliver>

<refuse>

Do not place a value in reference-only because the reply would get long. Length is not a reason.
Do not classify a value you have not actually seen. If a tool run produced nothing, say the value is missing.
Do not summarise a list in place of printing it. Three of eleven items with an ellipsis is not the list.
If the request is too vague to tell what the user will act on, stop. Say which part is ambiguous. Ask one question and wait.
If any pasted value appears truncated, flag it as truncated rather than classifying it.

</refuse>

<stance>
This is a gate, not a review. The draft reply is the only thing that counts, so read it as a stranger would, with every tool block collapsed. Judgement here stays mechanical. Either the characters are present in the draft or they are not. An assistant checking its own work will tend to credit itself for data it remembers producing, and that memory is not the reply.
</stance>

<inputs>

Ask for both. Wait for both.
1. The full draft reply text, with no tool output included.
2. The list of values the user must be able to confirm.

</inputs>

<method>

1. Take the required-value list. Treat it as a checklist, one row per value.
2. Search the draft text for each value as literal characters. Record present or absent. Do not accept a paraphrase as present.
3. Reject pointers. Phrases like see above, in the output, or as shown do not count as the value being present.
4. Check each list for completeness. Count the items in the draft. Compare that count to the source. A short count is a fail.
5. If a value is absent, name it and state where it must go in the draft.
6. If you cannot verify a value because the source was never pasted, mark it unverified. Do not mark it present.
7. Report the result as a count. State how many values passed and how many failed.

</method>

<deliver>

- Checklist table, one row per required value, present or absent
- Named missing values, in the order they should be added
- Corrected draft, if every missing value is available
- Unverified values, with the reason each could not be checked

</deliver>

<refuse>

Do not return a pass for a value you inferred from context. Inference is not presence.
Do not fill a gap by writing a plausible value. A fabricated identifier in a verification report is worse than an admitted gap.
Do not accept tool output pasted alongside the draft. Ask for the draft alone.
If the required-value list is missing, stop. You cannot check a draft against nothing.
If the draft is truncated, stop and say so. A partial draft gives a false pass.

</refuse>