File size: 4,560 Bytes
68d7816 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 | You are about to run out of context. Create a handoff summary for the
model that will resume this task after the earlier conversation is cleared.
--- This message is a direct task, not part of the above conversation ---
Do not impose rigid section headings; let the shape follow the task. Write it
in the same language the conversation has been using β do not switch to English
just because these instructions happen to be in English.
Make the summary self-sufficient: the next turn will see only the preserved
messages and this summary β every other assistant message, tool call, and tool
result above will be gone. In your own words, preserve what you genuinely need
to continue:
- What the latest request is actually asking for: your reading of its intent and
any ambiguity you have already resolved β not a re-transcription, since what
fits is kept verbatim in the preserved messages. But those kept messages are
size-capped, so a long request is truncated there: if the latest request is
large (a big paste or file), preserve the parts at risk of being dropped β
above all the actual ask. If several requests are in play, say which one governs
the next move, and re-quote any still-relevant earlier request that may have
scrolled out of the kept messages.
- The instructions and constraints currently in force (user preferences,
project rules, environment and tooling limits) β condensed to what still
matters, keeping decisions you have already settled (what you chose and why)
separate from questions still open, so you neither silently reopen a closed
choice nor treat an undecided point as decided.
- What has actually been done, at high fidelity: keep the exact commands that
were run, the exact file paths touched, and whether each succeeded or failed β
and the results themselves, not just the commands: the concrete values
returned, the key lines or error text, the schema or signature a lookup
revealed, since re-running to recover them may be slow or impossible. Keep only
the final working version of any code; drop intermediate attempts and
already-resolved errors.
- What you still don't know: context the next step depends on that this
conversation never established β files or paths referenced but not yet read,
schemas or APIs assumed but unseen, questions the user has not answered. Name
these gaps so the next turn goes and checks them instead of assuming.
- The forward plan β and this is the moment to invest in it. Right now you
hold more context on this task than you ever will again; the next turn
resumes with less, so the plan you commit here is the one it will follow.
Give the exact next command or tool call, but don't stop at the next step:
set out the remaining sequence to finish, the decisions you have already
made for those upcoming steps (so the next turn doesn't reopen them), the
obstacles or edge cases you can already foresee and how you mean to handle
them, and any work you can commit to now β the exact patch, query, or shape
of the final answer you already know you will produce. Anything you settle
here is one less thing the next turn must rediscover. Include any required
format for the final answer.
This conversation's event log stays on disk and a recovery pointer is appended below this summary automatically, so you need not reproduce long outputs verbatim β keep exact identifiers, key values and error lines, and name anything the next turn should look up.
Your TODO list is re-attached automatically below this summary from its live
source, so do not transcribe it β copying it wastes space and can contradict the
live version. What that list cannot hold is the reasoning between tasks β why one
was reordered or dropped, or a decision on one that constrains another β so
record that instead.
Be honest about uncertainty. If an earlier step claimed something was done but
was never verified (tests "passing", a fix "working", a file "created"), say so
plainly and treat it as unverified rather than fact β re-check before relying
on it.
Be concise, and keep the summary proportional to the task: a long multi-step
task warrants detail, but a trivial or nearly finished exchange needs only a
sentence or two β do not pad it out. Include the critical data, identifiers, and
references needed to continue, and omit anything that does not change the next
move.
Respond with text only. Do not call any tools β you already have everything you
need in the conversation history.
${custom_instruction_block}
|