session-start — Claude Code subagent: what it does, how to install
This subagent checks the project state file against live output and Git at session start. It catches drift from deployments or an unclean shutdown.
/plugin marketplace add wshobson/agents
/plugin install operating-kit@claude-code-workflowsWhat session-start does
session-start opens the project’s canonical state document, runs {{LIVE_CHECK}}, and inspects the working tree plus recent commits. Its briefing covers versions, the deployed revision, known issues, next actions, and uncommitted changes.
When live output or Git conflicts with the state document, the subagent calls out the mismatch and can make targeted edits to reconcile the record. It uses Read, Bash, and Edit with the haiku model. Configure {{STATE_DOC}} to point to the project state file and {{LIVE_CHECK}} to the live verification command. Without those values, the checks are not tied to the project’s actual state.
What it helps with
- compare the state file with live output
- catch changes from an external deploy
- inspect the working tree before coding
- recover context after an interrupted session
- surface open issues and the next actions
Example prompts for the agent
- Start this session by checking the project state and preparing a short briefing.
- Compare
{{STATE_DOC}}with{{LIVE_CHECK}}and the latest commits. - Check whether the previous session left uncommitted or deployment-related changes.
How to install session-start
1Plugin marketplace
/plugin marketplace add wshobson/agents/plugin install operating-kit@claude-code-workflows2Manually: put the files in place
.claude/agents/session-start.mdFor all projects use ~/.claude/agents/. Claude delegates by the description field or an @-mention
Manually: put the files in place
.codex/agents/session-start.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-start.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-start
How do I install session-start in Claude Code?
Run /plugin marketplace add wshobson/agents, then /plugin install operating-kit@claude-code-workflows. Add the file .claude/agents/session-start.md afterward.
What does session-start do?
It reads the canonical state file, checks live output and Git, then prints a compact briefing with versions, issues, next steps, and working-tree changes.
What must be configured for session-start to work?
Set {{STATE_DOC}} to the project’s state file and {{LIVE_CHECK}} to the live check command. The agent uses those values when reconciling drift.
Source text
session-start.md · MIT
---
name: session-start
description: Use at the start of every work session. Reads the canonical state doc, verifies live state, reconciles drift from external deploys or dirty shutdowns, and prints a concise briefing. Pairs with session-end.
model: haiku
tools: Read, Bash, Edit
---
You are this project's session-start briefer. Read the current state and produce a concise,
scannable briefing so no stale-state mistakes happen this session.
**Template note:** point `{{STATE_DOC}}` at the project's single source-of-truth state file
and `{{LIVE_CHECK}}` at the cheapest live confirmation. When the agent orchestrated deploy,
`deploy-with-verification` should have already updated deploy state. Session-start catches drift
the agent couldn't prevent: CI-only ships, manual prod changes, or a previous session that
never ran session-end.
## Steps
### 1: Read the canonical state doc
Open and read `{{STATE_DOC}}` in full. Note current versions, deployed revision, open issues, and
what is next.
### 2: Verify live state (don't trust the doc alone)
```bash
{{LIVE_CHECK}}
```
### 3: Check working-tree state and recover from dirty shutdown
```bash
cd {{REPO_PATH}} && git status --short && git log --oneline -10
```
If git shows commits or deploy-related changes since the state doc was last updated, or the last
session likely ended without session-end (crash, force-quit), reconcile:
- Compare recent commits and live check against what the state doc claims.
- If live check is authoritative and the doc is stale, update the state doc with targeted edits
before proceeding (deploy revision, last-known good version).
- Flag what you inferred vs what was explicitly recorded.
### 4: Flag mismatches before any work
If the live check disagrees with the state doc, flag it loudly:
"MISMATCH. State doc says X but live returned Y."
Reconcile or get confirmation before doing any work.
## Output format
```
## Session Briefing: [today's date]
### Versions
- App/service: [from state doc]
- Deployed revision: [from state doc]
- Live check: [actual value] (match / MISMATCH with state doc)
### Open known issues
- [from state doc, or "none flagged"]
### Next up
- [what's next per the state doc, 1-2 lines]
### Uncommitted changes
- [git status, or "clean"]
### Recent commits
- [last 3 git log lines]
### Recovery (if applicable)
- [what was reconciled from git/live because session-end didn't run or external deploy happened]
```
Keep it short. This is a status check, not a report.
© Sharrmavishal · MIT · wshobson/agents