session-lifecycle

A guide to the lifecycle of ShipIt sessions, which are separate workspaces where coding-agent tasks run.

In plain words
What is it for?
Use it when implementing session creation, warm-session pools, activation, switching, repository-backed sessions, or session cleanup logic.
Why use it?
It explains how sessions are created, prepared in advance, activated, switched, and eventually finished, reducing confusion when managing different workspaces and repositories.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/nikzlabs/shipit/session-lifecycle
Any agent
npx skills add nikzlabs/shipit --skill session-lifecycle
Clone the repo
git clone --depth 1 https://github.com/nikzlabs/shipit

Made for: Claude Code, Codex.

Per session 49 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 3,358 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00049 $0.03358
Opus 5 $0.00024 $0.01679
Sonnet 5 $0.00010 $0.00672
Haiku 4.5 $0.00005 $0.00336

Measured 3d ago against content hash adb81948b6a2, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

session-lifecycle scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/session-lifecycle/SKILL.md · 296 lines

How it starts

The opening of the file, as written. The whole thing — 296 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Session Lifecycle

This skill covers session creation, warm-up, activation, switching, and graduation. For container/runner infrastructure, see the session-containers skill.

Key Components

Component Location Role
SessionManager orchestrator/sessions.ts Persists session metadata (title, workspace dir, remote URL, warm flag) to JSON
SessionRunnerRegistry orchestrator/session-runner.ts App-level map of session ID -> runner. Fires onRunnerIdle callback for container cleanup
SessionRunnerInterface orchestrator/session-runner.ts Abstract contract: agent state, message queue, viewer count, preview
RepoStore orchestrator/repo-store.ts Tracks imported repos, clone status, warm session IDs

Session Types

  1. Standalone session — no repo, fresh git repo initialized in the session directory. Created via POST /api/sessions.
  2. Repo-backed session — its own independent local clone cut from the per-remote bare cache (git clone --local, hardlinked objects), checked out on a unique branch off the default branch. Created via warm pool or claim-session.
  3. Warm session — a repo-backed session pre-created in the background: clone-from-cache + metadata plus, where there is idle headroom, a pre-booted standby container. Invisible in the sidebar until the user sends their first message ("graduated"). Where no standby exists, the container is created on-demand when the WebSocket connects. A warm session never survives an orchestrator restart — see "Restart" below.

Session Creation

Path A: Standalone Session (no repo)

Client                          Server
  |                               |
  +- POST /api/sessions ---------> createSessionDir(title)
  |  {title}                      |   mkdir sessions/{uuid}
  |                               |   git init
  |                               |   configure credentials
  |                               |   sessionManager.track()
  |                               |   threadManager.init()
  |<- {sessionId, sessionDir} -----
  |                               |
  |  store pendingWsMessage       |
  |  navigate(/session/{id})      |
  |                               |
  |  useSessionWebSocket opens    |
  +- WS /ws/sessions/{id} -------> activateSession(id)
  |                               |   runnerRegistry.getOrCreate()
  |                               |     -> factory creates container
  |                               |   attachToRunner()
  |                               |
  |  useConnectionSync fires      |
  +- GET /api/sessions/{id}/history -> returns messages, commits, etc.
  |                               |
  |  send pendingWsMessage        |
  +- WS send_message ------------> handleSendMessage()
  |                               |   POST /agent/start to worker
  |<- WS streaming events ---------

Read the full file on GitHub · 296 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 296 lines · 49 tokens per session scan A adb81948b6a2

Subscribe to this mod's changes

session-lifecycle is a skill published in the GitHub repository nikzlabs/shipit (6 stars, last pushed 3d ago), licensed Apache-2.0. It adds 49 tokens to every session and 3,358 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

lanes-sessions

Use when managing Lanes issues or driving Claude Code sessions through the lanes MCP tools — creating issues, starting/stopping/inspecting sessions, batch-launching work across worktrees, reading terminal output, attaching labels and components by UUID, or moving issues across the backlog/todo/in-progress/done…

lanes-sh/app · 99 tokens

lanes-forms

Use when the user wants a form backend or contact form set up (a live POST endpoint that captures submissions and emails them), OR wants an agent to fill in / submit to a form on their behalf. Lanes Forms creates and manages hosted form endpoints from Claude Code. Triggers on "set up a contact form", "provision a…

lanes-sh/app · 105 tokens

github-lanes-bridge

Use when bridging GitHub and Lanes — importing GitHub issues into Lanes for local Claude Code execution, batch-spawning sessions per ticket, decomposing one GitHub issue into multiple Lanes sub-issues with dependencies, or posting session results (PR links, comments, follow-up issues) back to GitHub. Triggers on…

lanes-sh/app · 161 tokens

linear-lanes-bridge

Use when bridging Linear and Lanes — importing Linear issues into Lanes for local Claude Code execution, batch-spawning sessions per Linear ticket, decomposing one Linear issue into multiple Lanes sub-issues with dependencies, or posting session results (PR links, comments, status updates) back to Linear. Triggers on…

lanes-sh/app · 142 tokens

security-ownership-map

Analyze git repositories to build a security ownership topology (people-to-file), compute bus factor and sensitive-code ownership, and export CSV/JSON for graph databases and visualization. Trigger only when the user explicitly wants a security-oriented ownership or bus-factor analysis grounded in git history (for…

HKUDS/DeepCode · 99 tokens

code-assist

Guides implementation of code tasks using test-driven development in an Explore, Plan, Code, Commit workflow. Acts as a Technical Implementation Partner and TDD Coach — following existing patterns, avoiding over-engineering, and producing idiomatic, modern code.

mikeyobrien/ralph-orchestrator · 53 tokens