/diary

name: diary
description: "Use when the user says 'save diary', 'log session', 'wrapping up', or at end of a productive session."
version: 1.1.0

📓 Diary: Logging Session...

*Document what was accomplished in each CC session for future recall.*

Activation

When this skill activates, output:

`📓 Diary: Logging session...`

Then execute the protocol below.

Context Guard

| Context | Status | Priority | |---------|--------|----------| | **User says "save diary", "log session", "write diary"** | ACTIVE: write diary | P1 | | **User explicitly says they're done ("that's it", "wrapping up")** | ACTIVE, suggest diary if work was done | P2 | | **Multi-agent session (Builder/Reviewer role)** | DORMANT: Manager handles diary | none | | **Mid-session, user is actively coding** | DORMANT, don't interrupt flow | none | | **Casual conversation, no code changes made** | DORMANT: nothing to log | none | | **User asks to recall past sessions ("what did we do")** | DORMANT, Echo handles recall, not Diary | none | | **User says "save project" or "handoff"** | DORMANT, Project skill handles this | none | | **Session just started, no work yet** | DORMANT: nothing to log | none |

When NOT to Fire

• **Do NOT fire autonomously.** Only activate when the user explicitly requests it ("save diary", "log session", "wrapping up").
• **Multi-agent sessions:** If you are operating as Builder, Reviewer, or any non-Manager agent in a multi-agent session, do NOT fire diary. Only the Manager or a standalone session should trigger diary.
• **No work done:** If no meaningful changes were made (no commits, no file edits), skip diary.

Reminders

When the user asks to save a diary, keep these in mind:

| Temptation | Why it matters | |---|---| | "Nothing important happened" | Even small decisions have context worth capturing. | | "Commits capture everything" | Commits don't capture decisions, blockers, or next steps. | | "Skip the handoff section" | Handoffs are the most valuable part for session continuity. |

Protocol

**Never pass a JSON payload as a quoted command-line argument. Write it to a file and pipe it in with the dash sentinel, as every command below shows. On Windows, cmd.exe treats single quotes as ordinary characters, so a redirection operator anywhere in a quoted payload is executed rather than passed.**

**All JSON field values must be plain strings. Never pass arrays or objects. If multiple items (files, commits, decisions), join them as a comma-separated string.**

1. **Summarize the session:**

• Project name and working directory
• Date and approximate duration
• What was built or changed
• Key files created or modified
• Commits made (hashes and messages)
• Decisions made and why
• Problems encountered and solutions

2. **Check git log** for commits:

   git log --oneline -10

3. **Format the diary entry:**

   # Session Diary: {project}, {date}

   ## Accomplished
   - Item 1...

   ## Files Changed
   - path/to/file.ts: description

   ## Commits
   - abc1234 Message

   ## Decisions
   - Decision: reason

   ## Next Steps
   - What to do next

   ## Session Handoff
   **In Progress:** [what was actively being worked on when session ended]
   **Uncommitted Changes:** [list any unstaged/uncommitted work, or "None"]
   **Pick Up Here:** [exact instruction for next session, specific enough to start cold]
   **Session Context:** [anything important that isn't captured elsewhere: temp decisions, debugging state, gotchas discovered]

4. **Save to SQLite database** (primary storage):

Write the payload to a file, then pipe it in with `-` as the argument. A payload on stdin is never seen by the shell's parser, so a redirection operator inside your prose cannot be read as one.

   cat session.json | python "${CLAUDE_PLUGIN_ROOT}/db/memstack-db.py" add-session -

The store is `~/.memstack/memstack.db`, one file per user, never a file beside the script. Every command prints the path it used on stderr as `memstack-db: store <path>`, so a session can confirm where it wrote instead of assuming.

**The SQLite row is the primary store. The markdown in `memory/sessions/` is a backup export.** The row holds the full `raw_markdown`, so a markdown file that is lost, truncated or overwritten can be restored from it: find the row in the `sessions` table by project and date, and write `raw_markdown` back to the file. This matters because `memory/` is gitignored, so version control is not a fallback and the database is the only one there is.

`session.json` contains:

   {"project":"<name>","date":"<YYYY-MM-DD>","accomplished":"<bullets>","files_changed":"<bullets>","commits":"<bullets>","decisions":"<bullets>","problems":"<bullets>","next_steps":"<bullets>","duration":"<estimate>","raw_markdown":"<full text>"}

5. **Save insights** for cross-project search:

Same form: write the payload to a file, pipe it in, `-` as the argument. Insight text is prose, so it must never travel on the command line.

   cat insight.json | python "${CLAUDE_PLUGIN_ROOT}/db/memstack-db.py" add-insight -

`insight.json` contains:

   {"project":"<name>","type":"<type>","content":"<insight>","context":"Session <date>","tags":"<project>"}

Choose `<type>` deliberately from this vocabulary, do not default to one:

• `gotcha`: something that bit us and the fix. Non-obvious behavior a future session would trip on again.
• `lesson`: a general rule learned the hard way. Broader than one bug.
• `pattern`: a reusable approach or convention that worked.
• `warning`: a known hazard to avoid. Not yet a bug, but will be.
• `failed_approach`: something tried that did not work, and why. Prevents retrying it.
• `architecture`: a structural fact about how a system is built.
• `decision`: a choice made and the reasoning. Historical record.

The first fiv