autodream

name	autodream
version	1.0.0
description	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.
license	MIT
compatibility	claude-code opencode
allowed-tools	["Read","Write","Edit","Grep","Glob","Bash"]
metadata	{"author":"MKAbuMattar"}

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; done

Phase 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:

1. 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.
2. A trap — symptom first. A future session searches by symptom, so lead with it: "plan reports Invalid expression pointing at a comment line" beats "escape dollar signs".
3. 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.
4. A correction the user made — feedback type, 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:

1. Contradiction — two entries asserting different things. Resolve by checking reality, not by preferring the newer file.
2. Supersession — rewrite to current state and say what it replaced; delete only if no residual value.
3. Duplication — merge into the better-named entry, update MEMORY.md, repoint [[links]].
4. Staleness — verify, per the discipline below.
5. 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 main works; 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.

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

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