refresh-snapshots
Use to re-run the harness's snapshot/mirror flows so installed state matches version-controlled source — skill symlinks into ~/.claude, ~/.codex, ~/.gemini tool homes, git submodule pointers, and shell plugin checkouts. Use after restructuring skills, when links look stale or broken, or on a periodic freshness pass. Triggers: "refresh snapshots", "relink skills", "update submodules", "my installed skills are stale".
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- refresh-snapshots
- metadata
- { "owner": "tze", "status": "active", "authors": [ "tze", "Claude Fable 5" ], "last_reviewed": "2026-06-12" }
- description
- Use to re-run the harness's snapshot/mirror flows so installed state matches version-controlled source — skill symlinks into ~/.claude, ~/.codex, ~/.gemini tool homes, git submodule pointers, and shell plugin checkouts. Use after restructuring skills, when links look stale or broken, or on a periodic freshness pass. Triggers: "refresh snapshots", "relink skills", "update submodules", "my installed skills are stale".
- compatibility
- Assumes ~/.dotfiles with bootstrap.sh and the ai-bootstrap submodule; flows are idempotent and safe to re-run.
02 资源文件 2
- 参考文档references/snapshot-flows.md5.1 KB
- 脚本scripts/harness_doctor.sh2.0 KB
03 SKILL.md 正文
Refresh Snapshots
Several pieces of installed state are snapshots of version-controlled
source: symlink trees generated by bootstrap.sh, submodule checkouts
pinned to a recorded commit, plugin clones. They go stale silently when the
source moves. Every flow here is idempotent — re-running a fresh one is a
cheap no-op.
Health check without refreshing
To answer "is my harness healthy" without changing anything, run the doctor — it executes every flow's verify check (broken links, submodule drift, shell load, bd doctor, required binaries) as one pass/fail report:
bash <this-subskill>/scripts/harness_doctor.sh
Keep scripts/harness_doctor.sh in sync
when adding a flow to the catalog.
Workflow
- Read the flow catalog:
references/snapshot-flows.md— it lists each snapshot, its refresh command, and its verification check. - Run the refresh for the flows the task needs (or all of them on a periodic pass), then run each flow's verification and report refreshed/already-fresh/failed per flow.
- If a refresh changed git state (e.g. a submodule pointer moved), commit
it per the owning repo's conventions — pointer bumps in
~/.dotfilesuse the existingUpdate ai-bootstrap pointermessage style. - Write back (maintenance contract): if you discover a snapshot flow
not in the catalog — any script that copies or links version-controlled
content into a runtime location — append it to
references/snapshot-flows.mdin the same change.
Boundaries
- Refreshing a checkout to its recorded pointer (
git submodule update) is always safe; advancing a pointer (--remote) changes behavior — do it only when the task asks for updates, and report what moved. - If a verification fails after refresh (broken links remain, a skill vanished from a tool home), stop and diagnose before re-running — the flows are idempotent, so a second blind run cannot fix a real failure.
- Some machines symlink tool homes wholesale (
~/.claude→ai-bootstrap/.claude); others may copy. Confirm withls -ld ~/.claudebefore reasoning about which flow applies.
04 同仓库更多 Skills
user-run
Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable /home/orca/.tmp/<slug>/run.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: "I'll run it for you", "permission denied on docker.sock", "needs sudo", "sudo: a password is required", "run as tze", "/user-run".
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
dispatching-parallel-agents
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies