agentleFS
dean815dean815/claude-project-optimizer/skills/archive/SKILL.md

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

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-hubSkill

    distill

    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

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 5 projects that use this

  • AnthropicSkill

    status

    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 AzureSkill

    test

    Also in 3 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 3 projects that use this

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
  1. Distinctive:

    A dry run is the default and is not optional: Every invocation inventories, plans, and presents — then asks.

    line 18
  2. Distinctive:

    Default the path to the current working directory, and resolve it to an absolute path — the registries are keyed by absolute path.

    line 24
  3. Very specific:

    If either emits an error key, stop and report it.

    line 49
  4. Very specific:

    Use AskUserQuestion with dispositions rather than a free-text yes/no — the choice is genuinely coarse, and naming the middle option makes …

    line 145
  5. Distinctive:

    Remove worktrees with git worktree remove, then git worktree prune

    line 172
  6. Distinctive:

    After moving, confirm the archive actually contains what it should:

    line 183
  7. Distinctive:

    Only then remove the originals.

    line 189
  8. Very specific:

    Remove the linear-sync entry only if the project is going away entirely.

    line 207
  9. Distinctive:

    Never git commit, git push, git stash drop, or discard changes without explicit per-item approval

    line 213
  10. Very specific:

    Never delete a GitHub repository.

    line 215
  11. Distinctive:

    Never delete a Linear project — set its state instead, preserving issue history

    line 217
  12. Very specific:

    Never rm -rf a worktree; it corrupts the parent repo's metadata

    line 218
  13. Distinctive:

    Never copy a credential file into a git repository

    line 219
  14. Distinctive:

    Never make a public repository private as part of archiving

    line 220
  15. Distinctive:

    Never remove conversation history before confirming the copy succeeded

    line 221
  16. Distinctive:

    When the user is unsure about any store, leave it and say so.

    line 222

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-github

If 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:

ArchetypeSuggested tier
emptydelete
context-workspacecold
library, published tool, public repo with stars or forksdormant
everything elsefull

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.

BlockerRemedy
Uncommitted changesCommit, stash, or discard — the user's call
Unpushed commitsgit push
No remote, commits exist only locallyCreate a remote and push, or accept the loss explicitly
StashesApply or drop; stashes are invisible after the directory moves
Branches not on the remotePush or confirm they are abandoned
Worktrees with unsaved workResolve in the worktree before removing it
Untracked credential filesDecide 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:

OptionMeaning
Apply the whole planEverything presented, in the order given
Local steps onlyCopy history, move the directory, deregister. Skips GitHub and Linear
Resolve blockers firstPush, commit, or preserve what is unsaved; re-run afterwards
Nothing for nowChange 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:

  1. Push everything approved for pushing — the irreversible boundary
  2. Copy history to the archive root (copy, not move)
  3. Remove worktrees with git worktree remove, then git worktree prune
  4. Move the working directory
  5. gh repo archive if in scope
  6. Update Linear
  7. 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 full and dormant: git log origin/main..main is 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>" declined

Register 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 archive is the only supported disposition; --delete-repo is permanent and breaks existing clones
  • Never delete a Linear project — set its state instead, preserving issue history
  • Never rm -rf a 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.