safe-to-archive
Skill1 starsChanged 12 days agoMITView on GitHub
Check whether the current Conductor workspace can be archived without losing work — uncommitted or unpushed changes, open or missing PRs, commits added after the merge, stashes, .context and other ignored files that exist only here, running processes, and (in OpenSpec repos) unarchived changes. Read-only; gives a yes/no verdict with the fix for each blocker. Use when the user runs `/babysitter:safe-to-archive` or asks "can I archive this workspace/session?", "is this workspace done?", or "safe to archive?".
- Reads credentials
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- better-decisionSkill
- browser-handoffSkill
- doctorSkill
- hqSkill
- keep-goingSkill
- new-batch-exploreSkill
- pauseSkill
- status-checkSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
2
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 12
Read-only: Run the checks, report, then offer fixes.
- Distinctive: line 16
Run these from the workspace root (prefer one or two batched Bash calls):
- Very specific: line 36
If there is no PR, also check whether the branch's content already landed (e.g.
- Very specific: line 42
If the repo has an openspec/ directory, also run openspec list (or ls openspec/changes, excluding archive/) and git diff --name-only $(git …
≈ “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
safe-to-archive
Archiving a Conductor workspace deletes its worktree directory, including untracked and ignored files such as .context/. Pushed branches and PRs on GitHub survive. Decide whether anything would be lost or forgotten.
Local or cloud. Locally (CONDUCTOR_IS_LOCAL=1), the workspace is a git worktree: local branches live in the shared repository and survive archiving, so only this workspace's branch matters. In a cloud workspace (CONDUCTOR_IS_LOCAL=0), the sandbox is the only checkout and archiving deletes all of it, so every local branch matters (see step 1).
Read-only. Run the checks, report, then offer fixes. Do not commit, push, merge, or delete anything unless the user says so.
1. Gather facts
Run these from the workspace root (prefer one or two batched Bash calls):
git fetch origin -q
git branch --show-current
git status --porcelain # uncommitted + untracked
git rev-parse --abbrev-ref @{u} 2>/dev/null # upstream, if any
git log --oneline @{u}..HEAD 2>/dev/null # unpushed commits
gh pr view --json number,url,state,baseRefName,headRefOid,mergedAt 2>/dev/null
git stash list --format='%gd %gs' | grep -F "$(git branch --show-current)"
git status --ignored --porcelain | grep '^!!' # ignored files, incl. .context/
ps -Ao pid,command | grep -F "$PWD" | grep -v grepTarget branch: the PR's baseRefName if there is a PR; otherwise the Conductor target from the system prompt; otherwise origin/HEAD. Then:
git log --oneline origin/<target>..HEAD # commits on this branch not in targetIf there is no PR, also check whether the branch's content already landed (e.g. merged by another route): git diff --stat origin/<target> HEAD -- $(git diff --name-only $(git merge-base origin/<target> HEAD) HEAD). Empty means the content is already in the target.
Cloud only: check every local branch, not just this one: git for-each-ref refs/heads --format='%(refname:short) %(upstream:short)'. For each, look for unpushed commits (git rev-list --count <upstream>..<branch>, or no upstream at all) and whether its work landed in the target (gh pr list --head <branch> --state all, or an empty git diff origin/<target> <branch>). Also look for any cloud browser session still running for this workspace (for example, with Browserbase and BROWSERBASE_API_KEY set: GET https://api.browserbase.com/v1/sessions?status=RUNNING with header X-BB-API-Key). End it first so its saved logins are written back.
From the ignored files, skip regenerable ones (node_modules, build output, caches, .playwright-mcp/) and pick out anything that looks worth keeping: notes, scripts, plans, .env files with values that live nowhere else.
If the repo has an openspec/ directory, also run openspec list (or ls openspec/changes, excluding archive/) and git diff --name-only $(git merge-base origin/<target> HEAD) HEAD -- openspec/changes.
2. Classify
Blockers (not safe — work would be lost or stranded):
| Check | Blocker when |
| Working tree | git status --porcelain shows anything outside gitignored paths |
| Unpushed | Commits exist that aren't on the remote branch |
| Other branches (cloud only) | Another local branch has unpushed commits, or no upstream and content that isn't in the target |
| PR | PR is OPEN, or there's no PR and the branch has commits whose content isn't in the target |
| After-merge commits | PR is MERGED but HEAD ≠ headRefOid and the extra commits' content isn't in the target |
| Stash | A stash entry was made on this branch |
| OpenSpec | A change in openspec/changes/ (not archive/) was created or edited on this branch and not archived |
Heads-ups (safe, but say so):
.context/or other ignored files that exist only here: list them; they'll be deleted. Call out any that look worth keeping (notes, plans,.envvalues that live nowhere else) and offer to copy them.- Processes running from this directory (dev servers, watchers): they'll lose their directory. Give the PIDs. In the cloud, also any running cloud browser session (end it first so its logins are saved).
- PR is
CLOSEDwithout merging: the work was abandoned on purpose? Ask. - Squash-merge leftovers: Conductor may still show a diff after a squash merge. That's fine if the content is in the target.
- Repo with a
dev→mainflow: if the merged work isn't inorigin/mainyet, note it isn't in production. Not a blocker — promotion can be done from any workspace. If the branch added database migrations, remind the user to apply them to production before promoting.
3. Report
Lead with the verdict on one line:
✅ Safe to archive.followed by any heads-ups (max 5 bullets).⛔ Not safe to archive yet.followed by one numbered line per blocker: what, where, and the fix (e.g. "2 unpushed commits onfeature-x→ push and open a PR intodev").
End with one next step: either "Archive it in Conductor" or an offer to fix the first blocker ("Want me to commit and push these 3 files?").
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.

