Skip to main content
subagent CX Codex

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.

Install into Claude Code · Plugin marketplace All methods and platforms ↓
/plugin marketplace add wshobson/agents
/plugin install operating-kit@claude-code-workflows
Open on GitHub

What 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-workflows

2Manually: put the files in place

.claude/agents/session-end.md

For all projects use ~/.claude/agents/. Claude delegates by the description field or an @-mention

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

Similar subagents

All subagents for Agent setup: memory, context, orchestration →

From the same set342

The whole set →

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor