# Done > Use when ending a session, wrapping up work, or when the user says "done", "wrap up", "let's commit", or "end of session". Summarizes work, updates docs, and commits. - Skill: `musserlab/done` (Agent Skill) - Install (CLI): `npx skillmds@latest add musserlab/done` - Raw SKILL.md: https://api.skillmd.com/api/skills/musserlab/done/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: MusserLab (https://skillmd.com/u/musserlab) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/musserlab/done --- # End of Session Wrap-up When the user invokes `/done`, perform these end-of-session tasks in order. --- ## 0. Detect Project Type Check the project's `.claude/CLAUDE.md` for a `project-type:` field: - **`data-science`** — Full wrap-up including all steps - **`general`** (or no field found) — Skip steps marked **[Data Science only]** If no field exists, infer: `renv.lock`, `outs/`, or numbered `XX_*.qmd` scripts → data science. Otherwise → general. **Collaborator mode** — `` (optional): - For **repos you don't own** (e.g. a student's project you're reviewing). Set it in your personal `CLAUDE.local.md` so it applies only to you, not the repo owner. - In collaborator mode, `/done` keeps your session-management artifacts **private to your clone**: - **Session log** (Step 1b) → appended to `CLAUDE.local.md`, not the shared `.claude/CLAUDE.md`. - **No auto-push** (Step 4) → commit locally, then `/done` **does the push-vs-hold triage for you and recommends a set to push** (one-line rationale each); you approve or adjust rather than adjudicating file-by-file. Nothing is pushed without your OK, and nothing pushable is silently left behind. - **Private plans/reports** (`.claude/local/`) → update as normal but never commit them (the folder is gitignored locally); register them in `CLAUDE.local.md`, not the shared `.claude/CLAUDE.md`. **Push-vs-hold triage** — Claude runs this classification and **recommends a push set**; the user approves or adjusts (they don't decide each file). Default to a recommendation; only ask about genuinely ambiguous items: - *Lean push* (accurate, ready, helps the student/repo): shared docs (`.claude/CLAUDE.md`, `project_plan.md`/`project_summary.md`, `docs/feedback/`), shared inputs (`data/`), reference/lookup files, finished scripts or analysis, and doc-accuracy fixes. - *Lean hold* (not ready / personal): work-in-progress `scripts//`, drafts, prototypes — anything you'd only share once polished. - *Already private* (gitignored — never in a commit anyway): `.claude/local/`, `outs//`, `CLAUDE.local.md`. - Ask only about the genuinely ambiguous items — recommend the clear ones. The final call is always the user's. - Granular alternative: `` disables only the auto-push and leaves the rest normal. > Also read `CLAUDE.local.md` (gitignored, personal) for these markers — it overrides `.claude/CLAUDE.md`, so a collaborator can set personal wrap-up behavior without touching the shared repo. --- ## 0b. Load Project Extensions Check if `.claude/done_extensions.md` exists in the project root. If it does, read it and incorporate its steps into the wrap-up at the points it specifies (e.g., "run after Step 2" or "run before Step 4"). Extension steps are additional — they never replace core steps. If no extension file exists, skip silently. --- ## 1. Summarize Work and Decisions Briefly list what was completed this session: - Scripts created or modified - Data files created or modified - Documentation changes - Key analytical or design decisions made --- ## 1b. Update Session Log in Project CLAUDE.md Append a new entry to the **Session Log** section at the bottom of the project's `.claude/CLAUDE.md`. This is a rolling log of the last 5 sessions — it's the primary place future sessions look for "what to do next." > **Collaborator mode (Step 0):** append the session log to your private `CLAUDE.local.md` instead of the shared `.claude/CLAUDE.md` — same format and same last-5 trim — so your entries stay in your clone and don't reach the repo owner. ### Format ```markdown ## Session Log ### YYYY-MM-DD — Short title - **Plans:** [plan name(s) worked on, or "None"] - **Work:** [1-2 sentences on what was done] - **Next:** [bullet list of follow-up items for future sessions] ``` ### Rules - **Most recent first** — new entry goes at the top of the list - **Same-day updates** — if an entry for today's date already exists (from an earlier `/done` run in this session), **replace it** rather than adding a duplicate. Merge the work descriptions and update the Next items. This allows `/done` to be run multiple times per session without cluttering the log. - **Trim to 5 entries** — delete the oldest entry if there are more than 5 - **Short title** should disambiguate from parallel sessions (e.g., "Metadata exploration", "WGCNA figures", "Environment setup") - **Same-day session numbering** — when multiple sessions occur on the same date, number them: `### 2026-03-22 (session 1) — Title`, `### 2026-03-22 (session 2) — Title`, etc. This makes the log scannable when intensive work produces multiple sessions per day. The number reflects chronological order within that day. - **Plans line** — list which planning documents were worked on (e.g., "`figure_plan.md`"). Write "None" if no plans were involved. This helps track work that falls outside of plans. - **Next items** — these are the main value. Be specific and actionable. They accumulate across sessions until actually done — don't repeat items already listed in a recent entry unless context changed. - If the Session Log section doesn't exist yet, create it at the bottom of the file (before any closing comments). --- ## 2. Update Relevant Planning Documents Only update planning documents **directly relevant to this session's work**. Do NOT read all registered documents — identify the 1-2 that matter from session context. For each relevant planning document: **a. Status tables** — Mark completed phases/tasks. Add new phases if needed. When a phase is marked complete, collapse its detailed content to a 3-5 line summary (what was done, key outcomes). Before collapsing, ensure any forward-looking information needed by future phases is already captured elsewhere in the plan. **b. Script and file tracking** — Add new scripts, mark replaced ones as legacy, update modified entries. **c. Task lists** — Check/uncheck items as appropriate. Show proposed changes before editing. ### Also check Claude Code plan files If a plan file from plan mode exists in `~/.claude/plans/` and is relevant: - Update status tables, file tracking, task checklists - If it contains significant multi-session tracking, suggest promoting to a registered `.claude/` document --- ## 3. Update Project Documentation (if needed) Only do these checks if the session actually changed something relevant. Skip silently otherwise. ### Canonical Data Files Registry [Data Science only] If canonical data files were created, replaced, or had format changes: - Update CURRENT/Legacy status entries - Add new files that should be tracked - Show proposed changes before editing ### Project CLAUDE.md If new conventions, gotchas, or important patterns were discovered this session, propose additions. Only record things that are **surprising or counter-default** — skip anything Claude would infer from the codebase. ### MEMORY.md If reusable lessons or gotchas were discovered, or existing entries proved wrong/outdated, propose updates. Keep under 200 lines. ### New `.claude/*.md` files If new `.claude/*.md` files were created this session, add them to the Project Document Registry. ### CHANGELOG.md If the project has a `CHANGELOG.md` in its root directory: - Review what was done this session - Propose a changelog entry under today's date, using the existing format (Added/Changed/Fixed/Removed sections as appropriate) - If today's date already has an entry, append to it rather than creating a duplicate - Show proposed changes before editing - If no `CHANGELOG.md` exists, skip silently — do not suggest creating one --- ## 3b. Capture SLURM Resource Profiles [Cluster only] **Run only on the HPC cluster.** Guard: if `command -v sacct` fails (e.g., on local macOS), skip this step **silently** — it does not apply off-cluster. If SLURM batch jobs were submitted **and completed** this session, capture their observed usage so future jobs can be right-sized instead of re-discovering it: 1. For each distinct tool / job type run this session, pull empirical usage: `jobstats ` (or `seff ` / `sacct -j --format=Elapsed,MaxRSS,ReqMem,AllocCPUS,State`). Record peak memory, CPU efficiency, elapsed walltime, **and the input scale** (e.g. read/sequence count) — the scale is what makes the number reusable. 2. Record the right-sized CPUs / Memory / Time / Partition (with observed peak mem + efficiency + input scale) where your project keeps its resource notes — e.g. a comment in the batch script or a project planning doc — so the next run starts from the right ballpark. 3. Only bother when the numbers **refine** what you already knew — don't churn notes for trivial re-runs or jobs you didn't right-size. --- ## 4. Git Commit ### Project repository Run `git status` to check for uncommitted changes. If there are changes: - **CRITICAL: Only include files actually created or modified during THIS session** - **CRITICAL: Always stage specific files by name (`git add file1 file2`), NEVER use `git add .` or `git add -A` for the project repo** — broad staging will pick up changes from parallel Claude Code sessions - **Identifying session files** — use multiple sources, not just git diff: 1. **Conversation context** is the primary record of what you did — including compacted/summarized earlier portions of the conversation 2. **Git diff** (initial gitStatus vs current `git status`) is a cross-check — files appearing in current but not initial are *candidates* but not certainties 3. **Parallel conversations can create files** — another Claude Code session running simultaneously may have added files that show up in your git diff but were NOT created by this conversation 4. **When uncertain about a file's origin, ask the user** — do not silently include or exclude files you can't account for from conversation context - Files already in initial gitStatus should NOT be included unless you worked on them - Show the user session-relevant files and suggest a commit message - If approved, commit only those files - After committing, push to remote automatically (`git push`) — **unless collaborator mode or `done-autopush: false` is set** (see Step 0; typically in `CLAUDE.local.md` for collaborative repos). If auto-push is off, do NOT push automatically — but DO surface and **pre-triage** the decision: gather every local commit not yet on the remote (`git log @{u}..HEAD --oneline`), this session's and any earlier unpushed ones, classify each with the push-vs-hold heuristics (Step 0), and present a **recommended push set** and a **hold set** with a one-line reason each. Ask the user to approve or tweak the recommendation — Claude does the legwork; the user doesn't adjudicate every file. The final call is theirs. Only ask the user if an attempted push fails (e.g., rejected by remote, no remote configured). ### User config (`~/.claude`) Check for uncommitted changes: ```bash git -C ~/.claude status --short ``` If there are changes (skills, CLAUDE.md, etc.): - Show what changed - Ask if user wants to commit. Push automatically after — only ask if push fails - If yes, run these as separate sequential Bash calls (do NOT chain with `&&`): 1. `git -C ~/.claude add -A` 2. `git -C ~/.claude commit -m "Title" -m "Co-Authored-By: Claude "` (use multiple `-m` flags, NOT heredocs) 3. `git -C ~/.claude push` **Skill registration check:** If new skills were created in `~/.claude/skills/` this session, verify each appears in the Available Skills table in `~/.claude/CLAUDE.md`. If any are missing, add them before committing. **Sync reminder:** After committing, check if `~/.claude/.sync-canonical/` exists (indicates a two-repo sync setup). If it does, compare the cluster repo HEAD against the canonical staging HEAD. If they differ: > "You have changes in `~/.claude` that haven't been synced to canonical. Run `/sync-cluster` now to review and push them." If on the cluster, offer to run it immediately. If on macOS (canonical machine), remind the user to run `/sync-cluster` on the cluster next time they're there — macOS mode only pulls, it can't push cluster changes to canonical. Do NOT run `/sync-cluster` automatically — it's an interactive skill that requires decisions about what to push/modify/skip. ### Conditional: Conda environment drift check [Data Science only] Only if conda **or pip** packages were installed/updated this session. Do NOT blindly overwrite `environment.yml` (it's hand-curated and grouped) — detect drift and reconcile. 1. List what's actually in the env — **both** conda and pip: ```bash conda env export --from-history # conda (explicit installs) conda list | awk 'NR>3 && $NF=="pypi" {print $1"=="$2}' # pip-installed (channel = pypi) ``` `--from-history` does **not** include pip packages — that's why the second command is required. Skipping it silently drops pip installs from the spec. 2. Compare the union against `environment.yml` (its `dependencies:` list **and** its `pip:` subsection). Identify packages in the env but not in the spec (and vice versa). 3. If drift exists, show the diff and propose the exact lines to add, then ask: "environment.yml is missing these packages — add them?" - conda packages → add under `dependencies:` - pip-only packages → add under a `pip:` subsection (ensure `pip` is a conda dependency) 4. Apply the agreed edits to the hand-curated file (preserve grouping/comments). Keep out: the `prefix:` line and `defaults` channel; verify `conda-forge` is present. 5. Include the updated `environment.yml` in the commit. Reconcile the curated file rather than replacing it with a full `conda env export`, which records pinned, platform-specific build strings that aren't portable. ### Conditional: renv snapshot [Data Science only] Only if R packages were installed or updated during this session: ```bash Rscript -e "renv::status()" 2>/dev/null ``` If out of sync, ask about `renv::snapshot()`. Include updated `renv.lock` in the commit. ### Conditional: Quarto publish Check if this is a publishable Quarto project (all three must be true): 1. `_quarto.yml` exists 2. It's a book or website (`type: book` or `type: website`) 3. `gh-pages` branch exists If yes, ask: "This is a Quarto book/website with GitHub Pages. Publish now?" Do NOT offer for regular `.qmd` analysis scripts, projects without `gh-pages`, or `type: default`. --- ## 5. Final Summary Brief "Session complete" message listing: - Files created/modified - Commits made - Planning documents updated - Any follow-up items for next session