wrap-all
Skill0 starsChanged 5 months agoMITView on GitHub
End-of-session ritual across EVERY repo on this machine — for each git repo under the scan root with uncommitted or unpushed work, run the full wrap ritual (summarize, commit, push, handoff). Use when the user says "wrap all", "wrap everything", "/wrap-all", or wants to close out every repo at once. NOTE — a skill runs only in the current session; it cannot drive other live Claude Code sessions, it wraps repos on disk.
- Reads credentials
In this repository57 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- ask-mattSkill
- cast-memberSkill
- check-feedbackSkill
- codebase-designSkill
- content-pipeline-initSkill
- content-pipelineSkill
- data-analystSkill
- decision-mappingSkill
- diagnosing-bugsSkill
- domain-modelingSkill
- draft-asset-promptsSkill
- edit-articleSkill
- fableSkill
- game-concept-interviewSkill
- git-guardrails-claude-codeSkill
- global-guidelinesSkill
- grillingSkill
- grill-meSkill
- grill-with-docsSkill
- handoffSkill
- implementSkill
- improve-codebase-architectureSkill
- karpathy-guidelinesSkill
- launch-sessionSkill
- lesson-reviewSkill
- link-claude-skillsSkill
- loop-meSkill
- migrate-to-shoehornSkill
- obsidian-vaultSkill
- opusSkill
- prototypeSkill
- publish-metadataSkill
- resolving-merge-conflictsSkill
- retrieve-lessonsSkill
- reviewSkill
- rotate-sessionSkill
- run-buildSkill
- run-clipsSkill
- scaffold-exercisesSkill
- session-sandboxSkill
- setup-matt-pocock-skillsSkill
- setup-pre-commitSkill
- setup-status-lineSkill
- showrunner-shortSkill
- sonnetSkill
- tddSkill
- teachSkill
- to-issuesSkill
- to-prdSkill
- triageSkill
- verify-outputsSkill
- wrapSkill
- writing-beatsSkill
- writing-fragmentsSkill
- writing-great-skillsSkill
- writing-shapeSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
If the user named a root, use that.
- Distinctive: line 36
Do NOT auto-wrap a repo that is mid-operation or can't safely push.
- Distinctive: line 40
no upstream / no remote configured,
- Very specific: line 48
Honor the repo's own convention first: If that repo's CLAUDE.md defines a custom wrap ritual, follow it exactly for that repo instead of …
- Very specific: line 57
Read the newest .jsonl (these can be multi-MB — tail it / extract the last user+ assistant turns rather than loading the whole file) to see …
- Distinctive: line 61
If no transcript is found or it's unreadable, summarize honestly from git diff / git log and say the wrap was a bulk close-out (don't …
- Distinctive: line 68
Follow this repo's commit trailer/signing rules if it has them.
- Very specific: line 73
Update a ## Next Session section (what changed, what's next, blockers, suggested skills).
- Very specific: line 74
Commit only that file with message docs: handoff notes for next session, then push immediately.
- Distinctive: line 77
Keep going even if one repo fails — record the failure and move on.
≈ “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
Wrap every repo on this machine that has outstanding work. A skill runs inside the current session only — it cannot reach into other running Claude Code sessions. What it does instead is walk the repos on disk and wrap each one. Never save notes to OS temp or claude memory — everything ends up committed and pushed.
Scan root
If the user named a root, use that. Otherwise read SCAN_ROOT from this skills repo's .env,
prompting for it on first use and storing the answer — a scan root is machine-specific, so it
is never hardcoded here:
SCAN_ROOT="$(python lib/skillconfig.py get SCAN_ROOT --repo <skills-repo> --prompt 'Repo scan root')"Each immediate subfolder of that root containing a .git is a repo.
1. Enumerate repos with outstanding work
List every git repo directly under the scan root. For each, check:
- uncommitted changes (
git status --porcelainnon-empty), and/or - unpushed commits (
git log @{u}..non-empty, when an upstream exists).
Build the working set = repos that have either. Skip clean+pushed repos silently.
Report the working set to the user before acting — a short list of repos and why each is included (dirty / unpushed / both). This is the plan.
2. Set aside repos that need a human
Do NOT auto-wrap a repo that is mid-operation or can't safely push. Instead list it separately for the user to handle manually:
- an in-progress merge/rebase/cherry-pick (
.git/MERGE_HEAD,rebase-*dirs), - detached HEAD,
- no upstream / no remote configured,
- the current branch is the default branch AND the repo's own
CLAUDE.mdsays branch-first (respect each repo's rules).
3. Wrap each remaining repo, one at a time
For each repo in the working set, run its wrap ritual from that repo's directory:
- Honor the repo's own convention first. If that repo's
CLAUDE.mddefines a customwrapritual, follow it exactly for that repo instead of the steps below. - Summarize. For the repo you actually worked in this session, summarize from the
conversation. For the others, recover context from that repo's saved session transcripts
before falling back to the diff:
- Transcripts live at
~/.claude/projects/<enc>/<session-uuid>.jsonl, where<enc>is the repo's absolute path with every non-alphanumeric char replaced by-(e.g.D:\Work\my-project→D--Work-my-project). If several project folders could match, pick the one with the most recent.jsonl. - Read the newest
.jsonl(these can be multi-MB — tail it / extract the last user+ assistant turns rather than loading the whole file) to see what that session was doing. - These are persisted transcripts, not the live memory of a still-running session, so the final turns of an active session may not be flushed yet. Note that if it matters.
- If no transcript is found or it's unreadable, summarize honestly from
git diff/git logand say the wrap was a bulk close-out (don't invent intent).
- Transcripts live at
- Update existing logs only (changelog / worklog / TODO-DONE / ADR /
.changeset/), consistent with that repo's format. Do not create a new log file. - Commit. Stage intentionally by inspecting
git status— never a blanketgit add -A. Match the repo's existing commit-message style. If changes look half-finished or experimental, still commit (that's the point of a wrap) but say so in the message body. Follow this repo's commit trailer/signing rules if it has them. - Push to the current branch's upstream. Never force-push, never
--no-verifyunless the repo's rules explicitly allow it. - Handoff, as a separate commit. Find/create the handoff file
(
CONTEXT.md→HANDOFF.md→TODO.md, in that order; createHANDOFF.mdif none exist). Update a## Next Sessionsection (what changed, what's next, blockers, suggested skills). Commit only that file with messagedocs: handoff notes for next session, then push immediately.
Keep going even if one repo fails — record the failure and move on.
4. Report back
One compact table: repo → what was committed → pushed? (remote/branch) → handoff pushed? Plus the set-aside repos from step 2 with the reason each needs manual attention. If nothing had outstanding work, say so plainly.
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.

