agentleFS
dakldakl/engram/.claude/skills/dream/SKILL.md

dream

Skill2 starsChanged 5 months agoMITView on GitHub

Scheduled memory maintenance for Engram — verify the highest rot-risk memories, confirm the ones that still hold, and supersede the ones reality has moved past. Maintenance only; never summarizes or merges memories. Runs safely as a dry-run by default; pass `--apply` to write changes. Intended to run nightly via /schedule.

41 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use ingest, resume and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • JaimeGBASkill

    ingest

    Digest an external source (article, paper, transcript, URL, book chapter) and integrate its content into the knowledge base

    Also in 4 projects that use this

  • genomewalkerSkill

    resume

    Resume a thread by loading its ~800-token context capsule

    Also in 3 projects that use this

  • MicrosoftSkill

    init

    Also in 4 projects that use this

  • Hugging FaceSkill

    simplify

    Refactor code after tests pass. The "Refactor" phase of Red-Green-Refactor.

    Also in 3 projects that use this

  • AnthropicSkill

    start

    Set up your bio-research environment and explore available tools. Use when first getting oriented with the plugin, checking which literature, drug-discovery, or visualization MCP servers are connected, or surveying available analysis skills before starting a new project.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    reflect

    Learning capture system that extracts HIGH/MED/LOW confidence patterns from conversations to prevent repeating mistakes. Use after user corrections ("no", "wrong"), praise ("perfect", "exactly"), or when discovering edge cases. Complements .squad/agents/{agent}/history.md and .squad/decisions.md.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 40 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    If you can determine the corrected fact from the repo, in --apply mode supersede it: engram supersede <id> "<corrected markdown fact>" …

    line 29
  2. Distinctive:

    Always end with a digest (printed, never stored as a memory):

    line 50
  3. Very specific:

    Maintenance only: Never rewrite a memory into a summary, never merge or cluster memories.

    line 64
  4. Very specific:

    Run nightly via /schedule (e.g.

    line 70

“Common” is measured: kept by at least 6 in 10 of the 40 edited versions of this file we could read. “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

Maintain the Engram memory store: surface and fix rot, without ever summarizing or clustering memories (that is what slopped the prior system — see ADR 0008). Default is a dry-run that mutates nothing and just reports; only --apply writes changes.

1. Pull the riskiest candidates

engram list --by-risk --limit ${LIMIT:-20} --json

Rot-risk already excludes userConfirmOnly/timeless (they score 0), so you only see machine-checkable memories.

2. Deterministic verdicts first (cheap, no LLM)

engram verify --json

Match verdicts to the candidates by id. Verdicts: confirmed | contradicted | stale | inconclusive.

3. Act on each candidate

  • confirmed → it still holds. In --apply mode: engram verified <id> (bumps verified_at, lowers its future risk).
  • contradicted (e.g. the checkAnchor file is gone) → reality moved.
    • If you can determine the corrected fact from the repo, in --apply mode supersede it: engram supersede <id> "<corrected markdown fact>" --reason "<what changed>" --tags <tags> --source <repo>.
    • High-certainty contradiction with no replacement — the checkAnchor is gone AND the thing the memory describes no longer exists, so there's nothing to supersede it with: in --apply mode soft-delete it with engram delete <id>. This is the ONLY case /dream deletes, and delete is a recoverable tombstone (the row is kept), so it's safe. If you're unsure whether a replacement exists → do NOT delete; digest it.
    • Otherwise (fix unclear) → add to the review digest (don't guess).
  • stale (old as of <date>) → treat like contradicted: supersede if you can refresh it, else digest it.
  • inconclusive → escalate to a subagent (see §4) only if it has a checkAnchor; otherwise leave it and digest it.

4. Escalate inconclusive by FALSIFICATION

For each inconclusive memory with a checkAnchor, spawn a subagent (Task) whose job is to disprove the memory — not confirm it. Give it the memory content + checkAnchor + its source repo, and instruct: "Find concrete evidence this is now FALSE (run the checkAnchor grep/command, read the file). Report DISPROVED + the corrected fact, CONFIRMED + the evidence, or UNKNOWN."

  • DISPROVED → (--apply) engram supersede with the corrected fact.
  • CONFIRMED → (--apply) engram verified <id>.
  • UNKNOWN → leave it; add to the digest.

A falsification prompt resists the rubber-stamping a "prove it's still true" prompt invites.

5. Report a digest

Always end with a digest (printed, never stored as a memory):

  • confirmed/re-verified: N
  • superseded: N (old → new, with reason)
  • soft-deleted (high-certainty contradiction, recoverable): N
  • needs your review — for each memory that couldn't be auto-resolved, show its verdict + why and offer the three actions: keep (it's still fine — I'll engram verified it), update (give me the new fact — I'll engram supersede), or drop (engram delete, recoverable). Nothing in this list is touched until you choose.

In dry-run (the default) the digest describes what would happen; nothing is written. Tell the user to re-run with --apply to enact it.

Hard rules

  • Maintenance only. Never rewrite a memory into a summary, never merge or cluster memories. The only writes are engram verified and engram supersede.
  • Supersede, don't delete. History is preserved via superseded_by + evolution_reason.
  • Operate on the shared store (no --env).

Scheduling

Run nightly via /schedule (e.g. a routine that invokes /dream --apply at a quiet hour). Start with dry-run runs until you trust its supersede decisions.

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.