--- name: ingest-session description: Ingest a Claude Code working session into a vault as a source-note. Captures the final artefacts (files produced), key decisions made, calibration notes (what was considered and rejected), and any knowledge or external research that informed the session. Intended for long multi-hour working sessions whose outcome is worth preserving for interview prep, future regeneration, or just paper trail. Used by /ingest session. Not user-invocable directly, go through /ingest. user-invocable: false allowed-tools: AskUserQuestion, Read, Write, Edit, Bash(ls *), Bash(git log *), Bash(mkdir *), Bash(date *), Glob, Grep --- # Ingest Session Turn a working session (a long Claude Code conversation that produced real artefacts) into a structured source-note. Useful when you've done several hours of positioning work, CV iteration, skill writing, or research-and-decide loops and want the outcomes captured somewhere greppable later. ## When to use - You've been iterating with Claude Code for hours and want to close the loop with a paper trail. - A recruiter or interviewer might reasonably ask "walk me through why your LinkedIn reads this way" and you want to answer from notes, not from memory. - You plan to re-run a similar generation pass in a few months and want the skill to start from calibrated ground instead of rediscovering every lesson. - You've learned something about a tool or model that future skills should encode (e.g., Gemini's aspect-ratio quirks). ## Usage (via /ingest router) ``` /ingest session [--vault ] [--title ] ``` Examples: ``` /ingest session # current session, default vault /ingest session --title linkedin-overhaul # explicit title for the note /ingest session --vault personal-work --title cv-pass-for-stx ``` ## Output ``` vaults//wiki/sources/session-notes--.md ``` Plus rows appended to `wiki/index.md` Sources table and `log.md`, **and an update to `ROADMAP.md`** (see Step 6 below). ## Step 1: Resolve vault + title + date - Default vault: whichever vault this session's work has been modifying (check recent file writes under `vaults//`). - Date: today's date in `YYYY-MM-DD`. - Title: short kebab-case slug describing the session (e.g. `linkedin-overhaul`, `cv-pass-for-stx`, `bio-v3-calibration`). If not passed, interview the user for one. ## Step 2: Interview for the outcomes (if needed) If the session was entirely done by Claude in this conversation, Claude already knows the outcomes and should draft the note without asking. Just write it. If the user is ingesting a session that happened partly off-conversation (e.g. they ran several commands themselves, or the conversation is fragmented), ask 2-3 focused questions via AskUserQuestion: 1. **Session focus** — what was the core goal (positioning, feature work, research pass, etc.)? 2. **Final artefacts** — any files to link? Any live targets (LinkedIn, GitHub, deployed app)? 3. **Calibration notes** — was there a "what-was vs what-is" change worth recording (words, framings, decisions rejected)? Skip the interview when Claude has full context from the live session. ## Step 3: Extract the four canonical sections Every session note has the same four sections. Claude fills them from the conversation history: ### 3a. Final settled artefacts List every file / output that ended the session as the canonical one. Full paths inside the vault. Short one-line description each. This is what the user reaches for when they ask "where's the final X?" ### 3b. Decisions made The positions, phrasings, titles, approaches that landed. Present tense. Direct quotes where useful. ### 3c. Calibration notes (what was considered and rejected) A **table** of `what-was → what-is` plus a short reason per row. This is the single most valuable section for interview prep: each phrase was chosen over a stronger alternative for honest reasons. Example: ``` | Was | Now | Reason | |---|---|---| | `Lead Engineer` | `Software Engineer` | Never formally Lead; bullets prove leadership | | `co-leading X` | `helping with X` | Helping, not leading | ``` ### 3d. Knowledge captured External research, tool behaviours, and process-level learnings that inform future skills. Examples: - Gemini Nano Banana 2 supports `21:9` but not `4:1` - LinkedIn avatar covers `x=60-450, y=180-396` (observed, not the 568×264 the docs suggest) - IBM's definition of `AI-native` (link + summary) ## Step 4: Pick a source-type and related pages - `source-type: session` - `tags: [session-notes, ]` - `related` should link to every entity or comparison page the session produced or updated. This makes the session note a hub in the graph. - `sources` field: `"Claude Code session, "` plus any external URLs the session pulled from. ## Step 5: Write the source-note Template: ```markdown --- title: "Session Notes — ()" date-created: date-modified: page-type: source-note domain: - - session-notes tags: - session-notes - sources: - "Claude Code session, " - related: - "[[]]" - "[[]]" source-type: session author: " + Claude" date-accessed: --- # Session Notes — () ## Final settled artefacts ## Final positioning / final outputs ## Calibration notes ## Knowledge captured ## Skills created or updated ## Peripheral ingests ## Why this matters later ## Sources - **This session:** Claude Code conversation on , driven by . - **Related source material:** [[...]] - **External:** [...] ``` ## Step 6: Update the vault - Add a row to `wiki/index.md` under `## Sources` with `[[session-notes--]]`, a one-line summary, domain tags, date. - Append an entry to `log.md`: `## [] ingest | Session notes — ` with the source link and a paragraph of context. - **Update `ROADMAP.md`** (if the file exists — most vaults will have it): 1. Append a one-line entry to `## Recently completed`: `- : ([[session-notes--]])`. Prune the list to the most recent 10. 2. Scan `## In progress` for any checkboxes describing the work that just completed. Remove them (don't just tick them — the rolling "Recently completed" already captures that). 3. Ask the user: "Any new `Next up` items from this session?" — if yes, insert at the top of `## Next up`. If no, leave it. 4. Update the `_Last updated:_` date near the top of the file. If `ROADMAP.md` doesn't exist (e.g. older vault), skip without error and mention in the report that it would be worth creating one via `/pickup `. ## Step 7: Commit and report Auto-commit in the vault's repo using the standard emoji + conventional-commit format from `~/CLAUDE.md` (`✨ feat: ingest ...`). Add only the files just written: the source-note, `wiki/index.md`, and `log.md`. Respect the weekday commit-timestamp rule (`GIT_AUTHOR_DATE` / `GIT_COMMITTER_DATE` outside 08:30–18:00 Mon–Fri). Then report one paragraph: what got written, what paths, what the user can grep for later, and the commit SHA. ## Step 8: Skill-catalog drift audit (after every session close) Run the skill-lab catalog audit so any drift the session may have introduced (renamed skill, new skill missing from catalog, archived skill still pointed at) is surfaced before it accumulates: ```bash python3 ~/Dev/ai-projects/llm-wiki/.claude/skills/lint-skill-lab/audit.py ``` If the audit reports broken pointers (exit code 1), append a brief drift summary to the end of the report and ask the user whether to fix it now or defer. If the audit is clean (exit 0), include a single-line note in the report so the user knows the catalog is healthy. Reasoning: the catalog is a separate index that drifts silently from production unless something forces a check. Running this on every session close means drift never lasts more than one session. ## Rules - **Auto-commit** the ingest. The session note, index row, and log entry are always committed together so the paper trail is the commit. User can amend later if they want edits. - **Write in present tense** for decisions (`headline uses X`) and **past tense** for rejected paths (`considered Y, dropped because...`). - **No em-dashes, no banned AI-tell vocabulary.** Apply `/ro:write-copy` rules. - **Cross-vault refs** as plain markdown links: `[vault-short:page-slug](obsidian://open?vault=llm-wiki-&file=)`. Do NOT use `[[vault:page]]` wikilink form (unresolved-red, bad UX). - **The calibration table is the most valuable artefact.** Fill it even if thin — one or two rows is better than none. - **Link every artefact the session produced** under `related` so the session note becomes a hub in the graph. - **Date in filename.** Format: `session-notes--.md`. One session note per day per topic; if two sessions cover the same topic in one day, append `-a`, `-b`. ## Why this source-type exists Most Claude Code sessions produce artefacts but not paper trail. When the user comes back in three months and asks "why did I change my LinkedIn to say X?", the CV / bio / cover files don't answer — the *reasoning* lived in the conversation and is lost. Session notes capture the reasoning in a format that travels: decisions, rejected alternatives, and learnings that should inform future generations. It's the mirror of `rough-notes`: rough-notes captures a meeting *with someone else*; ingest-session captures a working session *with Claude*.