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
- zedarvates/frugal-skillstheir own version, first seen Nov 8, 2026
- zedarvates/botte-secretetheir own version, first seen Aug 8, 2026
- tractorjuice/arc-kittheir own version, first seen May 10, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- tractorjuice/arc-kit★ 2.3ksame name
- zedarvates/botte-secrete★ 2same name
- zedarvates/frugal-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- install-rhoSkill
- code-assistSkill
- codebase-summarySkill
- code-task-generatorSkill
- create-sopSkill
- evalSkill
- memory-consolidateSkill
- pdd-buildSkill
- pddSkill
- release-changelogSkill
- rho-cloud-emailSkill
- rho-cloud-onboardSkill
- session-searchSkill
- small-improvementSkill
- update-piSkill
- vault-cleanSkill
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
- Distinctive: line 112
If there are no genuinely new, durable items to extract, return:
- Distinctive: line 194
Prefer updating/superseding existing memories over adding new similar ones
≈ “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.
Files
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:
| Candidate | Why 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
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
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.

