agentleFS
aaroncohnaaroncohn/openspec-conductor-powerups/skills/safe-to-archive/SKILL.md

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

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

    Read-only: Run the checks, report, then offer fixes.

    line 12
  2. Distinctive:

    Run these from the workspace root (prefer one or two batched Bash calls):

    line 16
  3. Very specific:

    If there is no PR, also check whether the branch's content already landed (e.g.

    line 36
  4. Very specific:

    If the repo has an openspec/ directory, also run openspec list (or ls openspec/changes, excluding archive/) and git diff --name-only $(git …

    line 42

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

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

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 grep

Target 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 target

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

CheckBlocker when
Working treegit status --porcelain shows anything outside gitignored paths
UnpushedCommits 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
PRPR is OPEN, or there's no PR and the branch has commits whose content isn't in the target
After-merge commitsPR is MERGED but HEAD ≠ headRefOid and the extra commits' content isn't in the target
StashA stash entry was made on this branch
OpenSpecA 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, .env values 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 CLOSED without 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 → main flow: if the merged work isn't in origin/main yet, 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 on feature-x → push and open a PR into dev").

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?").

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.