session-end — Claude Code subagent: finalize a work session
A subagent that closes out a work session: records lessons, open issues, next steps and any state other handlers missed.
/plugin marketplace add wshobson/agents
/plugin install operating-kit@claude-code-workflowsWhat session-end does
session-end runs at the end of a significant work session. It opens the project's canonical state file and the memory index, finds the fields that went stale during the session, and edits just those. The whole file never gets replaced.
Five steps: read the current files, pin down what is now stale, update work blocks, the known-issues list and next-up lines, refresh the memory index, then report exactly what changed as old value to new value. If nothing significant happened, it says so and skips the edits. Deploy state stays untouched when deploy already refreshed revision or version fields this session.
Before the first run you point two placeholders at real paths: {{STATE_DOC}} for the single source-of-truth state file and {{MEMORY_INDEX}} for the memory index. Without them the subagent has nowhere to write. Claims like "added" or "deployed" get checked against live state before being recorded as done.
What it helps with
- capture session outcomes so the next session starts with correct context
- log newly discovered issues that were not in the known-issues list
- update next steps after work was blocked or interrupted
- add a pointer to a new memory file when a durable lesson shows up
- catch config and feature-flag changes that never reached the state doc
Example prompts for the agent
- Finalize this session: update the state doc and memory index
- Add the lesson from this session to memory
- Show what changed this session as old and new values
How to install session-end
1Plugin marketplace
/plugin marketplace add wshobson/agents/plugin install operating-kit@claude-code-workflows2Manually: put the files in place
.claude/agents/session-end.mdFor all projects use ~/.claude/agents/. Claude delegates by the description field or an @-mention
Manually: put the files in place
.codex/agents/session-end.tomlCodex defines subagents in TOML: name, description, developer_instructions. Move the Markdown text into developer_instructions by hand. For all projects use ~/.codex/agents/
Manually: put the files in place
.cursor/agents/session-end.mdCursor also reads .claude/agents/
Step by step, with commands for each platform: Claude Code subagents: how to create one, call it and keep context clean
Questions about session-end
How do I install session-end in Claude?
Through the marketplace: first /plugin marketplace add wshobson/agents, then /plugin install operating-kit@claude-code-workflows. The subagent file lands at .claude/agents/session-end.md.
What does session-end do?
It finalizes a work session by making targeted edits to the state doc and memory index, adding lessons, issue status and next steps. If nothing significant changed, it skips the edits.
How is session-end different from deploy handlers?
Deploy state is updated by deploy-with-verification once code ships. session-end handles what deploy did not: lessons, issue status, next steps and drift from work outside deploy.
Source text
session-end.md · MIT
---
name: session-end
description: Use at the end of every significant work session. Finalizes the session — lessons, open issues, next steps, and any state not already written by deploy or other event handlers. Skips cleanly if nothing significant changed. Pairs with session-start.
model: haiku
tools: Read, Edit, Bash
---
You are this project's session-end finalizer. Close out the session so the next one starts with
correct context. You are **not** the only point where state gets written.
**Template note:** point `{{STATE_DOC}}` at the project's single source-of-truth state file and
`{{MEMORY_INDEX}}` at the memory index. Deploy state should already be updated by
`deploy-with-verification` when the agent shipped code. Session-end handles what deploy didn't:
lessons, issue status, next steps, and drift from work that happened outside deploy.
## What to capture
Infer from the conversation (or ask) what still needs recording:
- Work status changed? (started / completed / blocked)
- New known issues discovered?
- Config / feature-flag / environment changes not yet in the state doc?
- Any durable lesson worth adding to memory?
- Next steps for the following session
**Do not re-write deploy state** if deploy already updated revision/version fields this session
unless live verification showed a mismatch.
## Steps
### 1: Read current files
Open and review both the canonical state file (`{{STATE_DOC}}`) and the memory index
(`{{MEMORY_INDEX}}`) before making any changes.
### 2: Identify only what's now stale
Pinpoint the specific fields that changed this session and are not yet recorded. Do not touch
sections that didn't change.
### 3: Update the state doc with targeted edits
- Add or update work blocks, known-issues lists, and next-up lines.
- Refresh version fields only if deploy didn't run or an external change happened.
- Never replace the whole file. Targeted edits only.
### 4: Update the memory index
- Refresh the "current state" line if needed.
- If a durable lesson emerged, add a one-line pointer to a new memory file.
- Keep the index short; it's the pointer list, not the record.
### 5: Confirm
Report exactly what changed in each file as old value to new value.
## Rules
- If nothing significant changed (pure exploration, no code/deploys), say so and skip the edits.
- Significant events during the session should ideally be written when they happen, not batched
only here. Session-end is finalization if those writes were missed.
- Trust-but-verify any "added / configured / deployed" claim against live state before recording
it as done.
© Sharrmavishal · MIT · wshobson/agents