Skill detail
nemo-rl-session-memory
Manage durable working-session memory for coding agents. Use when a user asks to preserve or recover agent context across disconnects, VS Code restarts, long-running work, handoffs, or any session where important state should be written periodically under the repo's session directory. Do NOT use…
Why we recommend it: Durable session memory for coding agents across VS Code restarts, adjacent to VS Code agent workflow.
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
--- name: nemo-rl-session-memory license: Apache-2.0 description: "Manage durable working-session memory for coding agents. Use when a user asks to preserve or recover agent context across disconnects, VS Code restarts, long-running work, handoffs, or any session where important state should be written periodically under the repo's session directory. Do NOT use for: simple questions, short tasks, one-off commands, linting, or code review." when_to_use: Preserving or recovering coding-agent context; creating checkpoints for long-running work, handoffs, disconnects, VS Code restarts, branch switches, or nontrivial edits. --- # Session Memory Keep a durable, human-readable record of the current working session so another agent can resume after a disconnect with minimal context loss. ## When To Use Use this skill when: - The user asks to preserve, recover, checkpoint, or manage agent memory. - Work is long-running, experimental, or likely to span disconnects. - You are about to make nontrivial edits, run long jobs, switch branches, or pause for user input. - You resume in a repo that already has `./session/` directories. ## Session Directory Create one directory per working session: ```bash mkdir -p session date +%Y%m%d_%H%M%S mkdir -p session/<session_date_time> ``` Use local time from the machine. Reuse the same session directory for all checkpoints in the same conversation unless the user explicitly starts a new session. Expected files: - `session_state.md` - overall goal, current subtask, loaded skills, status, plan, assumptions, blockers, and next actions. - `timeline.md` - append-only log of major actions, commands, results, and decisions. - `files.md` - files inspected, files changed, and why they matter. - `handoff.md` - concise resume instructions for the next agent. Add other files only when useful, such as `experiments.tsv`, `review_notes.md`, or copied command logs. ## Start Or Resume At the start of a session: 1. Check for existing session directories: ```bash ls -dt session/* 2>/dev/null | head ``` 2. If the user is resuming work, read the latest relevant `session_state.md`, `timeline.md`, and `handoff.md`. 3. If no relevant session exists, create a new timestamped directory. 4. Write an initial `session_state.md` with the user's overall goal, current subtask, loaded skills, repo path, branch, and known constraints. Do not treat session notes as the only source of truth. Verify important claims against git state, files, and command output before acting. ## Checkpoint Rhythm Write a checkpoint: - After gathering enough context to form a plan. - Before and after meaningful code edits. - Before long-running commands, experiments, branch switches, or anything hard to reconstruct from chat. - When the user changes direction. - Before final response if the session has meaningful state worth resuming. - At least every 30 minutes during active long-running work. Prefer updating the same files rather than creating many small checkpoint files. Keep the record compact and scannable. ## File Templates ### `session_state.md` ```markdown # Session State - Session: <session_date_time> - Repo: <absolute repo path> - Branch: <branch name> - Started: <local timestamp> - Updated: <local timestamp> ## Goal <Stable overall user goal in one or two sentences. Preserve this across follow-up steering unless the user explicitly changes it.> ## Current Subtask <Immediate task or steering request currently being handled.> ## Loaded Skills - `<skill-name>` - <why it was loaded and any important instructions to preserve.> ## Current Status <What is true now. Include completed work and verification status.> ## Plan - [ ] <Next concrete step> - [ ] <Next concrete step> ## Assumptions - <Assumption and how to verify it if needed.> ## Blockers - <Blocker or "None known".> ``` ### `timeline.md` ```markdown # Timeline ## <local timestamp> - User asked: <brief request> - Context gathered: <files/commands and key result> -Read the full source on GitHub (opens external page)