note-wrapup
Skill1 starsChanged 9 months agoMITView on GitHub
Generate a session summary with handoff notes for next session
In this repository10 other files it gives its agents.
- note-bugSkill
- note-contextSkill
- note-decideSkill
- note-findSkill
- note-loopSkill
- note-meetingSkill
- noteSkill
- note-snippetSkill
- note-standupSkill
- note-todoSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 10 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 32
If found → save its id — will use mcp__slashnote__update_note in Step 3 instead of creating new
- Distinctive: line 33
If not found → will create a new note in Step 3
- Distinctive: line 44
Read note-loop note if exists → task progress
- Distinctive: line 45
Read loop state file if exists → blocked/remaining tasks
- Distinctive: line 46
Read recent decision notes (green) → decisions made this session
- Distinctive: line 47
Read recent bug notes (pink) → known issues
- Very specific: line 106
If Step 0 found an existing wrapup from current session (< 3 hours) → update it with mcp__slashnote__update_note
- Distinctive: line 120
Omit: if no decisions were made
- Distinctive: line 140
Omit: if no risks identified — don't invent problems
- Distinctive: line 179
Don't repeat info across sections
- Distinctive: line 181
If user provides extra context → add as first item in relevant section
- Distinctive: line 182
If loop was active → include progress in "Done"
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/note-wrapup — Session Summary
Generate an end-of-session summary with handoff notes.
Usage
/note-wrapup # Full analysis (git + notes + conversation)
/note-wrapup --notes # Notes-only mode (no git required)
/note-wrapup <additional context> # Add extra context to the summaryBehavior
Step 0: Find existing wrapup to update
mcp__slashnote__search_noteswith query "Wrapup"- Among results, find one where
previewstarts with "Wrapup" ANDupdatedAtis less than 3 hours ago - If found → save its
id— will usemcp__slashnote__update_notein Step 3 instead of creating new - If not found → will create a new note in Step 3
Step 1: Collect data
Git data (skip if --notes or not in a git repo):
echo "LOG:" && git log --oneline -10 2>/dev/null && echo "---DIFF---" && git diff --stat 2>/dev/null && echo "---STAGED---" && git diff --staged --stat 2>/dev/null && echo "---BRANCH---" && git rev-parse --abbrev-ref HEAD 2>/dev/nullSlashNote data (always collected):
mcp__slashnote__list_notes— overview of all notes- Read note-loop note if exists → task progress
- Read loop state file if exists → blocked/remaining tasks
- Read recent decision notes (green) → decisions made this session
- Read recent bug notes (pink) → known issues
Conversation context (always available):
- Tasks discussed and completed
- Decisions made
- Issues encountered
- Files modified
Step 2: Generate summary
Full Mode (git + notes)
# Wrapup <date>
## Done
- <completed work — from git commits + note checkboxes>
- <loop progress if applicable: "/note-loop: N/M tasks">
## Decisions
- <decisions made this session — from /note-decide notes>
## Changed
- <file areas modified — from git diff --stat>
- <uncommitted changes warning if any>
## Open
- <uncompleted tasks, open bugs>
- <uncommitted/unstaged changes>
## Risks
- <potential issues for next session>
## Next
- <exact next steps with file:line references>
- <pending reviews or PRs>Notes-Only Mode (--notes)
# Wrapup <date>
## Done
- <completed items from note checkboxes>
- <decisions made (from decision notes)>
## Open
- <in-progress items from notes>
- <unchecked note-loop items>
## Next
- <specific next steps based on remaining work>Step 3: Create or update note
- Color: green
- Pinned: false
- If Step 0 found an existing wrapup from current session (< 3 hours) → update it with
mcp__slashnote__update_note - Otherwise → create new with
mcp__slashnote__create_note
Section Details
"Done" — What was accomplished
- Group related commits (same pattern as /note-standup)
- Include completed checkbox items from notes
- Include loop progress: "/note-loop: 9/12 tasks completed"
- This is a record — only things actually done
"Decisions" — Choices made this session
- Source from green decision notes created during this session
- Format: one-liner per decision (title from note)
- Omit if no decisions were made
- Cross-reference with git to see if decisions were implemented
"Changed" — Files and areas modified
- From
git diff --stat(both staged and unstaged) - Group by directory/module if many files
- Flag uncommitted changes: "3 files with uncommitted changes"
- Omit in notes-only mode
"Open" — Unfinished work
- Uncommitted/unstaged file changes
- In-progress checkbox items
- Open bugs (pink notes from this session)
- Blocked loop tasks (from state file)
"Risks" — Watch out for
- Uncommitted changes that could be lost
- Blocked tasks that need external input
- Failing tests mentioned in conversation
- Known bugs that could affect next work
- Omit if no risks identified — don't invent problems
"Next" — THE handoff section
This is the most important section. It must be specific enough for a fresh session to pick up immediately.
Quality bar — each item should answer: "What file, what function, what's left to do?"
Good:
- "Continue
validateToken()inauth.swift:45— JWT parsing done, need expiry check" - "Run tests after fixing flaky WebSocket test in
ws.test.ts" - "PR #42 needs one more review — Alice approved"
Bad:
- "Keep working on auth"
- "Fix bugs"
- "Continue development"
Analysis Intelligence
Cross-reference data sources for richer summary:
| Cross-Reference | Intelligence |
| Git commits ↔ Note checkboxes | If commit matches checkbox → confidently "Done" |
git diff ↔ Open tasks | Modified files show WIP areas |
| Decision notes ↔ Commits | Decisions that were already implemented |
| Bug notes ↔ Open items | Known issues that block next steps |
| Loop state ↔ /note-loop note | Accurate progress tracking |
| Staged vs unstaged | What's ready to commit vs still WIP |
Rules
- One Bash call max for git data
- "Done" = actual work (verifiable from git/notes), not plans
- "Changed" = actual files from
git diff --stat - "Open" = truly open work, not general TODOs
- "Risks" = real identified risks, not hypotheticals
- "Next" = specific, actionable, with file/function references
- 3-5 items per section max
- Don't repeat info across sections
- Date: "Feb 19, 2026"
- If user provides extra context → add as first item in relevant section
- If loop was active → include progress in "Done"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

