dream-remember

Review and apply pending memory updates from the learnings backlog.

Updated May 3, 2026
One-click install
npx skills add https://github.com/spikelab/multiplai-cc-mktplace --skill dream-remember-spikelab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dream-remember
Source: https://github.com/spikelab/multiplai-cc-mktplace/tree/main/plugins/multiplai-context/skills/dream-remember
Command: npx skills add https://github.com/spikelab/multiplai-cc-mktplace --skill dream-remember-spikelab

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Accumulated session learnings pile up in a backlog and never reach long-term memory without a controlled review process. This Skill provides a human-in-the-loop workflow that triages, resolves, and applies proposed memory updates so nothing enters memory unapproved and nothing reviewed gets lost. ## Core Features & Use Cases - Automated triage: A rubric, a judge model, and an in-code safety floor partition proposals into apply, review, and drop verdicts, with kind: RULE items never applied automatically. - Evidence-based resolution: Duplicates are merged, contradictions resolved by source date, and checkable claims verified against code or transcripts before writing. - Auditable decision record: Every decision is marked processed in the proposal file, receipts and rejection logs are written, and memory changes are reversible via git revert. - Use Case: After a week of coding sessions, run the skill to review a 190-item dream proposal: uncontroversial facts apply automatically, duplicates merge, and only genuine policy questions reach you. ## Quick Start Ask the agent to review and apply the pending memory updates from the learnings backlog using the dream-remember workflow.

Frequently Asked Questions about dream-remember

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review and apply pending memory updates from session learnings?

Run the dream-remember skill, which loads the newest proposal from .multiplai/dreams/, triages it automatically, resolves what evidence settles, and asks you only about rule changes and policy decisions. Approved edits are applied per target file and recorded in the proposal.

How does the triage decide which memory items apply automatically?

Three layers decide: a provenance-and-kind rubric in code, a judge model that can only lower verdicts, and an in-code floor that refuses unsafe targets. Items of kind RULE never apply automatically under any provenance or mode.

Can a rule ever be written to CLAUDE.md automatically?

No. Items marked RULE-PROPOSAL or targeting CLAUDE.md/AGENTS.md are always presented one at a time for explicit approval, even when the user answers all. The in-code floor refuses such writes in every mode.

What happens to dropped or rejected memory items?

Dropped items are removed from the proposal but written in full to .multiplai/data/rejections.jsonl with their source citation and the judge's reason. Rejected items are marked processed in the proposal, and nothing is deleted from the source learnings.

Why does the dream-remember run take a long time to generate a proposal?

Generating a fresh proposal with dream.py can run for many minutes, exceeding the Bash tool's 600-second timeout. It must be invoked with run_in_background set to true, and completion is detected by the sentinel line 'Proposal written to <path>'.

How do I undo a batch of applied memory updates?

Memory is under git, and each triage run writes a receipt under .multiplai/dreams/applied/ ending with the exact git revert command that undoes the whole batch. Run that command to reverse all applied edits.