eai-org/agent-toolkit/skills/memory-doctor/SKILL.md
memory-doctor
Audit the current project's agent-memory and, block by block, relocate each entry into a user-controlled home (project doc/skill/rule or user-level skill/rule) or archive it — draining memory so nothing uncontrolled accumulates in the agent's context.
- Source repository stars
- 30
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-08-04
- Source checked
- 2026-08-04
Decision brief
What it does—and where it fits
Agent-memory is an unseen side-channel into every session's context window: facts accumulate there, often by accident, that the user never reviews and cannot govern. This skill drains it. Technically nothing should live in project memory — durable guidance belongs in homes the u…
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/eai-org/agent-toolkit --skill "skills/memory-doctor"Inspect the Agent Skill "memory-doctor" from https://github.com/eai-org/agent-toolkit/blob/f950517c4b09c5c3892f6dd43d58770a63f7b249/skills/memory-doctor/SKILL.md at commit f950517c4b09c5c3892f6dd43d58770a63f7b249. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Golden rule
The skill guesses and recommends; the user decides. Every verdict, scope, form, and target is a proposal the user confirms or flips. When unsure, ask. Nothing is moved, deleted, or written without explicit per-item approval. For every block the user gets the whole fixed menu — r…
The skill guesses and recommends; the user decides. Every verdict, scope, form, and target is a proposal the user confirms or flips. When unsure, ask. Nothing is moved, deleted, or written without explicit per-item appr… - 02
Locate the memory
Find the memory store for the current project. Its location is agent-specific — other agents store it elsewhere, or not at all. Claude Code example: slugify the project's absolute working-directory path by replacing each / with - and prefixing one -, then look for /.claude/proje…
Find the memory store for the current project. Its location is agent-specific — other agents store it elsewhere, or not at all. Claude Code example: slugify the project's absolute working-directory path by replacing eac…Block = the smallest self-contained memory unit — typically one memory file plus its MEMORY.md index line, generally one fact each, though a store may group differently. If the memory is a single flat file with no index… - 03
Flow
1. Scan (read-only). Read every block. To judge staleness you may read or grep project files, git, and governing docs — but make no mutation in this phase. 2. Triage table. Present all blocks as ONE narrow overview table that renders as a table, not a wrapped list: | block | con…
Scan (read-only). Read every block. To judge staleness you may read or grep project files,Triage table. Present all blocks as ONE narrow overview table that renders as a table, not aDecide, one question per block, in strict index order (1 → last). Walk blocks by their table - 04
Verdicts
Duplicate — already covered by an existing project/user skill, doc, or rule. Cite the
Duplicate — already covered by an existing project/user skill, doc, or rule. Cite theGarbage — delete-worthy: stale (cites code/files that no longer exist — verify byRelocate — genuine durable guidance with no current home. Route by scope × form (below). - 05
Routing for relocate (scope × form)
Both axes are proposals the user confirms or flips.
Scope — "would this be true or wanted in a different project too?" Yes → user-levelForm — short standing behavioral constraint → rule; multi-step procedure with a trigger →Both axes are proposals the user confirms or flips.
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 85/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 30 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- eai-org/agent-toolkit
- Skill path
- skills/memory-doctor/SKILL.md
- Commit
- f950517c4b09c5c3892f6dd43d58770a63f7b249
- License
- MIT
- Collected
- 2026-08-04
- Default branch
- main
View the original SKILL.md
Memory doctor
Agent-memory is an unseen side-channel into every session's context window: facts accumulate there, often by accident, that the user never reviews and cannot govern. This skill drains it. Technically nothing should live in project memory — durable guidance belongs in homes the user controls (project docs, project skills/rules, user-level skills/rules), and the rest is garbage. Block by block, move each entry to its proper home or archive it, until memory trends toward empty and the user — not the memory store — decides what reaches the context window.
Golden rule
The skill guesses and recommends; the user decides. Every verdict, scope, form, and target is a proposal the user confirms or flips. When unsure, ask. Nothing is moved, deleted, or written without explicit per-item approval. For every block the user gets the whole fixed menu — relocate/merge, archive (delete), keep, or a custom action they type — never just the recommended verdict, never a pruned subset.
Locate the memory
Find the memory store for the current project. Its location is agent-specific — other agents store
it elsewhere, or not at all. Claude Code example: slugify the project's absolute
working-directory path by replacing each / with - and prefixing one -, then look for
~/.claude/projects/<slug>/memory/MEMORY.md (e.g. cwd /Users/me/app → -Users-me-app). If that
path is absent, or the user runs a different agent, ask the user for the memory path. Only
discovery is agent-specific; everything below is agent-agnostic.
Block = the smallest self-contained memory unit — typically one memory file plus its MEMORY.md
index line, generally one fact each, though a store may group differently. If the memory is a single
flat file with no index, treat each section as a block.
Flow
- Scan (read-only). Read every block. To judge staleness you may read or grep project files, git, and governing docs — but make no mutation in this phase.
- Triage table. Present all blocks as ONE narrow overview table that renders as a table, not a
wrapped list:
# | block | content (≤1 line) | verdict | why + target. Every cell is a summary: thecontentcell one line, thewhy + targetcell folding justification, duplicate/garbage evidence, and relocate scope/form/path. Full detail for a block waits for its question (step 3). The table numbers each block (1…N); refer to a block by that number, in order, and never re-list block numbers out of sequence in surrounding prose. The table ends the turn; step 3 begins the next — a same-turn question buries the table behind the prompt. - Decide, one question per block, in strict index order (1 → last). Walk blocks by their table index — never group, batch, or reorder blocks, even when adjacent ones share a verdict; ask about exactly one block per prompt. For each, lead with the detail the table only summarized — a verbatim content excerpt plus the full justification — so the user can judge, then present its recommended verdict as the default, then the same fixed menu every time regardless of that verdict — relocate/merge, archive (delete), keep, or other (the user types a custom action). Never drop an option because it seems not to apply; the user must never have to type a standard option by hand. Record each confirmed choice and move straight to the next block — act on nothing yet; never skip a block or record a choice without its own explicit confirmation.
- Execute, once every block is decided. Apply the recorded actions in index order, honoring the Safety rules below (relocate-before-delete, honest index). Doing all the work in one pass — never interleaved with the questions — keeps the decision phase a fast, uninterrupted Q&A.
Verdicts
- Duplicate — already covered by an existing project/user skill, doc, or rule. Cite the specific file (ideally line). Prefer a merge — fold any wording the block states better into the existing home — over a blind delete.
- Garbage — delete-worthy: stale (cites code/files that no longer exist — verify by reading/grepping, never assume), re-derivable (restates what the code, git, or a governing doc already makes obvious), or a one-off that never generalized. Never garbage on suspicion; the skill must have verified, and the user still confirms.
- Relocate — genuine durable guidance with no current home. Route by scope × form (below).
- Keep — real and durable, but no good home yet and not worth manufacturing one. Log it in the summary and leave the block untouched — do not annotate it as "reviewed"; that is just more context-window noise.
Routing for relocate (scope × form)
Both axes are proposals the user confirms or flips.
- Scope — "would this be true or wanted in a different project too?" Yes → user-level (the agent's own config home). No → project-level (a doc in the repo, or the repo's project-scoped skill/rule config). For user-level, do not assume reusable config lives in any particular managed repo; if it does, the user redirects on confirmation.
- Form — short standing behavioral constraint → rule; multi-step procedure with a trigger → skill; reference knowledge/design/context read when relevant but not an instruction → doc.
If using Claude Code: user-level config lives in ~/.claude/skills and ~/.claude/rules,
project-level in the repo's .claude/skills and .claude/rules.
Do the relocation through self-improve — it finds the home, drafts the least-text edit, and applies it (routing the write through the matching compaction skill). This skill owns discovery, enumeration, classification, and the archive/delete path; self-improve owns writing the content into its home.
Safety
Memory files live outside the project repo and are not in git, so a delete is irreversible.
- Relocate-before-delete. A block's content leaves memory only once it has landed in a confirmed home (relocate/merge applied) or the user explicitly OKs it as worthless. Never archive or delete the source before the destination edit is confirmed-applied.
- Archive, don't
rm. Worthless blocks are moved tomemory/.archive/, not deleted — an archive folder costs nothing in context and stays recoverable. - Keep the index honest. Update the
MEMORY.mdindex line in the same step as any block removal or relocation: never orphan a file, never dangle a pointer to a moved or archived one.
Close
Print an ephemeral chat summary — no report file (that would just be new uncontrolled state). Include counts plus each block's disposition (relocated → where, merged, archived, kept, skipped), and list kept blocks with each one's "no home because…" reason. The real deliverables are the cleaned memory and the archive folder.