From vp-beads
Audit the `bd remember` store and recommend which entries to prune, so each one earns its per-session `bd prime` injection cost. Read-only: it proposes a triage table plus the exact `bd forget` / migration commands; you run them. Use when `bd remember` entries have accumulated, feel stale, redundant, or conflicting, or when session-startup token cost from injected memories is high. Trigger phrases: 'harden memories', 'audit bd remember', 'prune bd remember', 'bd remember bloat', 'bd remember audit', 'trim bd remember', or '/harden-memories'. NOT for Claude Code auto-memory (`/dream` / Auto Dream files), NOT for Basic Memory graph hygiene (use vp-knowledge's memory-defrag / memory-lifecycle skills), and NOT for beads issues or the backlog (use /backlog-groomer).
How this skill is triggered — by the user, by Claude, or both
Slash command
/vp-beads:harden-memories.beads/**This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Audit the project's `bd remember` entries and recommend which to prune down to
Audit the project's bd remember entries and recommend which to prune down to
the few that genuinely earn their cost. bd prime injects every bd remember
entry in full at session start (they are persisted in the beads Dolt database),
so entries accumulate as a silent, scaling token tax — conventions drift, skills
ship, and facts graduate to CLAUDE.md / the auto-memory MEMORY.md / Basic
Memory, but nothing automates the cleanup until a manual pass. Periodic audits
(≈ every 4 sprints) reliably recover ~40% of that token budget.
This skill is READ-ONLY by design. It audits and proposes — it never edits
a durable file, never writes to Basic Memory, and never runs bd forget itself.
For each entry it presents a recommendation plus the exact command(s) for you
to review and run. This deliberately keeps the irreversible step (bd forget,
which destroys the only copy of a fact) and the migration write under your
control — no automated "verify-then-delete" can be trusted to gate an
irreversible delete (a Basic Memory write can fail schema_validate
asynchronously; an Edit can land in the wrong file; an append can hit the
wrong section). Proposing keeps you in the loop for both halves.
Scope — strictly the bd remember store. NOT Anthropic's Auto Dream /
/dream (which prunes Claude Code auto-memory files, a different store), and NOT
Basic Memory graph hygiene (defer that to vp-knowledge's graph-maintenance
skills). It audits bd remember and nothing else.
Beads is available iff a .beads/ directory exists and command -v bd
succeeds; this component is Tier B per CLAUDE.md
### Beads-availability convention. The bd remember store only exists when
beads does — with no beads there is nothing to audit. Stop cleanly, naming the
missing predicate (no .beads/ directory, or bd not on PATH). There is no
beadless equivalent to redirect to.
bd memories --json
Returns a JSON object keyed by memory key. Keep only entries whose value is a
string — memory entries are always strings; scalar metadata (e.g.
schema_version) are numbers or booleans:
bd memories --json | jq 'to_entries | map(select(.value | type == "string")) | from_entries'
The surviving entries are the audit set. If there are none, report that there is nothing to prune and stop.
For every entry, run the canonical three-question checklist (from Basic Memory
engineering/agents/three-memory-systems-taxonomy-and-graduation):
MEMORY.md / CLAUDE.md? →
recommend remove.MEMORY.md for
project state, or Basic Memory for generalizable engineering knowledge), then
remove.To answer question 1, cross-reference each entry against the live sources:
Read CLAUDE.md (small enough to read whole) and scan for the entry's key
facts. (The auto-memory MEMORY.md lives outside the repo at the Claude Code
project memory path — name it as a target in proposals, but you need not read
it here.)mcp__basic-memory__search_notes with 2-4 keywords from the entry. For
any match, mcp__basic-memory__read_note and confirm the specific fact is
actually present before recommending remove — a keyword co-occurrence is
NOT confirmation of capture. If you cannot confirm the fact is captured, do
not recommend remove.Tag each entry with the bloat category that justifies its disposition: redundancy (duplicates a live source), staleness (describes a state that no longer holds — e.g. an entry that says "STALE" or names a shipped/abandoned plan), granularity drift (early-project specifics that became standard practice), or conflicting (contradicts another entry or a live source).
| Key | Summary | Category | Recommendation | Rationale |
|---|---|---|---|---|
<key> | one line | redundancy / staleness / drift / conflicting | remove / migrate→<target> / keep | one line |
For the user to review and run. Group by disposition:
migrate→<target> — show the drafted text to add and the explicit
target (a named CLAUDE.md section; the auto-memory MEMORY.md; or a Basic
Memory note path + section). For the auto-memory MEMORY.md, give its real
path — ~/.claude/projects/<project-slug>/memory/MEMORY.md, where
<project-slug> is the project's absolute path with / → - — and ask the
user to confirm it rather than emitting a bare MEMORY.md (which would
resolve to a non-existent repo-root file). Then the bd forget command,
clearly marked "run only after you have written and verified the migration":
bd forget <key> # after the fact is durably captured at <target>
For a Basic Memory target, note the gotcha: use edit_note with find_replace
/ insert_before_section, never append with a section (it appends to
end-of-file, not end-of-section).
remove — show the evidence that the fact is already captured (which source, confirmed in step 2), then the command:
bd forget <key> # already captured elsewhere or no longer true
Note for the user: bd forget prints No memory with key "..." and exits 1 if
the key is already gone (benign); any other non-zero exit is a real failure
(DB locked/missing) worth investigating — verify with bd memories, not the
exit code.
keep — no command; the entry earns its injection.
Summarize: recommended-remove count, recommended-migrate count (with each target), keep count, and the approximate per-session token reduction if the user applies the removals (entries removed × their injected length). Note that the audit cadence is ≈ every 4 sprints.
bd forget. It presents recommendations and exact
commands; the user performs the irreversible write and delete steps, keeping
both under explicit human control.bd forget is run. The action plan always presents the migration first and
marks the bd forget as "run only after the migration is verified."bd remember entries are injected every session;
a kept entry should be a single-sentence recovery trigger. If a kept entry is
long, propose tightening it (the user re-runs bd remember with --key to
upsert) as part of the audit.bd remember. Basic Memory graph
hygiene (orphans, schema, duplicate notes) belongs to vp-knowledge's
graph-maintenance skills; do not perform it here.npx claudepluginhub voxpelli/vp-claude --plugin vp-beadsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.