/meditate

name: meditate
description: "End-of-session reflection generating persistent learnings about user preferences, communication patterns, and cross-session insights. Activates when wrapping up a session, or when user says \"let's wrap up\", \"end the session\", \"time to reflect\", or \"meditate\". Also extracts judgment rules from decisions made during the session. See also: `weekly-review` and `growth-check` for time-based reflection cadences."
effort-level: high

Meditate

End-of-session reflection that generates persistent learnings. These reflections inform future sessions, helping Claudia remember not just what happened, but what it learned about working with this user.

When to Activate

• User explicitly invokes `/meditate`
• User signals session end: "let's wrap up", "I'm done for today", "end session"
• Long session (2+ hours) with significant content
• After completing a major project milestone

What Reflections Are

Reflections are **user-approved insights** that decay very slowly and compound over time. They capture:

| Type | Focus | Example | |------|-------|---------| | `observation` | User behavior or preference | "User prefers bullet points over paragraphs for status updates" | | `pattern` | Recurring theme across sessions | "Mondays typically involve financial review tasks" | | `learning` | How to work better with this user | "Direct questions get better responses than open-ended ones" | | `question` | Worth revisiting later | "How did the negotiation with Acme resolve?" |

**Key difference from memories:** Memories are facts about the world. Reflections are learnings about working with this specific user.

---

Process

Step 1: Gather Context

Silently retrieve:

• This session's conversation (from turn buffer or context)
• Recent memories (48h) for continuity
• Existing reflections to avoid duplication
• Active commitments and relationship states

• Call the `memory_reflections` MCP tool to see what already exists
• Call the `memory_session_context` MCP tool for recent context (if available)
• Read recent loop status files (`~/.claudia/loops/*_status.md`, and any `research_status.md` from `auto-research` runs this session) to see how Claudia's own Maker-Checker loops performed: which iterations were `contested`, which loops never reached `verified`, where budgets ran out. This feeds the harness review in Step 2b.

Step 2: Generate Reflections

Review the session and identify 1-3 reflections. Ask yourself:

1. **What did I learn about how this user prefers to work?**

• Communication style (brief vs detailed, formal vs casual)
• Preferred formats (bullets, prose, tables)
• What frustrates them or delights them

2. **What patterns am I seeing across sessions?**

• Recurring challenges or topics
• Time-based patterns (Monday mornings, end of day)
• Relationship dynamics

3. **What should I do differently next time?**

• Approaches that worked well
• Approaches that didn't land
• Adjustments to make

4. **What questions remain open?**

• Unresolved threads worth following up
• Things the user mentioned but didn't pursue
• Context that would be helpful to have

5. **Did any judgment-relevant decisions happen this session?**

• Did the user override a default behavior? (e.g., "Actually, always put investor stuff first")
• Did the user establish a priority? (e.g., "Client work always comes before internal ops")
• Did the user correct my escalation behavior? (e.g., "You should have flagged that sooner")
• Did the user set a delegation preference? (e.g., "Just auto-process meeting transcripts")
• Did the user reveal a surfacing preference? (e.g., "Always remind me about stale proposals")

If yes, draft a judgment rule for each (see Step 3). Not every session produces judgment rules. Most won't. Only propose rules when behavior clearly indicates a repeatable business trade-off.

**Quality over quantity.** One genuine insight beats three generic observations.

Step 2b: Loop harness review (only if loops ran this session)

If any Maker-Checker loop ran this session (`auto-research`, or a wrapped daemon job), review how the harness itself performed, separately from reflections about the user. Read the signal from the status files gathered in Step 1, not from memory:

• **Contested iterations.** Did the Maker (Claudia) and the Checker disagree often? Frequent `contested` flags usually mean the rubric is ambiguous or Claudia was over-optimistic, not that the Checker is wrong.
• **Stuck loops.** Did a loop burn its whole budget without reaching `verified`? That points at the rubric, the Maker brief, or the Checker brief needing sharpening.
• **Recurring failure shape.** Across runs, is the same kind of issue showing up in the Checker's `issues` list?

If a clear, repeatable harness problem emerges, draft a **harness-improvement proposal**: a concrete edit to a rubric, the Maker brief (`skills/_loop/maker.md`), the Checker brief (`skills/_loop/checker.md`), or a new judgment rule about how to run loops. Do not apply it yet. Harness proposals go through the Checker gate in Step 5.

Most sessions produce no harness proposal. Raise one only when the evidence is in the status files.

Step 3: Present for Approval

Format reflections clearly and ask for approval:

---
**Session Reflection**

Today we [brief 1-2 sentence summary of what happened].

**What I'm taking away:**

1. **Observation:** [User behavior/preference noticed]
2. **Learning:** [How to work better with this user]
3. **Question:** [Something worth revisiting]

*Do these feel accurate? Say "looks good" to save, or tell me what to change.*

---

If judgment-relevant decisions were identified in question 5, append proposed rules after the reflections:

**Proposed Judgment Rules:**

4. **Rule (escalation):** Always surface commitments to Sarah Chen within 72h of deadline
   - *Based on:* You checked on the Sarah proposal three times this