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 for: simple questions, short tasks, one-off commands, linting, or code review.

nvidia/skills1.9k installsApache-2.0Synced Aug 27

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
name: nemo-rl-session-memory
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.
license: Apache-2.0
---

# 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>
- Decision: <important choice and rationale>
- Result: <edits/tests/outcome>
```

### `files.md`

```markdown
# Files

## Inspected
- `<path>` - <why it mattered>

## Changed
- `<path>` - <what changed and why>

## Generated
- `<path>` - <purpose>
```

### `handoff.md`

```markdown
# Handoff

## Resume From Here
<One paragraph summary of the current state.>

## Next Actions
- <Most important next action>
- <Verification or cleanup still needed>

## Watch Outs
- <Risks, user preferences, or repo constraints the next agent must preserve.>
```

## Recovery Workflow

When resuming after a disconnect:
1. Find the likely latest session directory.
2. Read `handoff.md` first, then `session_state.md`, then recent `timeline.md`.
3. Run lightweight verification such as `git status --short`, `git branch --show-current`, and targeted file reads.
4. Continue from the latest verified next action.
5. Append a timeline entry noting the recovery and any mismatches found.

## Quality Rules

- Keep notes factual and terse. Future agents need state, not a transcript.
- Record command outcomes that matter, especially failed tests or skipped verification.
- Mention uncommitted changes and whether they were made by the current agent or pre-existing.
- Do not store secrets, tokens, private credentials, or large logs in session files.
- If a session file becomes large, summarize old details and keep the latest next actions near the top of `handoff.md`.

More Code Review skills

pr-to-video

heygen-com/hyperframes

Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.

178.9k

receiving-code-review

obra/superpowers

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

178.0k

public-relations

coreyhaines31/marketingskills

When the user wants help with public relations, earned media, press coverage, journalist outreach, or media strategy (not pull requests). Also use when the user mentions 'PR,' 'public relations,' 'press,' 'press release,' 'press coverage,' 'media outreach,' 'pitch a journalist,' 'get featured,' 'media list,' 'media kit,' 'press kit,' 'newsjacking,' 'news hijack,' 'HARO,' 'Qwoted,' 'Featured,' 'Help A Reporter,' 'reporter request,' 'tech press,' 'TechCrunch,' 'earned media,' 'thought leadership placement,' 'op-ed,' 'guest article,' 'press contacts,' 'podcast prep,' 'going on a podcast,' 'podcast guest,' 'prep me for this podcast,' or 'how do I get press.' Use this for earned media work — finding journalists, pitching stories, newsjacking, prepping podcast appearances, and responding to press requests. For startup/SaaS/AI directory submissions, see directory-submissions. For product launches, see launch. For social-media engagement, see social. For cold-email outreach to prospects, see cold-email.

33.1k

← All Code Review skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY