wrap-up

name

wrap-up

description

Use to end a work session cleanly — syncs findings to your Obsidian vault (or any Markdown notes folder), updates the agent's persistent memory, marks tasks complete, and prints a handoff summary so the chat can be closed without losing context. Triggers on "/wrap-up", "wrap up", "close out", "end session", "ready to close chat", "save and close", "prep close", "sync and close". This is the safety net for the "always update my notes when a task finishes" rule — call it any time you want everything synced before walking away.

Wrap Up — Session Close-Out

Purpose

Sync everything from the current chat session into your second brain (an Obsidian vault, or any folder of Markdown notes) plus the agent's persistent memory, then produce a clean handoff so you can close the chat without losing context.

The problem this solves: AI coding sessions accumulate decisions, file paths, vendor quirks, and "next step" intentions that evaporate the moment the chat closes. The next session starts cold and you spend 30–45 minutes reconstructing state from git history and memory. This skill writes that state down — durably, in the same place every time — before you walk away.

Trigger

User types /wrap-up, says "wrap up", "close out", "end session", "ready to close this chat", "save and close", or similar.

Configuration

Before first use, set two paths. Either hardcode them at the top of this file, or — better — add them to your global agent instructions (e.g. CLAUDE.md, .cursorrules) so every session knows them:

• VAULT_ROOT — absolute path to your notes vault. Example: ~/Documents/vault or C:/Users/you/OneDrive/vault.
• MEMORY_DIR — the agent's persistent memory directory. For Claude Code this is ~/.claude/projects/<project-slug>/memory/ with a MEMORY.md index. If your agent has no persistent memory, skip Step 4 and put everything in the vault.

If neither is set when this skill runs, ask the user once for the vault path, then proceed.

Required Workflow

Do all 6 steps in order. Do NOT skip steps even for short sessions — the value of this skill is reliability. A wrap-up you can trust every time beats a thorough one you only run sometimes.

Step 1 — Identify what happened in the session

Review the conversation and list:

• Project(s) worked on (name and 1-line description)
• Files created or modified — full paths
• Decisions made (especially non-obvious ones, vendor calls, scope changes)
• Open follow-ups / blockers / "next session would be" notes
• New facts that future-you would want to remember (surprising findings, data corrections, confirmed preferences)

If multiple unrelated projects were touched, list each separately and handle each in steps 3–4. Do NOT merge unrelated work into a single note.

Step 2 — Determine vault location per project

Vault root: VAULT_ROOT (see Configuration).

Always check if a folder already exists before creating a new one. Reuse the existing path. Consistency is the whole point — the same project must land in the same place every session, or the second brain fragments.

A sensible default taxonomy (adapt to your own):

Folder	Purpose
projects/	Your own project work — one subfolder per project
clients/<client>/	Contracted / employer work, one subfolder per client
references/	External tools, APIs, services, audits — single-file notes or topic clusters
people/	One note per person
daily/	Date-prefixed daily journal
learning/	Continuous mastery trackers

If you use a status-prefix convention (e.g. projects/00-active/, 10-paused/, 20-archive/), respect it — put new work under the active prefix and move folders between prefixes as status changes.

Naming rules:

• kebab-case, lowercase, for all folder names. No spaces, no Title Case.
• README.md at each project-folder root.
• Date-prefix dated artifacts: 2026-05-01-run-notes.md.
• When in doubt, search the vault for an existing folder before creating a new one.

Step 3 — Update or create the project README

Path: <vault project folder>/README.md

Frontmatter (so future agents can filter by grep status: active, last-touched, tags):

---
status: active | paused | archived
last-touched: YYYY-MM-DD
tags: [...]
type: project            # optional
code: ../../_repos/<repo>/   # optional, if a separate code repo exists
---

If the README exists: update last-touched, refresh the Status section, append a dated bullet under the Decisions log, fix any file paths that moved, update Open items / Resume instructions. Do not delete prior content unless it's now wrong.

If the README is new (verify by listing the parent folder first): include the frontmatter above plus:

• # Project Name + one-line purpose
• ## Status — what shipped, what's blocked, what's next (1–3 bullets)
• ## Key artifacts — links to deliverables, code paths, external resources
• ## Decisions log — dated bullets: YYYY-MM-DD — decision, why
• ## Files produced — paths + 1-line description per file
• ## Open items / follow-ups — bulleted list (or "none")
• ## Resume instructions — for future-you: "exact next step when you reopen this"
• ## Related — cross-references (use [[wiki-links]] in Obsidian) including the memory entry and the parent category index

If the work warrants more than a README (a design spec, a runbook, a session log), create separate .md files alongside it using YYYY-MM-DD-<topic>.md and link them from the README.

Step 4 — Update persistent memory

Memory location: MEMORY_DIR (see Configuration). Skip this step if your agent has no persistent memory — the vault README already holds the durable record.

Two-step pattern:

1. If the work is substantial (created something, made decisions, shipped a deliverable, found something non-obvious): create or update MEMORY_DIR/project_<slug>.md with frontmatter (name, description, type: project) and a fact-dense, dated body with file paths.

2. Always: add or update a one-line pointer in MEMORY_DIR/MEMORY.md (the index loaded each session). Format: - [project_<slug>.md](project_<slug>.md) — <one-line hook>.

Keep the index lean — prune older bullets before adding if a section is getting long.

DON'T memorize (it's derivable or ephemeral):

• File paths, code structure, architecture — read the code
• Git history / who-changed-what — use git log
• Anything already in your global instructions
• In-progress task details for the current conversation

DO memorize:

• Project state and dates ("delivered X on YYYY-MM-DD", "Phase 1 complete")
• Surprising findings (vendor data was wrong, scope mismatch, a non-obvious bug)
• User preferences confirmed during the session
• External resource pointers (project-tracker links, dashboards, channels)

Step 5 — Mark task list completed

If a task list was used this session, review it. Any items actually finished but still showing pending or in_progress → mark completed. Genuinely unfinished items stay open — capture them in the Resume instructions.

Step 6 — Print close-out summary

One concise message back to the user:

Wrapped up — ready to close.

What got done:
- <bullets, terse>

Files produced / modified:
- <full paths, grouped by project if multi>

Open items / next session:
- <bullets, or "none">

Resume by: <one-line — where to start next time>

Vault: <path to README(s) updated>
Memory: <path to project_<slug>.md if created/updated>

Keep this under 200 words even for big sessions. If the user wants more, the README has it.

What this skill does NOT do

• Commit or push to git (the user controls when)
• Send messages, emails, or external notifications
• Run dangerous or irreversible actions
• Skip steps for "small" sessions — even short sessions get all 6 steps

When to invoke this skill yourself (proactive)

If the user signals end-of-session ("I need to step away", "let's stop here", "I'll come back to this tomorrow", "thanks, that's enough for today"), prompt to wrap up — do NOT auto-run the workflow without confirmation:

"Want me to /wrap-up before you go?"