autodream
Skill1 starsChanged 4 months agoMITView on GitHub
Harvest replayable know-how from the current session into the file-based memory, then consolidate the whole store — prune superseded entries, merge duplicates, and re-verify stale claims against the real repos and cluster. Use this skill at the end of a working session, or whenever the user says "autodream", "consolidate memory", "save what we learned", "remember how we did this", "clean up my memory", "what's stale in memory", or asks why a new session did not know something an old session figured out. Also use before a long compaction, or when a recalled memory turns out to contradict reality.
In this repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architecture-auditSkill
- deep-discoverySkill
- generic-by-designSkill
- gitops-cd-developerSkill
- gitops-pipeline-developerSkill
- golang-script-developerSkill
- humanizerSkill
- information-architectureSkill
- interactive-deck-builderSkill
- javascript-script-developerSkill
- linux-script-developerSkill
- makefile-script-developerSkill
- plan-interviewSkill
- pre-commit-setupSkill
- python-script-developerSkill
- qaSkill
- skill-builderSkill
- teacher-modeSkill
- terraform-module-developerSkill
- typescript-script-developerSkill
- ui-deslopSkill
- xquik-x-dataSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
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 39
Before writing anything, list what exists and grep for the topics you are about to record.
- Distinctive: line 137
When a claim proves false, fix the entry and name it in the report.
- Distinctive: line 140
Never delete for being unverifiable — mark it unverified.
≈ “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
AutoDream
Three jobs, in order. Orient so you don't write a duplicate. Harvest so a cold session can replay what this one worked out. Consolidate so the store stays honest — memory that lies is worse than memory that is missing, because it gets trusted and acted on.
Memory lives at ~/.claude/projects/<project-slug>/memory/, one fact per file,
plus MEMORY.md — the index that loads into every new session. Frontmatter types
are fixed: user | feedback | project | reference. Do not invent types;
playbooks are reference with a playbook- filename prefix.
Phase 0 — Orient
Before writing anything, list what exists and grep for the topics you are about to record. Updating a near-duplicate beats adding one.
M=~/.claude/projects/<slug>/memory
find $M -name '*.md' -not -name MEMORY.md -printf '%f\n' | sort
for kw in <topic> <topic>; do printf '%-20s ' "$kw:"; grep -rli "$kw" $M/*.md | xargs -r -n1 basename | tr '\n' ' '; echo; donePhase 1 — Harvest
Record only what a future session could not cheaply re-derive. Nothing that
is already plain from the code, git history, or CLAUDE.md.
Four things qualify:
- A procedure that worked — the real command sequence, in order, plus the check that proved it. Not "bumped the chart" but the targeted plan, the apply, and the assertion that confirmed it.
- A trap — symptom first. A future session searches by symptom, so lead with
it: "plan reports
Invalid expressionpointing at a comment line" beats "escape dollar signs". - A decision, plus why the alternative lost. Otherwise the next session
re-litigates it, or silently picks the rejected option. Record the rejected
option explicitly as
Do NOT. - A correction the user made —
feedbacktype, with the why.
Playbook shape (playbook-<slug>.md, type: reference):
---
name: playbook-<slug>
description: <one line — how to do X, and the trap that breaks it>
metadata:
type: reference
---
**Goal:** <what this achieves>
**Preconditions:** <repo, branch, context, creds that must be true first>
1. <command> — <what it proves or changes>
**Verify:** <the check, with the expected output>
**Traps:** <symptom → cause → fix>
**Do NOT:** <the approach that looks right and fails, and why>Then add one MEMORY.md line: - [Title](file.md) — hook. The hook is the
whole retrieval mechanism — it is often all a future session sees. Lead with
the symptom or the task, never the tooling. "port 465 fails by hanging" is
findable; "SMTP configuration notes" is not.
Phase 2 — Consolidate
Five passes over every file:
- Contradiction — two entries asserting different things. Resolve by checking reality, not by preferring the newer file.
- Supersession — rewrite to current state and say what it replaced; delete only if no residual value.
- Duplication — merge into the better-named entry, update
MEMORY.md, repoint[[links]]. - Staleness — verify, per the discipline below.
- Hygiene — relative dates become absolute; dangling
[[links]]get written or dropped; index matches disk.
Index integrity is mechanical, so check it mechanically:
cd $M
find . -maxdepth 1 -name '*.md' -not -name MEMORY.md -printf '%f\n' | sort > /tmp/d
grep -oE '\]\([a-z0-9-]+\.md\)' MEMORY.md | tr -d '](' | sed 's/)//' | sort > /tmp/i
echo "unindexed: $(comm -23 /tmp/d /tmp/i | wc -l) orphans: $(comm -13 /tmp/d /tmp/i | wc -l)"Verification discipline
A memory asserting a file, flag, or constraint exists is a hypothesis. Check the cheap ones: does the path exist, is the key still in the file, does the read-only query return it.
Three rules learned the hard way:
- Verify in the repo the claim names, and confirm you are in it. A negative
grep means "wrong target" at least as often as "claim is false". This skill's
own first run grepped
<network-infra-repo>for a bug that actually lived in<identity-infra-repo>, and nearly recorded a live defect as fixed. Print the path you searched alongside the result. - Don't restate counts or lists from recall — derive them. The same run asserted "five SSO clients" from memory; parsing the values file confirmed the count but corrected which entry the fifth one was.
- An observed behaviour in memory beats a claim in skill or plugin docs. Docs
go stale and nobody notices. When they conflict, trust the memory that records
what actually happened, note the conflict in the entry, and say so in the
report. On 2026-07-26 a memory had correctly recorded since 2026-07-05 that
pushing to
mainworks; two skill docs claimed it was protected; the docs were believed and a whole session of needless branch-and-PR ceremony followed.
When a claim proves false, fix the entry and name it in the report. A silently corrected memory teaches nothing.
Never delete for being unverifiable — mark it unverified. Delete only what is demonstrably wrong or fully superseded.
Safety gates
Both are mandatory before finishing.
- No credential material, ever. Reference where it lives (secrets-manager
entry name, K8s Secret name), never the value. Verify:
grep -rlE '<key-pattern>|<known-secret-fragment>' $M/*.md && echo LEAK || echo clean - No duplication of what the repo already states — no code structure, no
restating
CLAUDE.md.
Memory is the user's notes: rewrite content freely, but every deletion and every corrected claim goes in the report.
Report
Close with counts of added / updated / merged / deleted, then the section that matters most: claims that turned out to be wrong, including your own from this run. If that section is empty, say so explicitly — it means either a clean store or a shallow verification pass, and the user should know which.
Automation
A skill only runs when invoked; it cannot fire on its own at session end. The
useful hook is PreCompact, which fires while the transcript is still in context
— the one moment harvesting is possible without being asked. See
references/automation.md. Never edit the user's settings.json unprompted.
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.

