session-wrap
Skill1 starsChanged 4 months agoMITView on GitHub
Mandatory end-of-session sync protocol. Reviews changes and proposes updates across all systems.
13 other projects use a version of this.
Adopted by
Most recently taken up by
- catesandrew/skillstheir own version, first seen Nov 1, 2026
- itgenius-au/skills-librarytheir own version, first seen Oct 30, 2026
- aberson/skill-meshtheir own version, first seen Oct 24, 2026
- pinetreelic/codex-skillstheir own version, first seen Sep 14, 2026
- Kashyap-001/second-brain-templatetheir own version, first seen Jul 23, 2026
- syugoji/agent-skills-packtheir own version, first seen Jul 22, 2026
Other versions13 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 13
- ai-native-camp/camp-2★ 19same name
- leonsong09/session-wrap★ 9same name
- immacualate/claude-forge★ 5same name
- aberson/skill-mesh★ 2same name
- dawish39/session-wrap★ 2same name
- borgesme/fastapi-general-template★ 1same name
- catesandrew/skills★ 1same name
- itgenius-au/skills-library★ 1same name
- Kashyap-001/second-brain-template★ 0same name
- kingkingburger/ai-control-tower★ 0same name
3 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository22 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- commsSkill
- composeSkill
- daily-briefSkill
- domain-hygieneSkill
- grill-meSkill
- idea-deep-diveSkill
- laila-headless-conductSkill
- laila-judgmentSkill
- laila-ops-debuggingSkill
- level-upSkill
- new-domainSkill
- os-auditSkill
- personaSkill
- quarterly-refreshSkill
- roastSkill
- running-briefSkill
- setupSkill
- specSkill
- validate-ideaSkill
- whats-nextSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 4 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
Goals (FIRST): Update goal progress in whatever system is authoritative for goals, then regenerate any exported goals file.
- Distinctive: line 46
If nothing changed during the session, explicitly state: "No sync needed this session — no state changes."
- Distinctive: line 55
Capture skill corrections: if Alex manually corrected any skill's output this session, log the correction (skill name, one-line …
- Distinctive: line 98
Update tasks worked on this session
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Session Wrap Skill
MANDATORY before ending ANY session. Skipping this is how things get dropped.
Workflow
Step 1: Review what changed this session. Identify:
- Tasks completed or discovered
- Status changes (projects, pursuits, domain items)
- New information that affects goals or priorities
- Files that were read but not updated with new info
Step 2: Propose a sync table covering ALL affected systems:
**Session Sync:**
| System | Action | Detail |
|--------|--------|--------|
| Task system | check/add | Complete done items, add new action items |
| CRM / pipeline | update/add | Update pipeline stages, create new records |
| status.md | update | Update changed domain tracking files |
| Goals | update | Update goal progress |
| strategy.md | flag | Flag priority shifts (rare) |What to check (system-of-record-first sync order):
- Task system: Complete done items, add new action items, reschedule overdue ones. (Query your task/reminders system here — Apple Reminders, Todoist, a CRM task object, etc.)
- Pipeline / CRM records (FIRST): If a domain keeps its pipeline in an external system (e.g. the career domain's prospect pipeline in a CRM), update stages there first, then regenerate any derived tracking files from it. The external system is authoritative; the markdown file is the export.
- Goals (FIRST): Update goal progress in whatever system is authoritative for goals, then regenerate any exported goals file.
- Domain status.md: Update
domains/<name>/tracking/status.mdfor any domain whose status changed (new info, completed items, blockers resolved). MANDATORY stamp: any domain whose files were touched this session gets itstracking/status.md"Last updated" header stamped with today's date — even if the status content itself didn't change. - state/strategy.md: Flag if strategic priorities shifted (rare — only when focus areas change).
The full cross-system sync checklist lives in templates/sync-protocol.md — every trigger skill executes it; session wrap is its final guaranteed pass.
Step 3: Wait for Approval — Do NOT execute until Alex confirms. They may modify, add, or remove items.
Step 4: Execute Approved Changes — task system via its skill/CLI, files via Edit/Write, external systems via their integrations.
If nothing changed during the session, explicitly state: "No sync needed this session — no state changes."
Memory System Amendment
In addition to the sync above, ALSO:
- Append a session log to today's daily note (
state/daily-notes/YYYY-MM-DD.md) - Update active projects in the daily note (check off completed, add new, note owner: Alex or Laila)
- Flag knowledge updates that nightly consolidation should process
- Log decisions: if any decisions were made this session, append them to
knowledge/decisions/YYYY-MM.mdin the established format (or dispatch a decision-logger subagent with a summary of the session's decisions + today's date, if one is configured). Include the "entries appended" list in the wrap output. Skip if the session made no decisions. - Capture skill corrections: if Alex manually corrected any skill's output this session, log the correction (skill name, one-line description, date) so your weekly improvement ritual can review it.
Write/update the session handoff (
PROGRESS.md): every session maintains aPROGRESS.mdin the primary domain/repo worked on this session (e.g.domains/<domain>/PROGRESS.md, or the repo root for a code-heavy domain). It is a pass-off doc so another agent/session can resume cleanly — the audience is the next instance of you, not a stakeholder. At session start, read the relevantPROGRESS.mdfirst if one exists.Synthesize it from what actually happened THIS session — review the full conversation, not just the last few turns (handoffs miss things when they only summarize recent context). Keep it short and CURRENT: overwrite stale content, do not append-log. Use this stable structure every time; if a section has nothing to report, write "none" rather than dropping it — structure stability is the whole point:
# PROGRESS — <primary domain/repo> — updated YYYY-MM-DD ## TL;DR <2-3 sentences: what this session was about + where it now stands> ## Decisions locked + what shipped - <decision/change> — <why; absolute path if a file; commit + test status> ## Key findings - <non-obvious fact the next agent needs> — or "none" ## Key files for next session - `<absolute path>` — <why read this first> - Plan file: `<path>` — name it FIRST if a plan drove the session ## Running right now - Background jobs: <IDs + what + how to check + how to kill> — or "none" - Dev servers / ports: <url + port> — or "none" - Worktrees / branches: <paths> — or "none" ## Verification — how to confirm it still works - `<command>` — <expected outcome> ## Deferred + open questions - Deferred: <item> — <why pushed to later> - Open: <question needing Alex's input> — <context> ## Pick up here <1-2 sentences: the single most likely next action for a fresh agent>Hard rules: absolute paths always (the next agent may have a different working directory); never invent state — write "none" rather than omit a section; background job / server IDs are load-bearing, so include how to check AND how to kill them; verification is concrete commands + expected outcomes, not prose; terse end-of-shift-engineer tone — no emojis, no hype, no "what went well" retrospective.
Active Task Update
Also during session wrap:
- Review
state/active-tasks.json - Update tasks worked on this session
- Add new multi-session tasks with the correct owner (
owner: alex= Alex works, Laila reminds;owner: laila= Laila monitors/executes) — mint the next task ID programmatically, never pick it by hand. Parse every existing ID, take the numeric maximum, add one. Eyeballing "last entry + 1" fails silently the moment a non-numeric or out-of-order ID exists in the file, and a collided ID splits one task's references across two unrelated records. - Close completed tasks (move to the
completedarray) - Lint before finishing — re-scan the file for duplicate IDs and missing required fields so collisions are caught the same session, not weeks later.
If a duplicate is found: the ID stays with whichever task owns the live external references (grep for it), and the other task renumbers. Repoint live pointers (memory files, status.md, PROGRESS.md) but leave dated daily notes and the decision log alone — those are a record of what was true then, not pointers to fix.
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.

