Dream

Dream

Consolidate what recent sessions revealed into the memory that loads next time.

Two modes, meant to run a day apart:

References

• references/scheduling.md — running the two modes as routines, and the invocation requirement
• references/configuration.md — settings, defaults, and where run state lives
• references/rules-and-instructions.md — when a finding belongs in a path-scoped rule or an instruction file

Why this skill is model-invocable

Every other user-driven workflow in this plugin sets disable-model-invocation: true and carries a one-line description. This one must not, and the reason is not stylistic.

That field also prevents a scheduled task from firing the skill. Running unattended on a schedule is this skill's entire purpose, so setting the flag would leave a routine that fires and does nothing, with no error to notice.

Do not "correct" this to match the other skills. The deviation is recorded in the repository conventions for the same reason.

Workflow: full-analysis

1. Prepare the run

python3 "${CLAUDE_PLUGIN_ROOT}/lib/dream/cli.py" resolve

Stop if memory_exists is false and say the location was not found. An empty result from the wrong directory is indistinguishable from a clean one.

Create a run directory under the per-plugin data directory, named by timestamp. Never write run state inside the plugin directory.

2. Analyse recent sessions

Read ../../analysis/session-analysis/SKILL.md and carry out its steps here, inline. Do not invoke it with the Skill tool — it sets disable-model-invocation, so only a person can invoke it and the call is refused. The refusal message reads like a hard stop; it is not. Inline the procedure instead.

Produce analysis.md in the run directory, in dream mode. Pass --since from the previous run's timestamp when one exists; otherwise the default window.

3. Improve memory

Read ../improve-memory/SKILL.md and carry out its steps here, inline — same reason as step 2. Give it the analysis alongside the audit. It snapshots before writing, applies only what is mechanically certain, and returns everything else as proposals.

4. Carry forward the previous overview

When a previous overview exists, read its pending items so proposals keep their identity and sighting count across runs. Items already ticked belong to the apply-fixes run, not this one. Items unticked past the expiry threshold move to declined and are dropped.

5. Write the overview and deliver

Write memory-improvement-overview.md, then inline ../../notifications/send-result/SKILL.md the same way, with a short summary: what was applied, how many items await a decision, and where the full document is.

6. Prune

python3 "${CLAUDE_PLUGIN_ROOT}/lib/dream/cli.py" prune --keep 10

Workflow: apply-fixes

1. Find the pending overview

Locate the most recent memory-improvement-overview.md in the run directories. If there is none, say so plainly and stop — this is not a failure.

2. Read what was signed off

python3 "${CLAUDE_PLUGIN_ROOT}/lib/dream/cli.py" approved "<overview path>"

Only ticked items. An unticked item is left alone and stays pending.

3. Apply

Snapshot first:

python3 "${CLAUDE_PLUGIN_ROOT}/lib/dream/cli.py" snapshot

Then make each approved change, one at a time, exactly as its item describes. Do not extend an item beyond what it says, and do not apply an item whose meaning has become unclear — report it instead.

4. Record and deliver

Rewrite the overview with applied items moved into the applied section, then deliver a summary naming each change and the snapshot path.

Guardrails

• The three sub-skills are read and inlined, never invoked. The reuse is real but lives in the shared library and in these procedures, because a skill carrying disable-model-invocation can only be invoked by a person
• Never apply an item that was not ticked
• Never touch an instruction file automatically; those are proposals in both modes
• A failure in any stage names the stage and leaves memory unchanged
• Undo is cli.py restore, which puts the newest snapshot's files back