Update SenseNova Skills (the sn-* bundle) inside an OpenClaw or hermes-agent install. ALWAYS use this skill when the user says any of: "update SenseNova skills", "update SN skills", "更新 sensenova skills", "更新 sn skills", "刷新 sn-*", "升级 sn-* skills", or names a specific sn-* skill to update (e.g. "更新 sn-ppt-standard", "refresh sn-image-base"). Default scope is the whole sn-* bundle; if the user names specific skills, update ONLY those.
78
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Critical
Do not install without reviewing
Refresh installed sn-* skills from upstream
SenseNova-Skills.
sn-* skill upstream.Check which directories exist:
~/.openclaw/skills/ | ~/.hermes/skills/ | Target |
|---|---|---|
| exists | absent | openclaw |
| absent | exists | hermes |
| exists | exists | ask the user — never silently dual-write |
| absent | absent | no install found, stop |
Persistent cache at ~/.cache/sn-update/repo/. Default URL:
https://github.com/OpenSenseNova/SenseNova-Skills.git. User may override
with a fork URL.
--filter=blob:none --no-checkout, then sparse-checkout only
the selected skills/<name> paths before copying them. --filter=blob:none
alone does not keep the cache small if the full worktree is checked out;
that checkout will still download most or all needed blobs. It still
preserves history metadata for SHA queries.skills/<name> paths before
copying. If updating the whole sn-* bundle, expect most/all skill blobs to
be downloaded.origin differs from the requested URL,
delete and re-clone.For each skill, pick the highest-precedence signal present on both sides (installed + upstream); equal → skip, differ → install.
Upstream "version" is the per-subtree commit SHA — using repo HEAD would mark unrelated skills as stale every time:
git -C <cache> log -1 --format=%H -- skills/<skill-name>.sn-version marker: one-line file inside the installed skill
holding the SHA from its last install..sn-release marker (fallback): one-line file holding the
upstream tag name. Compare against git describe --tags --abbrev=0.version: field in SKILL.md frontmatter: parse from
YAML on both sides, but only for forks or skills that explicitly add this
field. If either side lacks it, C does not apply.Always write .sn-version on install so future runs can use A.
For each skill flagged "install":
<agent-skills>/<skill-name>/ into a
single timestamped backup bucket shared by all skills in this run:
~/.<agent>/skills_backup/<UTC-timestamp>/<skill-name>/
(e.g. 2026-04-30T15-29-07Z).<cache>/skills/<skill-name>/ → <agent-skills>/<skill-name>/.
Never symlink (ln -s) from the cache. The cache lives under
~/.cache/ with permissions the agent runtime may not be able to
traverse, and some runtimes refuse to load skills resolved through
symlinks. Always do a real recursive copy so the installed tree is
self-contained and owned by the agent skills dir..sn-version with the upstream subtree SHA inside the new copy.If the bucket ends up empty (all targets were fresh installs), remove it.
The backup tree is a sibling of skills/, never a .bak folder
inside it — most agent runtimes scan the whole skills/ directory and
would pick up stale duplicates.
After every run, prune the per-agent backup root to at most 3 buckets. Timestamps sort lexicographically; keep the newest 3, delete the rest. Run this even when the current run produced no backup of its own.
Group by status, keep it short:
Updated (3): sn-ppt-standard, sn-image-base, sn-deep-research
Already up-to-date (5): sn-ppt-creative, sn-ppt-doctor, ...
Backup: ~/.openclaw/skills_backup/2026-04-30T15-29-07Z/Backup: when nothing was backed up.abc1234 → def5678) only if the user asks for detail.~/.<agent>/skills_backup/ if they want to roll back.sn-update updating itself — fine; the new copy takes effect on
the next invocation.179fea1
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.