archive
Skill0 starsChanged 4 months agoMITView on GitHub
This skill should be used when the user asks to "archive this project", "retire this project", "I'm done with this project", "clean up this directory", "shut down this repo", "wind down this project", or asks how to safely stop working on a project. Inventories every store holding state for it — working directory, conversation history, worktrees, GitHub, Linear, and the optimizer registry — reports what would be lost, and archives it in a safe order. Always produces a plan first and asks before changing anything. The counterpart to the onboard skill.
- Deletes or force-pushes
- Commits and pushes
22 other projects use a version of this.
Adopted by
Most recently taken up by
- phuthuycoding/kanban-flowtheir own version, first seen Nov 8, 2026
- egregore-labs/egregoretheir own version, first seen Nov 6, 2026
- myowinthein/claude-helmtheir own version, first seen Nov 1, 2026
- serbanghita/plan-critique-skillstheir own version, first seen Nov 1, 2026
- kirkchen/beattheir own version, first seen Nov 1, 2026
- matthewdigiuseppe/MStacktheir own version, first seen Nov 1, 2026
Used with
Projects with it also use distill, plan and 3 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.
HK-hubSkilldistill
Strip designs to their essence by removing unnecessary complexity. Great design is simple, powerful, and clean. Use when the user asks to simplify, declutter, reduce noise, remove elements, or make a UI cleaner and more focused.
Also in 3 projects that use this
BlockSkillplan
Draft a TDD, PRD, or lightweight plan in the conversation without committing it.
Also in 5 projects that use this
AnthropicSkillstatus
Case status summary by audience — client-facing (plain language), internal (for the professor), or court-ready (formal caption format per local rules). Same facts, different framing and depth. Use when a student needs to update the client, brief the professor, or prepare a court status report.
Also in 3 projects that use this
Microsoft AzureSkilltest
Also in 3 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 3 projects that use this
Other versions22 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 22
- ReScienceLab/opc-skills★ 1.9ksame name
- egregore-labs/egregore★ 293same name
- matthewdigiuseppe/MStack★ 17same name
- bks-lab/open-bridge★ 13same name
- serbanghita/plan-critique-skills★ 13same name
- kirkchen/beat★ 9same name
- philippe-desplats/second-brain★ 6same name
- codebycorey/delta-spec★ 4same name
- grasscaograss/AwesomeWeldoneSkills★ 2same name
- jcordon5/archive-skill★ 2same name
12 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.
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 11 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 18 edited versions we read keep these.
11
Distinctive
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
- could be automatic: a setting could enforce it
- Distinctive: line 18
A dry run is the default and is not optional: Every invocation inventories, plans, and presents — then asks.
- Distinctive: line 24
Default the path to the current working directory, and resolve it to an absolute path — the registries are keyed by absolute path.
- Very specific: line 49
If either emits an error key, stop and report it.
- Very specific: line 145
Use AskUserQuestion with dispositions rather than a free-text yes/no — the choice is genuinely coarse, and naming the middle option makes …
- Distinctive: line 172
Remove worktrees with git worktree remove, then git worktree prune
- Distinctive: line 183
After moving, confirm the archive actually contains what it should:
- Distinctive: line 189
Only then remove the originals.
- Very specific: line 207
Remove the linear-sync entry only if the project is going away entirely.
- Distinctive: line 213
Never git commit, git push, git stash drop, or discard changes without explicit per-item approval
- Very specific: line 215
Never delete a GitHub repository.
- Distinctive: line 217
Never delete a Linear project — set its state instead, preserving issue history
- Very specific: line 218
Never rm -rf a worktree; it corrupts the parent repo's metadata
- Distinctive: line 219
Never copy a credential file into a git repository
- Distinctive: line 220
Never make a public repository private as part of archiving
- Distinctive: line 221
Never remove conversation history before confirming the copy succeeded
- Distinctive: line 222
When the user is unsure about any store, leave it and say so.
“Common” is measured: kept by at least 6 in 10 of the 18 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
Archive a Project
Retire a project without orphaning the state that lives outside its directory.
The governing rule: nothing is removed until its content is confirmed safe somewhere else. Verification comes before deletion, always, and deletion of the originals comes last.
Invocation
A dry run is the default and is not optional. Every invocation inventories, plans, and presents — then asks. There is no flag that skips straight to acting, because the plan is where the mistakes get caught: dry-running this skill against real projects surfaced four cases where a project was about to be reported safe on evidence that did not support it.
Default the path to the current working directory, and resolve it to an absolute path — the registries are keyed by absolute path.
--plan-only— present the plan and stop without prompting. For batch review, or when the user is comparing several projects before deciding--tier <name>— skip the tier question, still plan and prompt
Workflow
1. Preflight
bash "${CLAUDE_PLUGIN_ROOT}/scripts/archive-preflight.sh" "<absolute-path>"This inventories all six stores and returns a blockers array — everything that
archiving would destroy. Read the whole object; the blockers list is a summary,
not the full picture.
Also run the ordinary scan, which supplies the archetype used to suggest a tier:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/scan-project.sh" "<absolute-path>" --no-githubIf either emits an error key, stop and report it.
2. Propose a tier
Consult ${CLAUDE_PLUGIN_ROOT}/references/archive-tiers.md. Map from the scan's
archetype, then confirm:
| Archetype | Suggested tier |
empty | delete |
context-workspace | cold |
library, published tool, public repo with stars or forks | dormant |
| everything else | full |
State the suggestion and what it implies, then let the user correct it. The tier determines how much of the rest of this workflow runs, so it is worth one question rather than an assumption.
3. Report blockers before proposing anything
Blockers are work that exists in exactly one place. Present them plainly, with the remedy for each, before the archive plan — the user may decide not to archive at all once they see what is unsaved.
| Blocker | Remedy |
| Uncommitted changes | Commit, stash, or discard — the user's call |
| Unpushed commits | git push |
| No remote, commits exist only locally | Create a remote and push, or accept the loss explicitly |
| Stashes | Apply or drop; stashes are invisible after the directory moves |
| Branches not on the remote | Push or confirm they are abandoned |
| Worktrees with unsaved work | Resolve in the worktree before removing it |
| Untracked credential files | Decide per file — never copy one into a git repo |
Do not resolve blockers automatically. Committing or pushing on the user's behalf makes decisions that are theirs. Present them, get direction, then act.
headOnRemote: false outranks everything else in this list. It means the
local commits are not on origin right now, whatever unpushed says —
unpushed compares against a cached tracking ref that another clone may have
force-pushed past. Do not remove anything until a copy is confirmed.
Before concluding a history is unique
headOnRemote only ever checks origin. A second copy commonly lives in a
repository that is not configured as a remote — a -dev, -private, or backup
repo pushed to once and forgotten. A private repo does not appear in public
listings, so gh api users/<owner>/repos will miss it entirely:
gh repo list <owner> --limit 200 --json name,visibility,pushedAt # includes private
git ls-remote git@github.com:<owner>/<candidate>.git | grep <head-sha>Prove a candidate actually holds the history by SHA, not by name or timestamp. Then state the finding precisely: "not on origin; a complete copy is at X" is a different situation from "this history exists nowhere else," and the two lead to opposite decisions. Never assert the second without having searched for the first.
Before proposing gh repo archive
Confirm no other local directory shares the remote. Two checkouts of one repo is common — a squashed publishing copy alongside a full-history working copy — and archiving the repo from one silently affects the other:
git -C "<path>" remote get-url origin
for d in "$(dirname "<path>")"/*/; do
printf '%s %s\n' "$d" "$(git -C "$d" remote get-url origin 2>/dev/null)"
done | grep -i "<repo-name>"Normalize before comparing — the same repo appears as both
git@github.com:owner/repo.git and https://github.com/owner/repo.git. When
another directory shares it, drop the GitHub step from the plan and say why.
For delete and cold tiers most blockers do not apply; skip the ones that are
vacuous rather than listing them as satisfied.
4. Present the plan
Group by store, marked with what each action costs:
- Move — reversible
- Remote — affects GitHub or Linear
- Remove — irreversible; state exactly what is being removed and what holds the surviving copy
Include the conversation history size. Users routinely do not know it exists, and it is often the largest single artifact — state the figure rather than a vague reference to transcripts.
5. Prompt
Having presented the plan in full, ask what to do with it. Stop here when invoked
with --plan-only.
Use AskUserQuestion with dispositions rather than a free-text yes/no — the
choice is genuinely coarse, and naming the middle option makes the safe path easy
to take:
| Option | Meaning |
| Apply the whole plan | Everything presented, in the order given |
| Local steps only | Copy history, move the directory, deregister. Skips GitHub and Linear |
| Resolve blockers first | Push, commit, or preserve what is unsaved; re-run afterwards |
| Nothing for now | Change nothing. The plan stands as a record |
Offer "Local steps only" whenever the plan contains any Remote item, since
GitHub and Linear changes are the ones visible to other people and the ones
worth deferring. Offer "Resolve blockers first" whenever blockers is non-empty,
and make it the recommended option in that case.
Accept a free-text answer selecting individual items — apply exactly what was named and say plainly what was skipped. When the answer is ambiguous, ask once more rather than guessing; an ambiguous archive instruction is not one to interpret generously.
6. Apply in order
Ordering is a safety property, not a preference. See the reference for why:
- Push everything approved for pushing — the irreversible boundary
- Copy history to the archive root (copy, not move)
- Remove worktrees with
git worktree remove, thengit worktree prune - Move the working directory
gh repo archiveif in scope- Update Linear
- Deregister
Report each step as it completes. On failure, stop that store and continue with the others, then say clearly what did not happen.
7. Verify before removing originals
After moving, confirm the archive actually contains what it should:
- The archived working directory exists and is non-empty
- The history directories are present, with file counts matching preflight
- For
fullanddormant:git log origin/main..mainis empty
Only then remove the originals. When any check fails, leave everything in place and report — a duplicated project is a minor annoyance, a lost one is not.
8. Deregister
bash "${CLAUDE_PLUGIN_ROOT}/scripts/registry.sh" set "<original-path>" declined
bash "${CLAUDE_PLUGIN_ROOT}/scripts/registry.sh" set "<archived-path>" declined
bash "${CLAUDE_PLUGIN_ROOT}/scripts/registry.sh" set "<archive-root>" declinedRegister all three. The original stops the hook if the directory is ever
recreated. The archived path matters because moving a project outside ~/claude
does not stop the hook — it fires in any directory not in its noise list, so
the move re-arms the offer at the new location. The root covers cd-ing there
directly; it does not cover the projects beneath it, since the hook matches
exact paths rather than prefixes.
Remove the linear-sync entry only if the project is going away entirely.
Close with what moved where, what was removed, and anything left undone.
Safety constraints
- Never
git commit,git push,git stash drop, or discard changes without explicit per-item approval - Never delete a GitHub repository.
gh repo archiveis the only supported disposition;--delete-repois permanent and breaks existing clones - Never delete a Linear project — set its state instead, preserving issue history
- Never
rm -rfa worktree; it corrupts the parent repo's metadata - Never copy a credential file into a git repository
- Never make a public repository private as part of archiving
- Never remove conversation history before confirming the copy succeeded
- When the user is unsure about any store, leave it and say so. An incompletely archived project is recoverable; a deleted one is not
Additional Resources
${CLAUDE_PLUGIN_ROOT}/references/archive-tiers.md— The four tiers, the disposition of each store, and store-specific procedure${CLAUDE_PLUGIN_ROOT}/references/archetypes.md— Classification, which supplies the suggested tier${CLAUDE_PLUGIN_ROOT}/scripts/archive-preflight.sh— Inventory and blockers${CLAUDE_PLUGIN_ROOT}/scripts/scan-project.sh— Archetype classification${CLAUDE_PLUGIN_ROOT}/scripts/registry.sh— Deregistration
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.

