56 results available
Sign in
Skills directory

nemo-rl-session-memory

nvidia

·

Last changed
Hardened

This skill has been hardened by Chainguard

Last changed

This version passed the hardening gate. Hardening updated the skill content and independently checked the resulting changes. Classified findings before hardening: 2. Classified findings closed: 0. Classified findings remaining: 2. Unclassified scanner findings remaining: 0. Review findings closed: 1. Review findings remaining: 8.


Open before hardening

2

Medium
Open after hardening

2

Medium

Expand
File
Group
Subtype
Severity
Status
skill-card.md

Sensitive Data & Secret Exposure

Agent snooping

Medium
Open
BENCHMARK.md

Sensitive Data & Secret Exposure

Agent snooping

Medium
Open

2 findings


SKILL.md

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.

Session Directory

Create one directory per working session:

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:
ls -dt session/* 2>/dev/null | head
  1. If the user is resuming work, read the latest relevant session_state.md, timeline.md, and handoff.md.
  2. If no relevant session exists, create a new timestamped directory.
  3. 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

# 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

# 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

# Files

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

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

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

handoff.md

# 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.

Install

Install with chainctl
chainctl skill install public/nvidia/nemo-rl-session-memory:latest
Get started with chainctl
View source

Harden your own skills

Bring Chainguard's hardening pipeline to your first-party skills — custom rulesets, automated remediation, full audit trail.

Provenance

Upstream sourcehttps://github.com/nvidia/skills
Upstream commit6fb5c4ec2284422d80191c35f792c6554f3a37a1
OCI reference

skills.cgr.dev/public/github.com/nvidia/skills/nemo-rl-session-memory:latest

License

Apache-2.0

Files

BENCHMARK.md

HARDENING.md

LICENSE

SKILL.md

evals/evals.json

skill-card.md

skill.oms.sig


The trusted source for open source

Talk to an expert
PrivacyTerms

Product

Chainguard ContainersChainguard LibrariesChainguard VMsChainguard OS PackagesChainguard ActionsChainguard Agent SkillsIntegrationsPricing
© 2026 Chainguard, Inc. All Rights Reserved.
Chainguard® and the Chainguard logo are registered trademarks of Chainguard, Inc. in the United States and/or other countries.
The other respective trademarks mentioned on this page are owned by the respective companies and use of them does not imply any affiliation or endorsement.