Claude-Mind: Skill for Claude Code

/replay — Hippocampal Replay Engine

Compressed, selective review of resolved hypotheses. Inspired by hippocampal sharp-wave ripples that replay experiences at 20x speed during rest, selectively prioritizing novel, goal-relevant, and high-stakes outcomes.

Based on: Hippocampal sharp-wave ripples (Buzsaki 2015), systems consolidation theory, memory reconsolidation (Nader et al. 2000).

Quick Links

Related Skill	Relationship
/reflect	Parent — calls /replay during --full-cycle
/reflect-on-outcome	Hypothesis + execution reflection feeds replay candidates
/reflect-on-self	Pattern extraction mines replayed hypotheses
/aspirations-consolidate	Calls /replay during session-end consolidation

Parameters

• --sharp-wave — Run compressed replay of last N resolved hypotheses (default: 10)
• --reverse — Replay in reverse chronological order (recent first)
• --selective — Only replay tagged items from working memory encoding_queue (via wm-read.sh encoding_queue --json)
• --category <cat> — Replay only hypotheses from a specific category
• --domain-transfer — Cross-domain replay: find patterns in strong domain applicable to weak domains

Default (no args): equivalent to --sharp-wave --reverse

Step 0: Load Conventions

Step 0: Load Conventions — Bash: load-conventions.sh with each name from the conventions: front matter. Read only the paths returned (files not yet in context). If output is empty, all conventions already loaded — proceed to next step.

Step 1: Select Replay Candidates

Bash: pipeline-read.sh --replay-candidates → resolved hypotheses eligible for replay
Bash: wm-read.sh encoding_queue --json  (if --selective mode)
Read core/config/memory-pipeline.yaml → replay_priority_order, max_replay_items

Priority selection (most learning signal first). THE FIELD IS `surprise` — read
it by that exact name, NOT `surprise_level` (g-001-05, measured 2026-08-10):
`surprise_level` is a WRITE-SIDE ALIAS that `core/scripts/pipeline.py:442`
normalizes to `surprise` at write time, so it survives on almost no record. Live
counts over the 464 replay candidates on cc-05: `surprise` present on 425,
`surprise_level` on 1. The canonical field is seeded `"surprise": None` in
DEFAULT_FIELDS (pipeline.py:79) and documented in
`core/config/conventions/pipeline.md`.
Keying on the alias is SILENT and self-concealing: rules 1 and 2 below both go
to zero, so selection falls through to rule 5 and returns a batch of routine
CONFIRMED fillers that looks like a perfectly normal replay. There is no error
and no empty result — the only symptom is a batch with no violations in it,
which is also what a genuinely calm week looks like. Sanity check before
trusting a zero: `surprise>=5` matched 104 of 464 and violations 56 of 464 on
the run that found this.
1. Violations: hypotheses where outcome contradicted expectation (`surprise` >= 5)
2. High-impact outcomes: hypotheses with `surprise` >= 7 or significant consequences
3. Pattern signature mismatches: hypotheses where a pattern was matched but outcome differed
4. EXPLORE/CALIBRATE categories: hypotheses in categories where we're still learning
5. Random sample: 2-3 routine hypotheses (prevents overfitting to extremes)

Apply spaced repetition filter:
  For each candidate, check replay_metadata.last_replayed
  Skip if replayed within last 7 days
  Skip if replay_metadata.encoded_via_chronic == true
    # Chronic-CORRECTED items already encoded as a calibration guardrail by
    # Step 3.6 — re-replaying them yields zero new learning (g-115-1104).
    # As of g-115-1421 pipeline.py's replay_candidates endpoint ALSO excludes
    # these at the source, so they no longer appear in the candidate list;
    # this LLM-side skip remains as defense-in-depth.
  IF replay_metadata.replay_count >= 5:
    # Hard cap (encoded or not): stop infinite cycling. Move to archived,
    # never delete (CLAUDE.md pipeline rule), then drop from candidates.
    Bash: pipeline-move.sh {candidate.id} archived
    Log: "REPLAY CAP: archived {candidate.id} (replay_count >= 5)"
    Skip
  Prefer hypotheses never replayed (replay_count == 0)

  ⚠ THIS PREFERENCE AND THE PRIORITY ORDER ABOVE ARE ANTI-CORRELATED, AND
  NOTHING HERE SAYS WHICH DOMINATES. Resolving it rc-first costs the entire
  violation enrichment. Measured 2026-08-19 (zeta, hostname cc-02, uname -r
  6.8.0-137-generic, 588-record pool), replay_count x surprise:

      rc   surp>=6   surp==5   surp<5
       0         1        12      194
       1        67        25      110
       2        31         4       49

  The never-replayed stratum is surprise-POOR (194 of 207 below 5; exactly ONE
  record at rc==0 AND surprise>=6), because spaced repetition is WORKING — a
  high-surprise record gets replayed, so it accumulates rc and leaves the rc==0
  stratum. The two preferences therefore pull apart by construction and will
  keep doing so.
  Cost, measured on the same run: sorting (rc asc, surprise desc) and taking the
  top 8 produced a batch at 30% CORRECTED — the corpus BASE rate of 29.2% — while
  rule 1's own population (surprise>=5) runs 69.0% CORRECTED, a +39.8pp
  enrichment. Sorting rc-first did not weaken the enrichment; it discarded ALL of
  it, and the resulting batch looks perfectly normal.
  RESOLUTION: order by the PRIORITY RULES first and use replay_count only to
  break ties WITHIN a priority band. The spaced-repetition filter (7-day skip +
  `next_review_date`) already prevents re-replaying anything recent, so rc==0 is
  not needed as a freshness guard — it is a tiebreak, and promoting it to the
  primary key silently inverts what this step selects for.

  ⚠ THAT RESOLUTION IS NOT SUFFICIENT WHEN THE BAND IS COARSE, and "within a
  priority band" is exactly where it hides. `surprise` is a small integer, so
  band 1's top tie group is large and the "tiebreak" ends up doing most of the
  selecting — reproducing the rc-first failure through the back door while
  looking like compliance. Measured 2026-08-21 (foxtrot,
  `hostname` LAPTOP-3IOFCNEO, `uname -r` 6.6.87.2-microsoft-standard-WSL2,
  626-record pool): NO record scored `surprise >= 7` at all, so rule 2
  contributed nothing and rule 1's top tie group was the 118 records at
  `surprise == 6`. The anti-correlation PERSISTS INSIDE that single band —
  CORRECTED by replay_count runs rc=0 **50.0%** (n=12), rc=1 **70.4%** (n=71),
  rc=2 **93.9%** (n=33). So an rc-asc tiebreak selects the band's LEAST-enriched
  corner. Following the RESOLUTION literally produced a batch at 30.0%
  CORRECTED against a 27.3% corpus (+2.7pp — the enrichment gone); stratifying
  the same 8 slots across rc 3/3/2 gave 50.0%. FIX: when the top band is larger
  than N, STRATIFY across replay_count rather than sorting by it, and stratify
  on the TIEBREAK axis — never on `outcome`, which is the variable every rate
  below is computed over (selecting on it makes the reported rate circular).
  Check the band's surprise ceiling before trusting the priority sort: if the
  ceiling is also the modal value, the priority rules have already stopped
  discriminating.

  (Do not read this as contradicting guard-2129: rule 1 IS enriched for
  corrections, by 39.8pp, so every batch-scoped corrected-rate remains
  upward-biased and still must be re-measured against the corpus.)

Select top N candidates (N = max_replay_items from config, default 10)

   # Add experience-backed candidates
   IF agents/<agent>/experience.jsonl exists:
       Bash: experience-read.sh --type goal_execution
       Bash: experience-read.sh --type hypothesis_formation
       Include experiences with high retrieval_count as additional replay candidates
       Experience candidates complement pipeline-based candidates — they provide
       full-fidelity traces that pipeline summaries may have compressed away