agentleFS
mikeyobrienmikeyobrien/rho/skills/auto-memory/SKILL.md

auto-memory

Skill372 starsChanged 8 months agoMITView on GitHub

Extract durable learnings and preferences from conversations for automatic memory capture.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If there are no genuinely new, durable items to extract, return:

    line 112
  2. Distinctive:

    Prefer updating/superseding existing memories over adding new similar ones

    line 194

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Auto-Memory Extraction

Overview

Extract durable learnings and user preferences from a conversation that will remain useful across future sessions. This runs automatically after each agent turn, using a small/cheap model. Quality over quantity: one precise memory is worth more than five vague ones.

Parameters

  • conversation (required): The serialized conversation text to extract from
  • existing_memories (optional): Already-stored memories to avoid duplicating

Steps

1. Classify Conversation Content

Scan the conversation and classify each substantive exchange into one of these categories:

Extractable:

  • Final decisions (user confirmed or explicitly chose something)
  • Corrections (user said "no, do X instead" or "that's wrong")
  • Stated preferences ("I prefer X", "always do Y", "don't use Z")
  • Discovered facts about the environment, tools, or APIs that were verified
  • Patterns that were tested and confirmed working
  • Bug fixes with root causes identified

Not extractable:

  • Intermediate discussion before a decision was reached
  • Options that were considered but rejected
  • Transient states ("GitHub is down right now")
  • Obvious facts any model would know
  • One-off task details ("fix the bug on line 42")
  • Anything the user explored but didn't commit to
  • Version numbers or update confirmations ("updated X to v1.2.3")
  • Heartbeat or check-in status reports ("Heartbeat Feb 19: all clear")
  • Benchmark scores or run results ("scored 42/89 = 47.2%")
  • Bug sweep summaries without a generalizable root cause ("reviewed X, no bugs found")
  • UI/feature implementation details ("button text changed to X", "layout uses 3 columns")
  • Task completion status ("task X is complete", "run Y failed")
  • Project-specific state that won't inform future decisions

Constraints:

  • You MUST only extract from the "extractable" category
  • You MUST apply the 30-day test: "Would this change a decision I make 30 days from now?" If no, do not extract it. Most conversations produce zero durable knowledge — that's fine.
  • You MUST NOT extract intermediate discussion states as settled facts because conversations explore options before deciding, and capturing exploration as truth produces wrong memories
  • You MUST NOT extract transient information (outages, temporary workarounds, "currently broken") because these become stale and misleading
  • You MUST prefer the final state of a decision over earlier states because users change their mind during conversations

2. Check Against Existing Memories

Compare each candidate extraction against the existing memories list.

Constraints:

  • You MUST NOT extract anything that restates, overlaps with, or is a subset of an existing memory
  • You MUST NOT extract a weaker version of something already stored (e.g., don't store "use ripgrep" if "Always use ripgrep instead of grep for searching" already exists)
  • You SHOULD flag when a new extraction contradicts an existing memory — extract the new one with updated information, as it represents a more recent decision
  • You MUST NOT extract more than 1 item total per conversation — force yourself to pick only the single most valuable extraction, or nothing. Most conversations should produce nothing.

3. Draft Extractions

For each valid candidate, draft a concise memory entry.

Constraints:

  • You MUST write each entry as a specific, actionable statement — not a summary of what happened
  • You MUST keep entries under 300 characters unless additional context is essential for future usefulness
  • You MUST use the final decided form, not the discussion form
    • Bad: "User discussed whether to use the rho tmux config or keep the current one"
    • Good: "Rho tmux config swapped in as ~/.tmux.conf, replacing the nix-configs-based one"
  • You MUST NOT use vague language like "the user prefers better approaches" because it provides no actionable guidance
  • You SHOULD include the "why" when it's not obvious from the "what"
    • Good: "Use printf '%s' instead of echo for piping to jq — echo adds trailing newline"
    • Bad: "Use printf instead of echo"

4. Categorize

Assign each extraction a type and category.

Learning types:

  • Corrections, discovered patterns, environment facts, bug root causes, tool behaviors

Preference types with categories:

  • Communication: Voice, tone, formatting, emoji policy
  • Code: Style, patterns, conventions, architecture
  • Tools: Tool preferences, CLI flags, configuration
  • Workflow: Process, git, deployment, review practices
  • General: Anything that doesn't fit above

Constraints:

  • You MUST assign exactly one category per preference
  • You SHOULD default to "General" only when no other category fits

Output Format

Output strict JSON only:

{
  "learnings": [
    {"text": "concise, actionable learning statement"}
  ],
  "preferences": [
    {"category": "Communication|Code|Tools|Workflow|General", "text": "concise, actionable preference statement"}
  ]
}

If there are no genuinely new, durable items to extract, return:

{"learnings": [], "preferences": []}

Returning empty is better than returning noise.

Examples

Example 1: Decision After Discussion

Conversation excerpt:

User: "Should we source the rho tmux config or swap it in?" Agent: "Here are the differences... Want me to source it or swap it?" User: "swap it in" Agent: swaps the config

Good extraction:

{"learnings": [{"text": "Rho tmux config at ~/.rho/tmux.conf is now the active ~/.tmux.conf, replacing the nix-configs-based one. Old config backed up at ~/.tmux.conf.bak."}]}

Bad extraction (captures discussion, not decision):

{"learnings": [{"text": "The rho-specific tmux configuration is not being used by the current ~/.tmux.conf"}]}

Example 2: User Correction

Conversation excerpt:

Agent: drafts a formal, structured X post User: "do something more clever" Agent: drafts dry, self-aware version User: "I like that personality, do that more"

Good extraction:

{"preferences": [{"category": "Communication", "text": "X post voice: understated, self-aware, dry. State the problem, state what was done, land it flat. Let the reader connect the dots."}]}

Bad extraction (too vague):

{"preferences": [{"category": "Communication", "text": "User prefers clever X posts over formal ones"}]}

Example 3: Nothing Worth Extracting

Conversation excerpt:

User: "find recent X posts about rho and post something" Agent: searches, drafts, posts

Correct output:

{"learnings": [], "preferences": []}

The task was executed but no durable knowledge was produced.

Example 4: Tempting But Not Durable

These look like learnings but fail the 30-day test:

CandidateWhy it fails
"pi-coding-agent updated to 0.55.4 on 2026-03-04"Version snapshot — stale tomorrow
"Heartbeat Feb 19 08:02 UTC: rho-web healthy"Status report — not a decision or pattern
"ChefBench scored 42/89 = 47.2% on Terminal-Bench 2.0"Benchmark result — won't change future behavior
"Fresh-eyes bug sweep: reviewed X, no bugs found"Sweep status — no generalizable root cause
"The sessions hamburger button should use an icon-only button"UI detail — too specific to one feature
"All 224 unit tests pass with no failures"Test status — transient fact
"Task X is complete and verified"Completion status — belongs in task tracking, not memory

Correct output for all of the above:

{"learnings": [], "preferences": []}

Troubleshooting

Memory Growing Too Large

  • Return empty rather than extracting marginal items
  • Prefer updating/superseding existing memories over adding new similar ones

Contradicts Existing Memory

  • Extract the newer version — it represents a more recent decision
  • The memory system handles dedup and supersession separately

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.