Wrapup Session

Session wrap-up

This is the last turn of the session: the harness may quit as soon as it settles. Do not ask questions. State assumptions and finish. When arguments are passed, treat them as the focus of the pass.

1. Repeat invocation

Check the conversation for a closing report from an earlier invocation of this skill: the labelled to-do list (Commit: …, Push: …) is its signature. If one is there, this is a repeat call, and the session must end clean this time instead of deferring again.

On a repeat call, do not re-list the leftovers. Finish them:

• Execute every remaining item in the working tree: apply the deferred fix, write the code or the docs entry, draft the upstream report, delete the scratch files left in a checkout, run the verifications. Re-verify each item first, per § 2: work finished by hand since the last report is done, not to do.
• The repeat invocation is the user's go-ahead to commit: stage and commit the finished work locally, one commit per strand, following the commit-message rules. A first invocation never commits; a repeat one does.
• Pushing to a remote and posting to an external service still need the user's own hand. If only such items remain, say the tree is clean and name them.
• Then run the lessons pass (§ 3) and close with the same two lists (§ 4), near-empty by design.

2. Loose ends

Collect what this session leaves behind:

• Promises made in the conversation but not delivered: deferred fixes, "later" items, questions parked with a workaround.
• Working-tree changes this session created or touched, still uncommitted. Check git status and name only what this session produced. Never push or post anywhere; committing is reserved for the repeat invocation (§ 1).
• Background jobs or processes started here and still running.

Verify every candidate against the current state before listing it. The user often fixes, commits, or cleans items by hand between the last prompt and this wrap-up, and a stale item tells them to redo work already done. For each candidate, re-check the evidence: re-run git status and git log rather than trusting an earlier snapshot, read the file a fix would touch, check whether a deferred report or upstream comment already exists. Drop every item that is already resolved. When an item is only partially done, list only the remainder.

Never list the cleanup of temporary files that the next reboot deletes. macOS empties /private/tmp at each boot, so a scratchpad or a build tree left there needs no item. Apply the same test to the temporary directory of any other machine or virtual machine. A scratch file left in a checkout stays a loose end. A draft or a result the user still needs keeps its own item, whatever directory holds it.

3. Lessons worth persisting

A candidate lesson is a correction the user gave, a surprise that cost time, or a rule stated nowhere. Skip anything the code, git history, or existing docs already record.

Route each keeper to the narrowest home that owns it. The global instructions file loads into every session of every project, so it is the last resort, not the default:

• A rule specific to one project: the project's own CLAUDE.md or AGENTS.md. A lesson about maintaining a tool belongs to that tool's repository, even when the session ran elsewhere.
• A step of a repeatable procedure: the skill that performs it, new or updated. This wrap-up skill is itself a valid target: an improvement here compounds across every later session.
• A decision tied to one spot in the code: a comment or docstring at that spot.
• A fact about this machine or the user: persistent memory, when the harness provides one.
• A rule a machine can check: propose a test or lint. Mechanical enforcement beats prose.
• A habit or correction that holds across projects and tools: the global agent instructions file (the CLAUDE.md or AGENTS.md loaded from the home directory). Resolve symlinks and edit the target file inside its repository, never through the $HOME path: a replace-then-rename write forks the symlink.

Guards:

• An empty result is the normal outcome. Most sessions teach nothing new: report "nothing to persist" and never invent a lesson to fill the section.
• Read the target file first and dedupe: update an existing rule in place instead of appending a near-duplicate.
• Write a lesson for the global file as its rule and its fix, in two sentences at most. Leave the story out: no dates, durations, counts or account of what happened, and a version stamp only on a claim about the harness itself. Keep an exact error string when it is how the situation announces itself.
• Measure the global file before and after the pass (wc -c): each lesson adds about 400 characters at most. More means a story stayed in or a narrower home was skipped, so cut until it fits. When the harness warns that the instruction files exceed its size limit, remove at least as much as the pass adds.
• Apply small, safe edits directly, in the working tree only. Anything larger becomes a one-line proposal, reported as a Review: item in the closing report (§ 4).