From mf
Consolidate the current session's progress into the project's auto-memory directory — the "log everything, update state, prepare for resumption" drill. Use when the user says "log everything", "checkpoint", "save progress", "update memory", "dump state", or when a long session is about to end and context is saturated. Works on any project primed with /mf:prime; writes to the Claude Code auto-memory dir under ~/.claude/projects/<slug>/memory/.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mf:dumpThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Write the current session's non-derivable state to the project's auto-memory directory so a future session can resume cleanly. Idempotent: can run mid-session, at a natural checkpoint, or at end-of-session.
Write the current session's non-derivable state to the project's auto-memory directory so a future session can resume cleanly. Idempotent: can run mid-session, at a natural checkpoint, or at end-of-session.
git log, current code, or CLAUDE.md do not belong in memory.date -I if uncertain.Claude Code's auto-memory system lives at ~/.claude/projects/<slug>/memory/ where <slug> is the project's absolute path with every / replaced by -.
bash -c 'echo ~/.claude/projects/$(echo "$PWD" | sed "s|/|-|g")/memory'
The directory is usually already created by Claude Code. If not, create it before writing.
Confirm CLAUDE.md, SOUL.md, PROJECT.md exist in the project root (these are set up by /mf:prime). If any are missing:
/mf:prime from the project root./mf:prime silently — pre-existing files with the same name matter.Read <memory_dir>/MEMORY.md (the index) and the most recently modified files:
ls -lt <memory_dir>/*.md 2>/dev/null | head -10
Decide for each signal you want to log: does it belong in an existing file (preferred) or a new file (rare)?
Identify, in priority order:
Skip anything derivable from git log, the current code, or the primed config files.
Every memory file has YAML frontmatter with name, description, type. The four types:
project — ongoing work state, results, decisions, deadlines, pending experiments. High churn.feedback — behavioural guidance (both corrections and validated choices). Each entry: rule + Why: + How to apply:. Moderate churn.user — durable facts about the user's role, expertise, responsibilities. Low churn.reference — pointers to external systems (issue trackers, experiment trackers, dashboards, buckets). Low churn.Filename convention: <type>_<topic>.md (e.g. project_state.md, results_full_sweep.md, feedback_offline_vs_online.md, reference_wandb.md).
Update <memory_dir>/MEMORY.md with one line per entry:
- [Title](file.md) — one-line hook, under ~150 characters.
MEMORY.md has no frontmatter — it's an index, not a memory. For any file you updated or created, re-word its hook if the content shifted substantively.
Before writing: for any file you're about to modify, read it first to preserve load-bearing context. Duplication is a smell — if the same fact appears in two files, pick one canonical home and cross-reference.
If the session surfaced a general guideline or preference worth propagating to every future session on any project, propose an edit to:
SOUL.md at ~/.mindfunnel/SOUL.md — user traits, collaboration style, communication preferences.CLAUDE.md at ~/.mindfunnel/AGENTS.md (the CLAUDE.md symlink points there) — general engineering guidelines.Guardrails:
CLAUDE.md symlink directly — always edit the underlying AGENTS.md.If in doubt, skip. SOUL.md and CLAUDE.md churn creates noise.
End with a concise summary, ≤ 15 lines:
Memory dir: <path>
Updated:
- <file> — <one-line reason>
Created:
- <file> — <one-line reason>
Index (MEMORY.md): refreshed | unchanged
Proposed SOUL.md / CLAUDE.md edits: none | <one-line summary, pending approval>
If nothing was worth logging, say "no new signal; memory is current" and do nothing.
User says: "Log everything, the sweep results just came in."
Actions:
MEMORY.md exists; read it.project_state.md and results_*.md files.project_state.md with the new "where we are + next action".results_<experiment>_<date>.md if the sweep is a major dossier; otherwise append to an existing results file.MEMORY.md one-liner for each touched file.Result: One report block listing what was updated, memory ready for the next session.
User says: "Dump before I close."
Actions:
User says: "Log everything. That lesson about always verifying memory claims before citing them is something I want to keep."
Actions:
project_state.md and any results_*.md as usual.~/.mindfunnel/AGENTS.md under "Handling Existing Code" or "Autonomy and Asking".Symptom: Files land at an unexpected location, or Claude Code complains about an unknown memory dir.
Cause: The slug transformation doesn't match Claude Code's internal convention on this host.
Solution: Check with ls ~/.claude/projects/ — the current project's dir should appear. If absent, Claude Code hasn't indexed this project yet; create the dir manually with mkdir -p ~/.claude/projects/<slug>/memory and Claude Code will adopt it.
Symptom: Two memory files disagree on a number or decision.
Cause: A previous dump duplicated content instead of cross-referencing.
Solution: Pick the newer or more specific statement as canonical. Edit the other file to cross-reference the canonical one (See [results_foo.md](results_foo.md) for current numbers.). Note the consolidation in the final dump report.
Symptom: git log of the memory dir shows many small updates, many of them trivial.
Cause: The empty-dump guard is being skipped.
Solution: Skip the dump when the conversation contains only tool noise / small Q&A. Say "no new signal; memory is current" and do nothing. Memory is not a commit log.
Symptom: The user said "no" to a proposed general-guideline edit.
Cause: The insight wasn't actually general, or was contradicted by other contexts.
Solution: Accept the rejection, do not re-propose in the same session, and move the insight into a project-level feedback_*.md instead if it's still useful at the project scope.
project_state.md under a "Next actions" section, tied to a concrete command or decision.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub emaballarin/ccplugins --plugin mf