AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Migrate Memory

skill-nanocoai-nanoclaw-migrate-memory · by nanocoai

Carry an agent group's memory across a provider switch, in either direction (e.g. Claude ↔ Codex, or any provider to/from another). Run after the operator switches a group's provider with `ncl groups config update --provider`. The coding agent reads the source provider's memory store, distills it into the target provider's store, and restarts the group. Triggers on "migrate memory", "carry memory…

No reviews yet
0 installs
2 views
0.0% view→install

Install

$ agentstack add skill-nanocoai-nanoclaw-migrate-memory

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-nanocoai-nanoclaw-migrate-memory)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
1mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Migrate Memory? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Migrate memory across a provider switch

NanoClaw does not migrate memory at runtime — each provider keeps its own store, and carrying content across is the operator's move, executed by you (the coding agent). This skill is the whole mechanism: read the source store, infer what is durable, write it into the target store, restart.

You translate between store shapes, not provider names. There are two:

  • Flat fileCLAUDE.local.md at the group workspace root (the Claude provider; may reference satellite files in the workspace).
  • Scaffold treememory/ (any provider with usesMemoryScaffold, e.g. Codex). memory/index.md is the index; durable notes live under memory/memories/; memory/memories/imported-agent-memory.md is the conventional landing file for imported memory.

A switch only needs migration when it crosses shapes. Two providers that both use the scaffold share the same memory/ tree, so switching between them carries nothing — the memory is already there. The work is always one of: flat → scaffold, or scaffold → flat.

Principles: copy, never move (the source store stays intact — it IS the rollback), idempotent (re-running must not duplicate), distill, don't dump (you are the inference step: keep identity/seed instructions, user preferences, durable facts; drop conversational residue).

Step 1: Identify the group, both providers, and the direction

  • ncl groups list, then ncl groups config get --id — note the current (target) provider. Ask the operator which group, and which provider it switched from, if either is ambiguous.
  • Map each provider to its store shape (flat CLAUDE.local.md vs memory/ scaffold), then inspect groups//:
  • Same shape on both sides (e.g. scaffold → scaffold) → the store is shared; nothing to migrate. Tell the operator and stop.
  • Flat → scaffold (source has CLAUDE.local.md content, target uses the scaffold) → Step 2.
  • Scaffold → flat (source has a memory/ tree, target is Claude) → Step 3.
  • Source missing or empty → nothing to migrate; tell the operator and stop.

Step 2: flat → scaffold (CLAUDE.local.mdmemory/)

  1. Read groups//CLAUDE.local.md and any workspace files it references.
  2. If memory/memories/imported-agent-memory.md already exists, a previous import happened — show the operator what's there and ask before overwriting; integrate only what's new.
  3. Distill the content into groups//memory/memories/imported-agent-memory.md (create the directories if missing — the container scaffolds the rest of the tree at boot and never clobbers your files). Lead with anything that defines who the agent is or how it must behave; references to satellite files keep their workspace-root paths.
  4. If memory/index.md exists, add the following: - [Imported agent memory](memories/imported-agent-memory.md) — seed instructions and memory carried over from a previous provider. Read it first and treat it as binding; it may define who you are and how to behave. Integrate its facts into your memory as you work; never modify files that belong to another provider's memory system.
  5. Leave the source store exactly as it is.

Step 3: scaffold → flat (memory/CLAUDE.local.md)

  1. Read memory/index.md, then the files it points to under memory/memories/ (and memory/data/ where durable).
  2. Integrate the durable facts into groups//CLAUDE.local.md under a clearly marked section (e.g. ## Imported from memory/ ()), deduplicating against what's already there. If the section already exists, update it instead of appending a second one.
  3. Leave the source store exactly as it is.

Step 4: Restart and verify

ncl groups restart --id 

Tell the operator to send the group a quick test message that depends on a migrated fact (a preference, a project name). If the agent doesn't know it, re-check that the target file landed in the right group folder.

Note: switching the provider is an operator action — ncl groups config update --id --provider from the host. See [docs/provider-migration.md](../../../docs/provider-migration.md) for what carries over automatically.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.