Source profileQuality 85/100

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…

Best for

    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

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    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.

    Source-detected install commandSource
    npx skills add https://github.com/eai-org/agent-toolkit --skill "skills/memory-doctor"
    Safe inspection promptEditorial

    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

    1. 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…
    2. 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…
    3. 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
    4. 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).
    5. 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

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score85/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars30SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated 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

    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 | content (≤1 line) | verdict | why + target. Every cell is a summary: the content cell one line, the why + target cell 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.
    3. 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.
    4. 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 to memory/.archive/, not deleted — an archive folder costs nothing in context and stays recoverable.
    • Keep the index honest. Update the MEMORY.md index 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.