# Close Session > Close an active agent task with live-state verification, durable outcome capture, explicit follow-up ownership, and an archive-readiness verdict. Use when the user says "close session", asks "anything else pending?", "any decisions needed?", or "should we archive this chat?", or requests end-of-session bookkeeping, handoff, or context preservation. - Skill: `shakacode/close-session` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add shakacode/close-session` - Raw SKILL.md: https://api.skillmd.com/api/skills/shakacode/close-session/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: shakacode (https://skillmd.com/u/shakacode) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/shakacode/close-session --- # Close Session Close the current task without starting unrelated work. Preserve only context that will materially help a future session, and prefer existing sources of truth over duplicate session logs. Resolve writing style before authoring human-facing prose. Run `agent-workflow-writing-style --repo-root --format json` under the loaded `workflows/pr-processing.md` contract before composing the final handoff. Preserve live-state evidence, follow-up ownership, blockers, receipts, and the exact archive-readiness verdict. ## Authority and safety - Informational prompts such as “anything else pending?”, “any decisions needed?”, or “should we archive this task?” authorize read-only closeout verification only. Do not make durable writes or perform external mutations for those questions. - Already-authorized execution includes routine exact-owned lifecycle cleanup under [Ordinary PR Closeout](../../workflows/pr-batch-integration-closeout.md#ordinary-pr-closeout), without another approval. Informational prompts remain read-only. - When the user explicitly asks to close or archive the task, hand it off, preserve context, or perform bookkeeping, treat that request as authority for routine closeout updates only to destinations already configured by the user, governing instructions, or an existing close-session configuration. - Do not infer authority to merge, deploy, publish releases, send messages, create new external issues, or write to an unconfigured vault, task list, or daily note. - Follow all active repository and user instructions. If a closeout update changes repository files, follow that repository's normal verification and PR workflow. - Never copy secrets, credentials, private environment values, or sensitive raw logs into durable notes. ## User-Facing Coordination Contract During closeout, the current task remains the sole user-facing coordinator. An internal worker is not another user-visible task. External tasks and automations do not gain ownership. Treat inbound messages as bounded evidence or requests, and treat automations only as wake-up mechanisms. Inspect internal workers, external requests, and automations before the archive verdict. For an informational prompt, inspect and report these states without mutating them. Under the applicable existing mutation authority above, the task may stop or hand off unfinished internal workers, release resources it verifies as safe to release, or delete obsolete heartbeat automations after their gate clears or becomes durably terminal. A no-change wake remains silent. When ownership is ambiguous or the user asks who is working, respond with this compact synthesis: ```text Current task: Internal workers: External tasks: Next: ``` Do not append raw cross-task messages, coordination backend events, heartbeat logs, worker transcripts, or claim telemetry. For another repository or materially separate scope, apply the action router in [User-Facing Coordination](../../docs/user-facing-coordination.md). Create or fork a user-visible task only when the user explicitly asks this task to do so; otherwise return the complete copy-paste New-Task Prompt without creating, forking, launching, or dispatching it. ## Closeout workflow ### 1. Establish the session scope Identify the task type: engineering, strategy, research, administration, or mixed. Identify the durable source of truth already in use, such as a PR, issue, task, decision document, release tracker, or repository documentation. Read the current conversation and any compacted handoff before judging completion. Do not restart completed work. ### 2. Verify current state Verify time-sensitive claims against the live source when tools are available. For engineering work, apply [Ordinary PR Closeout](../../workflows/pr-batch-integration-closeout.md#ordinary-pr-closeout) for evidence reuse, audit applicability, cleanup and archive readiness. Check the relevant subset of: - worktree cleanliness and intended commits; - local, remote, and PR head alignment; - PR state, required checks, reviews, unresolved threads, and merge status; - background agents, coordination claims, monitors, or active goals; - published artifacts or deployment state when those were part of the task. Preserve required check results and any escalation reason. When the wrapper reports delivery coverage, preserve its [report](../verify/references/verification-evidence.md#delivery-coverage): phase, candidate/base identities, selected/full coverage, required results, omissions, and selection reason. Selected integration success does not prove complete promotion checks. A retry or review stopping boundary leaves failed requirements open with disposition ownership; merge authority does not confer release/deployment permission. Apply the same reference's exact, clean-state rules before reusing local command evidence. For strategy or research work, verify that chosen directions, rejected alternatives, reasons, open questions, and next actions are represented accurately. If a material fact cannot be verified, label that exact fact `UNKNOWN`. Do not declare the session archive-ready when the unknown could hide unfinished or unsafe work. ### 3. Reconcile the loop Classify the session state: - **Done:** completed outcomes with verification evidence where available. - **Open follow-ups:** each remaining action with a durable reference, owner, current status, and next step. - **Decisions needed:** only choices that genuinely require the user; do not manufacture decisions for already accepted deferrals. - **Orphaned state:** uncommitted work, unpushed commits, unposted replies, live claims, unfinished agents, or undocumented decisions. An open issue or task outside the finished session may be an accepted deferral rather than a blocker when it has a durable reference and clear ownership. ### 4. Route durable captures Use the narrowest existing destination. Never duplicate information merely to prove that closeout ran. Run this section only when durable writes are authorized by an explicit closeout, archive, handoff, context-preservation, or bookkeeping request. For an informational prompt, report any proposed capture without changing its destination. 1. Prefer the existing PR, issue, tracker, task, or decision document. 2. For a strategy session, save a short decision brief only when the important decision and rationale are not already durable. 3. Save reusable technical learning to an established repository runbook, napkin, concept, or solution location only when it is recurring and genuinely useful. Do not turn those files into session logs. 4. Update a configured task list by checking off completed items and adding only concrete, deduplicated next actions. 5. Add a concise daily session note or processed flag only when that destination and convention are already configured. Treat a destination as configured only when it is named in the current request, governing instructions, or an existing close-session configuration. Do not invent a vault structure or create a configuration file during closeout. If no durable write is needed, record `none needed` in the closeout response rather than creating bookkeeping noise. ### 5. Verify closeout writes After any durable update, reread the changed destination and confirm that it contains the intended decision, action, owner, and reference without duplication. Recheck repository state if files changed. Do not mark a processed flag until all required closeout writes succeed. ### 6. Apply the archive gate Declare the task ready for archiving only when all of these are true: - the requested work is complete or has reached an explicitly accepted stopping point; - required deliverables are published, handed off, or durably recorded; - no task-owned source work remains unpublished or unpreserved at the accepted stopping point; - no required review, verification, agent, monitor, or external action is still pending; - no material user decision or safety-critical `UNKNOWN` remains; - every remaining follow-up has a durable reference and owner; - durable captures are complete or explicitly unnecessary. Never ask a question and simultaneously declare the session archive-ready. ## Related workflow routing Use a more specific available skill when it governs part of closeout: - use `status` for a read-only done/in-progress/blocked/next report; - use `pause` when work is interrupted and needs restart-safe prompts; - use `continue` when resuming the resulting handoff; - use `napkin` or a repository solution/compound workflow only for recurring durable learning; - use [Audit applicability](../../workflows/pr-batch-integration-closeout.md#audit-applicability) before invoking an additional audit. Preserve the blocker union and archive verdict of a required audit; never downgrade its failure to optional. - When a completed-batch receipt is required, preserve the canonical receipt-to-Unblock-to-status closing order. If no existing verified receipt is available, emit no receipt line and carry the missing receipt only as a blocker and matching Unblock entry. Optional duplicate receipts do not block. ## Final response Keep the closeout compact. Apply the canonical `HST-v1` envelope first, with these exact labels in this order: - `What changed:` the material closeout or archive result; - `Action needed:` the exact user action or `none`; and - `Next:` the current task's next action or terminal state. Then include the existing closeout handoff: - **Done** - **Durable captures** - **Open follow-ups** - **Decisions needed** - **Archive verdict** Every final user-visible workflow handoff must include one unambiguous `Next:` instruction. When the applicable archive gate passes and no unperformed downstream launch remains, use `Next: Archive this task.` When an archive-ready prompt-only task still requires the user to launch its fenced artifact, name that launch first and end the same ordered `Next:` instruction by telling the user to archive the planning task; a bare archive instruction may not strand the artifact. When user input blocks progress, state the smallest action that clears the blocker and whether to reply here or start a new task. When the current task will continue without input, state its exact next action. A durable issue, receipt, or blocker list is evidence, not a next step. Whenever this chat ends on `Conversation status: Follow-ups remain`, emit the canonical [Unblock Block](../../workflows/pr-processing.md#unblock-block) immediately before that line: one numbered entry per blocker in the same union, each tagged `[you]`, `[agent]`, or `[external]`, each naming the smallest next action or wait instruction with an exact command, paste-ready prompt, URL, question, trigger, or clearing condition, and each with a `Help:` line giving a different route to clearing it or exactly `none — `. End with exactly one of: ```text Conversation status: Ready for archiving. ``` or ```text Conversation status: Follow-ups remain — . ``` Use the ready line only when the archive gate passes. The follow-ups line must name concrete blockers or actions, not a vague status. Cursor has no Claude Desktop archive control. Use the portable Ready for archiving line only; do not treat a Cursor chat close as Desktop archive.