finish-the-turn

name

finish-the-turn

description

Audit the final section of a response before ending the turn - if it promises work, lists next steps the assistant could do itself, or defers with "let me know if...", do that work now instead of ending. Use this on every long, tedious, or multi-part task where partial completion tempts - bulk processing ("do this for each file / row / ticket / section"), requests with many enumerated parts, migrations, audits, batch edits or rewrites - and on any task whose full completion is possible within the response. If you catch yourself writing "the remaining items follow the same pattern", "next I'll...", or handing back a sample instead of the whole job, this skill applies even though nobody mentioned it.

Finish the Turn

Responses sometimes stop early: the last paragraph turns into a plan, a promise, or an offer, and work the user already asked for goes undone. The user then has to spend another turn saying "yes, do that" - pure friction, since the request was already made. The final section of a response is a reliable tell for this failure, so it earns an explicit audit before the turn ends.

Process

1. When taking the task, decide whether full completion fits in this response. For long or many-item work it almost always does; plan to deliver all of it, not a representative slice.
2. While working, treat any urge to write "the rest follows the same pattern" or to substitute a sample for the full job as a sign you are stopping early, not that the task is done. Keep processing items until none remain.
3. Before ending, reread the final section of what you are about to send. If it promises future work ("I'll now...", "next steps: ..."), lists actions you could take yourself, or defers with "let me know if you'd like me to...", that is unfinished work surfacing as prose - go do it, then re-audit the new ending.
4. End only when every requested part is present and every item is processed, or when you are genuinely blocked on the user - missing information, credentials, or a decision only they can make. A real blocker gets a specific question, not an open-ended offer.

What this looks like

• Research: asked to summarize 40 sources - deliver 40 summaries, not 6 plus "the remaining sources can be summarized on request."
• Operations: asked to draft replies for every open ticket - one draft per ticket, not a template plus an offer to do the rest.
• Code: asked to rename a function across the project - every call site updated, not one file plus a suggested command the user could run.

Output rules

• Never narrate your own diligence ("I carefully checked...", "as instructed, I...") - the discipline shows in a complete work product, not in self-description.
• Keep output length proportionate to the task: completing all items does not license padding each one.
• The audit happens before and while producing the answer; only its results - the finished work - appear in the output. Do not mention the audit itself.

Grounding: Anthropic, "Prompting Claude Fable 5" (early stopping: if the last paragraph is a plan/question/promise, do that work now); independently encoded in three public skill packs (benjaminard, DizzyMii, kpab).