wrapup
Skill1 starsChanged 4 months agoMITView on GitHub
Finalize a chunk of work at the end of a session — build/lint/test green, version/changelog bump if the project uses one, docs updated, and a GATED commit — reported as a per-item checklist. Use when the user says "wrap up", "wrapup", "finalize this", "we're done here", or when a chunk of work has landed and needs to be made durable. NOT a context-saving doc — that's /handoff.
- Commits and pushes
25 other projects use a version of this.
Adopted by
Most recently taken up by
- ryanportfolio/HarnessFirmware.comtheir own version, first seen Nov 8, 2026
- ryanportfolio/winuse-mcptheir own version, first seen Nov 8, 2026
- ryanportfolio/Harness-Firmwaretheir own version, first seen Nov 7, 2026
- ryanportfolio/Corewise.Academytheir own version, first seen Nov 1, 2026
- zommuter/dotclaude-skillstheir own version, first seen Nov 1, 2026
- griffinhilly/claude-code-synthesistheir own version, first seen Nov 1, 2026
Used with
Projects with it also use addskill, apply-firmware and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ryanportfolioSkilladdskill
Create, import, update, or install repo or personal skills: runtime ownership, resources, discovery checks.
Also in 6 projects that use this
ryanportfolioSkillapply-firmware
Bring current folder (plain folder, existing repo, old or partial firmware copy) up to full Harness Firmware in place. Mirror external repo → adopt-repo.
Also in 6 projects that use this
- +10 more from ryanportfolio
Other versions25 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 25
- atelier-fashion/adlc-toolkit★ 173same name
- griffinhilly/claude-code-synthesis★ 67same name
- sunitghub/canon-skills★ 9same name
- ebaumel/claude-wrapup★ 4same name
- maxekman/skills★ 4same name
- zommuter/dotclaude-skills★ 4same name
- PatriotAgenticLLC/better_claude_skillz★ 3same name
- iXanadu/tiding★ 2same name
- olzn/skills★ 2same name
- ryanportfolio/winuse-mcp★ 2same name
15 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 repository9 other files it gives its agents.
- commitpushSkill
- discordembedSkill
- discordmsgSkill
- endSkill
- handoffSkill
- prettyhtmlSkill
- prettymsgSkill
- startSkill
- wtfSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 9 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 23 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 21
Never silently auto-do the gated item (commit).
- Very specific: line 26
Run the project's checks before declaring done — detect from the repo: npm test / pnpm test, cargo test, go test ./..., pytest, make, …
- Distinctive: line 29
If something fails, say so with the output — don't call it done.
- Very specific: line 32
If the repo versions releases (a version in package.json/Cargo.toml/pyproject.toml, a CHANGELOG.md, tags), bump/append per its convention.
- Distinctive: line 36
If behavior changed, update the affected README / docs — usage, flags, examples.
- Very specific: line 40
If the session produced a reusable gotcha or fix pattern and the repo has a NOTES.md / LESSONS.md / decision log, add a short entry with …
- Distinctive: line 46
When you do commit: stage only the relevant files/hunks — never sweep in unrelated dirty changes.
- Distinctive: line 50
If this topic had its own git worktree + branch and it's now fully merged, it's dead weight.
- Distinctive: line 51
Verify before pruning — never on a hunch:
- Distinctive: line 55
Only when empty, and only on the user's okay:
- Distinctive: line 60
Never remove a worktree with uncommitted changes (another chat may be mid-edit there).
- Very specific: line 64
If the session is heading toward a /clear, offer /handoff — don't write the handoff yourself.
- Distinctive: line 70
Don't claim "done & tested": when checks didn't run or didn't pass — say which it is.
“Common” is measured: kept by at least 6 in 10 of the 23 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
Wrap Up (finalize the work product)
This skill finalizes the deliverable at the end of a work session: makes the changes durable and shippable (build green, versions/changelog, docs, gated commit) and leaves things in a known-good state.
It is NOT /handoff. /handoff preserves the conversation (a throwaway doc so you can
/clear) and never changes code. /wrapup touches real shipped state. They compose: run /wrapup
first to finalize, then /handoff if you're about to /clear.
How to run it: a reporting checklist, not a blind auto-runner
Walk the steps in order. For each, report status — ✅ done / ⏭️ skipped (why) / ⚠️ needs the user. Never silently auto-do the gated item (commit). End with a one-screen summary table.
Steps
1. Build / lint / test green
- Run the project's checks before declaring done — detect from the repo:
npm test/pnpm test,cargo test,go test ./...,pytest,make,./gradlew build, etc. If you can't tell, ask which to run rather than skipping silently. - If something fails, say so with the output — don't call it done.
2. Version / changelog (only if the project uses one)
- If the repo versions releases (a
versioninpackage.json/Cargo.toml/pyproject.toml, aCHANGELOG.md, tags), bump/append per its convention. If it doesn't, ⏭️ skip and say so.
3. Docs
- If behavior changed, update the affected README / docs — usage, flags, examples. Keep it to what actually changed.
4. Notes / lessons (if the repo keeps them)
- If the session produced a reusable gotcha or fix pattern and the repo has a
NOTES.md/LESSONS.md/ decision log, add a short entry with the evidence that proved it. Otherwise skip.
5. Commit — GATED
- Do NOT
git commitorgit pushunless the user explicitly asks. If they didn't, report "uncommitted — say the word to commit" and stop here. (Use/commitpushwhen they do.) - When you do commit: stage only the relevant files/hunks — never sweep in unrelated dirty changes. Fold the docs/notes from steps 3–4 into the same commit.
6. Worktree cleanup (if you use worktrees) — GATED
- If this topic had its own
git worktree+ branch and it's now fully merged, it's dead weight. Verify before pruning — never on a hunch:
Only when empty, and only on the user's okay:git log --oneline <integration-branch>..<branch> # EMPTY = fully merged, nothing unshippedgit worktree remove <path> git branch -d <branch> # -d refuses if unmerged; never -D unless the user confirms - Never remove a worktree with uncommitted changes (another chat may be mid-edit there).
7. Close out
- Print the summary table (item → ✅/⏭️/⚠️ + one line).
- If the session is heading toward a
/clear, offer/handoff— don't write the handoff yourself.
Don'ts
- Don't write a handoff doc — that's
/handoff. This skill finalizes shipped state, not context. - Don't commit or push unless explicitly asked. Report the uncommitted state instead.
- Don't stage unrelated dirty files — focused commits only.
- Don't claim "done & tested" when checks didn't run or didn't pass — say which it is.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

