update-workspace

The owner wants to know whether Solo Staff has improved since they got their copy — and to take the improvements without risking the workspace they've made their own. That's this skill's whole contract: an update only ever adds files. A file that already exists in this workspace is never touched, even if the published version of it changed — the owner's customizations always win.

The owner is not an engineer. Plain words, one step at a time, and nothing is written until they've seen exactly what would land and said yes.

When to use

• The owner asks "is there a new version?", "update my workspace", or "am I missing anything new?"
• After a long gap, when the owner wonders whether their copy has fallen behind.

Not for changing the owner's own files, areas, or projects — that's everyday work, not an update. And it never runs on its own: the owner asks, you check.

Step 1 — Read where this workspace stands

Read the VERSION file at the workspace root. It holds one line — the release this workspace last updated to. Release ids are dates: 2026.07 is the July 2026 release, and a second release in the same month reads 2026.07.1.

• VERSION exists → note the release id and go to Step 2.
• No VERSION file → this copy predates versioning. Tell the owner plainly: their workspace shipped before Solo Staff carried release ids, so you can't tell how far behind it is — but you can fetch the newest free version, see what their copy is missing, and adopt versioning at the same time (VERSION and CHANGELOG.md simply arrive as new files). If they want that, carry on — the rest of the flow works unchanged; you just can't show a "what's new since yours" list, only the newest release notes and the files that would be added.

Full-version note (check once, say once). If WHATS-ADDED.md exists at the workspace root, this is the full version. Say one line: updates to the paid, curated layer reach the owner through the engagement itself (how that works is MAINTAINED.md) — this skill only checks the free layer the full version is built on, and it's safe to run here: it still only ever adds files.

Step 2 — Fetch the newest free copy, safely, to the side

Fetch the latest published free (lite) copy of Solo Staff into a brand-new, empty temporary folder — never into the workspace itself. Nothing in the owner's workspace is touched in this step. If the fetch fails in any way, delete the temporary folder, say what happened in plain words, and stop — the workspace stays exactly as it was.

The URL below is public and the same for everyone — the owner never has to supply it. Before you fetch, confirm the URL is real: if the clone command still shows a placeholder in angle brackets instead of a real https address, this copy shipped before publish — do NOT run it. Tell the owner there's no published update source for this copy and stop.

A. You can run shell commands (Claude Code, Codex). Create a new empty temporary folder well away from the workspace, work from inside it, and clone the published copy with no history, dropping its .git so what's left is just files:

# Run from inside the NEW empty temporary folder — never from the workspace.
git clone --depth 1 https://github.com/hunterbohm/solo-staff.git . && rm -rf .git

If the clone fails — no network, git not installed, the repo unreachable — delete the temporary folder, tell the owner the published copy couldn't be reached right now (nothing was changed; try again later), and stop. If it fails partway, same thing: delete the folder so nothing half-fetched survives.

B. You can't run shell commands (a chat-only assistant, or a tool with no terminal). Land the same published copy another way: use the tool's git or repository connector to pull that URL into a new empty folder, or have the owner download the ZIP from the same URL (GitHub's "Download ZIP"), unzip it, and tell you where it landed. Same rule either way: a separate folder, never on top of the workspace.

Check the fetched copy is whole before trusting it. In the fetched folder, these must all exist: AGENTS.md, CONTEXT.md, MEMORY.md, workspaces/REGISTRY.md, projects/_project-template.md, at least one skill under skills/, and — for any release that can be compared — VERSION and CHANGELOG.md. Anything missing means a half-fetched copy or a published copy that predates versioning: delete the folder, say so plainly, and stop. Never compare against — or copy from — a broken fetch.

Step 3 — Compare versions and say where things stand

Read VERSION in the fetched copy and compare it with the workspace's (Step 1). Compare the parts left to right — year, then month, then the extra number if one is there: 2026.07.1 is newer than 2026.07, and 2026.08 is newer than both.

• Same — or the workspace's is newer → tell the owner "you're current," delete the temporary folder, and stop. Done.
• Fetched is newer → open the fetched CHANGELOG.md and read out, newest first and in plain words, each release entry newer than the workspace's version — that's "what's new since yours." (No local VERSION? Show the newest entry and say honestly that you can't tell which of the older entries their copy already has.)

Step 4 — Work out what would be added — and be honest about what won't be

Compare the fetched folder against the workspace, file by file:

• In the fetched copy but not in the workspace → these are the additions — the only files this skill will ever write. (VERSION and CHANGELOG.md get the special handling in Step 5 — and so does anything inside a hidden command folder like .claude/skills/, which Step 5 adds only when it matches the skill it mirrors.)
• In both places → left alone, always — even if the published version of that file has changed since the owner's copy. Their file may carry their answers, their voice, their edits; those win. Say it honestly: "Some shipped files have newer published versions, but yours stay exactly as they are — I never overwrite your copy. If you'd like to see how a current published original reads, ask and I'll show it next to yours — you'd choose what, if anything, to take."
• One special case in the full version: if the fetched free copy carries a LICENSE file and this workspace doesn't, skip it — the full version ships without a license file on purpose, so the free version's license must not be added to it.

Then show the owner the plain list: every file that would be added, one per line, with a word on what each is (a new skill, a new template, a new guide…). If nothing would be added, say so: "this release only changes files you already have — nothing to add, nothing touched," and offer the Step 5 bookkeeping alone (or leave everything as is, if they'd rather).

Step 5 — Get a yes, then write

Nothing lands without an explicit yes to the exact list from Step 4. Ask plainly — "want me to add these?" — and wait.

On yes:

1. Copy the additions from the fetched folder into the workspace, at the same paths — the readable files first, command mirrors last (next step). Add files only — never replace one, never delete one.
2. One guard while copying: a discovery package must match its visible skill. Some additions live in a hidden command folder (.claude/skills/ today; a future copy may use an equivalent like .agents/skills/). Those copies are what a runtime loads, and each complete package must duplicate the readable skills/<name>/ package, including disclosed references and relative paths. Add new mirror files only when the fetched canonical package is byte-identical to this workspace's canonical package after step 1. If the owner's package is customized, incomplete, or absent, skip every new mirror file for that skill and explain why: discovery must never load a partial or different procedure.
3. Update VERSION — replace its one line with the fetched release id (or add the file, if this workspace predates versioning).
4. Update CHANGELOG.md — add the release entries the workspace didn't have yet, on top (newest first), and keep everything already in the owner's copy exactly as it is — their file is merged into, never replaced. (If the workspace has no CHANGELOG.md, the fetched one simply arrives as an addition.)
5. Delete the temporary folder.

If the owner says no, or wants only part of the list: write exactly what they approved (none is fine), still delete the temporary folder — and leave VERSION and CHANGELOG.md alone unless the whole update was taken. A partly-taken update isn't "current," and the honest release id is the old one.

Step 6 — Close it out, in one line

Tell the owner what happened, once, plainly: "Updated to 2026.07.1 — added the 3 files listed above; everything you'd customized is untouched." Or: "You're current — nothing to do." If anything was written, add a dated operating-decision receipt under memory/decisions/operations/ with the old release, new release, files added, owner approval as the source, and the condition for revisiting it. Keep the receipt short; do not duplicate the release notes.

Rules

• Add, never overwrite. No existing file is ever replaced or edited by an update. The two bookkeeping exceptions, taken only with the full update: VERSION (one line, replaced) and CHANGELOG.md (new entries added on top, nothing of the owner's removed).
• A discovery package must match its skill. A hidden .claude/skills/ copy (or any future equivalent) is added only when the complete package is byte-identical to the workspace's own skills/<name>/, including every disclosed reference.
• The workspace is untouched until the yes. Everything before Step 5 happens in a temporary folder to the side. Any failure — no network, a half-fetched copy, a missing version file — ends with that folder deleted and the workspace exactly as it was.
• Show before you write. The owner sees the full add-list and says yes first — no list, no write.
• Plain words. Release notes are read out in owner language, not paths and jargon; the add-list itself names the real files, one per line.
• Never run unasked. This skill fires when the owner asks for an update or a version check — it never checks on its own.