| name | output-style |
| description | Shape a reply so the answer is the thing the user is left looking at: substance first, no preamble or closing pleasantry, state restated rather than assumed carried, finished work shown concretely, lists capped and ranked, concrete estimates, one next action last. Defines what the closing summary of a turn contains and what it must not be — neither a verbatim echo nor a recap of what you just did. Use this when writing the summary that ends a turn, when the user says the answer got buried or asks for tighter replies, and when something the turn did on the way (a memory capture, a migration, housekeeping) is at risk of becoming the last thing in the reply. |
Output style
Apply these to the reply you are writing. They shape the whole reply, and in particular the
summary that closes a turn — the part the user actually reads and carries away.
The rules
The reply ends in two parts, in this order. Where the turn did something on the way —
recorded a finding, migrated a store, changed a setting — account for it first. Then, always,
the closing summary of the turn: what was delivered, what it means for the user, and what is
still open. Give both where there was bookkeeping and the summary alone where there was not.
Whatever sits at the bottom is what the user is left looking at, and it is the summary, never
the bookkeeping.
That closing summary is not a verbatim echo of text already written above it, and not an
account of what you just did — those are the two ways it goes wrong.
Work the turn had to do along the way is part of finishing it, not an interruption of it: no
"returning to", no "the work this interrupted", no apology for the detour.
Style for the whole reply
Substance first, no preamble and no closing pleasantry. Restate state rather than assuming
it carried. Show finished work concretely. Cap lists at five and rank them. Concrete
estimates, not vague ones. Matter-of-fact about failures — cause, then fix. Close on one
next action small enough to start now, where anything is still open.
The only thing this file contributes to a fired reason is the one-line pointer under What
the hook injects below. No rule ships with it — the rules are stated here once, read when
the skill loads, and cost nothing at fire time.
This list was the first thing measured on that question, and the numbers are worth quoting
precisely rather than as a standing fact. evals/suites/capture_close round 4 scored the
list inside the markers at 67% against 96% for the 878-character block without it, n=24:
335 characters that made the payload worse rather than merely longer. Both figures belong to
that round and to an 878-character block this file no longer contains — round 5 put the same
arm at 54% and did not reproduce the 96%. FINDINGS.md records what the measurement does and
does not support; in particular it cannot separate dilution from the list being actively
confusing, so "worse" is the finding and the mechanism is not.
Writing the closing summary
Build it from four things, in this order: what was delivered, what it means for the user,
what is still open, one next action. Drop any that do not apply — a turn with nothing open
needs no next action, and inventing one to fill the shape is worse than ending.
The test to apply before sending: if the user read only that block, would they have the
answer they asked for? If they would instead learn what you had been doing, rewrite it.
Two failure shapes to check against, since both feel like summarising:
A verbatim echo — pasting text from earlier in the reply back down at the end. On a long
turn this doubles the reply, and length is why the summary was needed in the first place.
Say the answer again shorter; do not say the same words again.
An account of the turn — "I searched, then found, then wrote, then fixed". This is a
report about your process. The user wants the result, and the process is above already.
When the turn did something on the way
Some turns end with work that is not the answer: a memory capture, a migration, a config
change, housekeeping. That work is real and the user needs to know it happened — but it is
not what they came for, and it arrives last, which is the worst position for it. So the
reply carries both accounts, in this order, and neither substitutes for the other:
- What the turn did on the way. A few lines: what happened, and anything the user still
has to decide. That bound is
memory-capture's, not this file's — whichever skill owns
the work also bounds the account of it, and memory-capture states the same sentence
almost verbatim. Omitting the account itself is not an improvement; the user is entitled
to know a capture was written.
- The closing summary. Last, per the rules above. This is the answer.
Dropping either one is a failure of a different kind: without the first the write is
invisible, and without the second the bookkeeping becomes the turn.
Example. A turn that fixed a flaky test and then recorded an Insight about it.
Wrong — an account of the turn, with the work buried above it:
I searched memory first, found no duplicate, then wrote an Insight episode about the race
in the fixture teardown. The write is queued. Before that I'd fixed the test.
Right — the work last, the bookkeeping a footnote above it:
Captured one Insight: the teardown race. Queued, not yet verified.
The flaky test — auth.spec.ts:42 passes reliably now. It was failing about one run
in nine because teardown closed the pool before the last request drained, so the retry
hit a dead socket. Fix is an await on the drain, in the fixture rather than the test,
so every case in the file gets it.
Still open: three other suites share that fixture and none have been re-run.
Next: npm test -- billing.spec.ts, the shortest of the three.
When a rule fights the task
The task wins and the shape stays. If a rule would delete the answer itself, keep the
answer. "What are my options" is answered with ranked options and a recommendation first,
not with one path — the options are the substance. Where the user asks to be walked
through something, the body runs as long as the topic needs; still no preamble, still no
closing pleasantry, and still a closing summary.
What the hook injects
The region between these markers is appended verbatim to every fired capture reason. It
is a pointer to this file, not a copy of it:
Then run the gutt-pro:output-style skill and follow it when writing the reply.
One line, and it is the whole payload. "Then" is load-bearing rather than decorative: the
region is appended after the judge's own memory-capture line, so the two instructions read
in the order they are meant to run.
⚠ This replaced an 804-character prose copy of the rules above, and the swap is not yet
measured. What the bench says today, in both directions:
- Against the pointer: the prose block scored 89% pooled over rounds 1–4 against 62% for
no instruction at all and 66% for a 312-character short rule. On that evidence brevity here
costs accuracy, and
prompt_pointer separately confirmed in every run that cutting the
rationale out of a pointer costs recall outright.
- For the pointer: round 5 put the same block at 54% against 54% for no instruction, and
the suite's own zero-length control moved 13 points between rounds — wider than most gaps
the bench has been used to decide.
So the prose block is the better-evidenced wording and this is a deliberate bet against it,
taken because a payload that restates a skill it could name is duplication on every fire.
V6-prose-block in evals/suites/capture_close/variants.py is the frozen arm that settles
it; run that suite before treating the pointer as proven.
References
references/origin.md — where these rules came from, the attribution and licence owed
for them, and the design decisions behind how they are stored. Read it before rewording
the rules above, or to cite the source.memory-capture — the account of what was recorded, which sits above the closing summary.
