---
name: close-day
description: End-of-day audit ritual — synthesize sessions into daily log, audit patterns against MEMORY.md and existing concepts/rules, propose promotions verbally, write approved patches
---

# /close-day — The audit ritual

You are closing the user's working day. This is NOT just "dump today into a file". This is the **audit moment** where you inspect what the day produced, compare it against accumulated memory, and propose what should grow into the user's knowledge base or rules.

## Your goal in two phases

### Phase 1: SYNTHESIZE

Create `daily/YYYY-MM-DD.md` (today's date in ISO format). Include:

- **Session count and approximate total duration.** How many times did the user start a fresh session today? Rough total time.
- **Projects worked on.** Which `projects/<name>/` were active today.
- **Key decisions made.** What did the user decide today that will shape future work?
- **Artifacts produced.** Code shipped, copy drafted, design finalized, research completed.
- **Open threads.** What's left unfinished and should be picked up next session.
- **Notable moments.** Things the user reacted strongly to (positive or negative). These are high-signal for the audit.

Format: concise, structured markdown. This file is the chronological record. Target 200-500 words.

Also update `context/next-session-prompt.md` (NSP) with the immediate-action handoff: "Tomorrow: continue X. Open questions: Y, Z."

### Phase 2: AUDIT

Now the ritual. Read:

1. **Today's daily log** (just written)
2. **`MEMORY.md`** — date-tagged patterns from prior sessions (lean on the `[YYYY-MM-DD]` prefixes — they are how you detect repetition)
3. **Existing knowledge articles** — `knowledge/concepts/*.md` (check `updated:` frontmatter to see freshness)
4. **Existing rules** — `.claude/rules/*.md` (check `last-reviewed:` frontmatter to spot stale rules)
5. **Active experiments** — list `experiments/*/` folder names; parse the `-YYYYMMDD` suffix to find any older than 30 days

**Date-arithmetic queries you should run mentally (or with grep):**
- "Did this pattern appear in MEMORY on 3+ distinct dates within the last 14 days?" → strong promotion candidate
- "Has this rule's `last-reviewed` been more than 90 days ago?" → ask user if it still applies
- "Are any experiment folders older than 30 days?" → ask user to close or revive

Compare. Look for four kinds of signals:

#### Signal A: Cross-session repetition
A pattern you noticed today matches MEMORY entries on multiple distinct prior dates. Quote the dates back to the user — that's the evidence.

**What to do:** Propose codifying it.

> "Noticed: you rejected em-dashes in short copy on [2026-04-21], [2026-04-23], [2026-04-27]. Three distinct days, no contradiction. Codify as a rule in `.claude/rules/copy-style.md` (frontmatter `created: 2026-04-27`): 'em-dash forbidden in UI copy ≤20 words'? Or as a section in `knowledge/concepts/copy-style.md` if you want the rationale alongside? I can write it — confirm."

#### Signal B: New strong preference
User expressed a clear preference today, even once, but it was emphatic. Example: "I hate blurry previews — never do that".

**What to do:** Propose adding it. If emphatic enough, propose a rule directly. Otherwise add to MEMORY.md and wait for repetition.

> "You said clearly that blurry previews are unacceptable. Even though it's the first time in this project — should we lock it in `.claude/rules/visual-quality.md` now, or save to MEMORY and wait for a repeat?"

#### Signal C: Contradiction with existing canon
Today you did something that contradicts an existing rule or concept article. Example: `concepts/design-tokens.md` says "warm palette default" but today user insisted on a cold palette for a specific page.

**What to do:** Surface the tension. Don't silently update — ask.

> "Today we built page X in a cold palette. `concepts/design-tokens.md` says 'warm palette default for editorial pages'. Is this an exception or should the rule be updated?"

#### Signal D: Article-worthy topic emerged
Today's work surfaced a topic that's been touched several times across `daily/*.md` with accumulating detail (5+ times) and the facts are stable.

**What to do:** Propose compiling a `knowledge/concepts/<topic>.md` article via `/memory-compile`.

> "Topic 'Stripe webhook patterns' came up on [2026-04-08], [2026-04-15], [2026-04-22], [2026-04-25], [2026-04-27] — 5 distinct days across 3 weeks. Want me to compile a `knowledge/concepts/stripe-webhooks.md` article that pulls together the rationale from those daily logs?"

#### Signal E: Experiment hygiene
Folders in `experiments/<name>-YYYYMMDD/` older than 30 days that haven't been closed are stale.

**What to do:** Surface them. Don't auto-close — ask.

> "`experiments/payment-provider-selection-20260322` has been open 36 days. Still active, or ready to distill and close?"

If user says close → run the **distill ritual**:
1. Lessons → `knowledge/concepts/<topic>.md`
2. Reusable code → `projects/<name>/`
3. Update EXPERIMENT.md `Status:` field to `closed-success | closed-failed | inconclusive`
4. After distillation confirmed, propose `rm -rf experiments/<name>-YYYYMMDD/` (git history retains)

If experiment patterns repeated across days but the experiment is still open — note them in MEMORY but **do NOT propose promotion to rules yet**. Experiments are sandbox; promotion happens after distillation, not from raw experiment notes.

### Phase 3: EXECUTE APPROVED PATCHES

For each signal user approved verbally:

1. **Write the patch.** Open the target file, add the new entry at the right section, or update MEMORY.md, or modify NSP — whatever was proposed.
2. **Confirm briefly to user.** "Saved."
3. **Commit mentally to what you DIDN'T approve.** If user said "not now", DON'T write it. Keep it in next session's awareness so you can propose again if pattern recurs.

### What you do NOT do

- **Don't ask user to open any file.** Never say "open the rules file and add...". Say "I'll write it — confirm?".
- **Don't promote to `.claude/rules/` casually.** Rules are forever. A pattern needs to be either: emphatic AND clearly mechanical, OR repeated 3+ times in MEMORY without contradiction. Otherwise prefer `knowledge/concepts/<topic>.md` (which can be edited later) or a longer wait in MEMORY.
- **Don't write patches without explicit verbal approval.** "yes", "ok", "go", "save it" all count. Silence or ambiguity does not — ask again.
- **Don't surface more than 3-4 candidates per `/close-day`.** Pick the most signal-rich. Overwhelming the user with proposals kills the ritual.
- **Don't repeat proposals user already rejected.** If on last week's `/close-day` user said "not now" to adding X — don't propose X again unless there's new evidence (another repetition, related pattern, etc.).

## Session definition (context for your audit)

A "session" is **one Claude context window**. As you accumulate context (~300-500k tokens of 1M), you ask user to save state and start fresh. A day can have 3-10 sessions.

When synthesizing today's daily log, include ALL sessions of the day, not just the current one. You may need to read prior NSP states or session-start hook snapshots to know what earlier sessions contained. If uncertain, ask user: "how many times did we restart today? What was in the morning session?".

## Output format

When the user types `/close-day`, respond in this shape:

```
Synthesizing the day...
[brief note: X sessions, projects Y, Z, key decisions]

daily/2026-04-24.md written.
NSP updated.

Audit:

1. [Signal description]
   Proposal: [what to add where]
   Add? [yes/no]

2. [Signal description]
   ...

(Waits for user response to each item)
```

After user confirms each, execute patches and confirm briefly.

## Edge cases

- **User says "cancel" or "not now" mid-ritual** — acknowledge, stop the ritual, nothing is lost. Today's daily + NSP is already saved. Audit candidates can be revisited next time.
- **Nothing notable happened today** — the audit may surface zero candidates. That's fine. Just synthesize the daily and confirm: "Quiet day, no promotion candidates. Done."
- **User wants to preview patches before approving** — show the exact text you'd write, so they can adjust wording via speech. "Was going to write: 'X'. Wording OK?".
- **Current session still has active work** — if user types /close-day mid-task, clarify: "Close out the day now, including unfinished work? Or finish first?".

## Why this ritual exists

Memory Kit's invariant: **user only talks, agent writes**. Prior versions tried to automate promotion detection with background scripts — unreliable + violated the invariant by implicitly pushing users to edit files. `/close-day` replaces that with an agent-in-the-loop ritual: the agent has full conversational context at end of day, can spot patterns a script would miss, and does the writing itself.

The user's job is to **notice what they notice** during the day's work. Yours is to **catch it and structure it**.