菜单
Sync the Viv install. Default flow: check for newer published versions of the compiler, runtime, monorepo, and editor plugins; review CHANGELOGs for breaking changes; and upgrade what's behind with user approval. Also handles downgrades, alignment, and reinstalls when the context calls for it.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Answer questions about Viv, an engine for emergent narrative. Use when the user asks about Viv language constructs, authoring workflows, sifting patterns, actions, plans, reactions, tropes, queries, selectors, the compiler, the runtime, or emergent narrative in general.
Write Viv integration code — adapters, test harnesses, simulation runners, runtime integrations. Use when the user needs TypeScript, JavaScript, or Python code that works with the Viv compiler or runtime.
Diagnose and fix Viv errors. Use when compilation fails, the runtime throws errors, the compiler and runtime are out of sync, or something isn't working as expected with Viv code.
Set up Viv in the current project. Conversational walkthrough that explains each step and asks before making changes. Run this first in any new Viv project.
Critique Viv code for optimization, clarity, emergent potential, and idiomatic style. Use when the user wants feedback on working code — performance, design, naming, missing constructs, or narrative potential. Does not make changes; produces a report.
Design Viv systems from a premise. Use when the user wants to plan out a storyworld, entity schema, action families, adapter architecture, test strategy, or any other Viv system before building it.
| name | sync |
| description | Sync the Viv install. Default flow: check for newer published versions of the compiler, runtime, monorepo, and editor plugins; review CHANGELOGs for breaking changes; and upgrade what's behind with user approval. Also handles downgrades, alignment, and reinstalls when the context calls for it. |
| argument-hint | [optional direction — e.g., 'downgrade the compiler', 'align to compiler v0.11.3', 'reinstall everything'] |
| user-invocable | true |
You are managing the user's Viv install. Read the conversation to determine the goal before acting:
Run viv-plugin-check-latest. It reports the latest versions for:
viv-compiler)@siftystudio/viv-runtime)siftystudio.viv)sublime-v* tagclaude-v* tagUse your judgment. The right command depends on the component:
vivc --version, or read compiler_path from viv-plugin-read-state if vivc isn't on PATH.npm list @siftystudio/viv-runtime in the project directory.monorepo_tag from viv-plugin-read-state.viv-plugin-install-*-{extension,plugin,package} --check.viv-plugin-version for the version that's actually running in this session, then list ~/.claude/plugins/cache/siftystudio/viv/ for the version that's been cached (highest semver subdirectory). If the running version is older than the cached version, that's the well-known Claude Code cache-staleness bug — surface it to the user explicitly and recommend a manual cache clear + reinstall (handled by the upgrade flow in step 5). Do not rely solely on the cache directory listing — it tells you the latest available on disk, not what's actually executing.For every component that's behind, read the component's CHANGELOG in the monorepo to understand what changed. Each package has its own:
compiler/CHANGELOG.mdruntimes/js/CHANGELOG.mdplugins/vscode/CHANGELOG.mdplugins/jetbrains/CHANGELOG.mdplugins/sublime/CHANGELOG.mdplugins/claude/CHANGELOG.mdLook especially hard at minor-version bumps — pre-1.0, 0.10.x → 0.11.0 may include breaking changes per semver convention. Patch bumps (0.10.1 → 0.10.2) are typically safe but still worth a glance. Fall back to git log in the monorepo if the CHANGELOG is thin or missing the relevant entries.
Summarize anything user-facing, especially breaking changes, so you can present them to the user in step 4.
Show the user what's current, what's behind, and what each upgrade would bring — including any breaking changes you found in the CHANGELOGs. Then ask whether to upgrade.
Always check in before upgrading. Sync is a rarely used skill; the cost of asking is small compared to the cost of surprise changes. Even for patch bumps, confirm with the user.
Use AskUserQuestion for structured decisions. The /viv:setup skill leans heavily on this pattern for procedural interactions and it's a natural fit for sync too. Concretely: for each component that's behind, consider an AskUserQuestion with labeled options like "Upgrade" / "Skip" / "Show me the CHANGELOG first" (and for minor-version bumps, include a "Show the breaking-change summary" option). Don't assume the user wants to upgrade everything at once — let them pick and choose.
For each component the user approved:
/viv:setup step 5 (pipx / pip3 / venv). Use compiler_path from state as a hint about how it was originally installed.viv-plugin-install-runtime — re-runs the install, which pulls latest from npm.viv-plugin-fetch-monorepo <tag> where <tag> is the most recent release tag of any flavor (what viv-plugin-check-latest reports for monorepo). This grabs the freshest snapshot, which by the project invariant contains the latest of every component.viv-plugin-fetch-monorepo compiler-v<installed_version> so the monorepo's language reference and grammar match the compiler the user is running. This is the only time compiler-v primacy applies.viv-plugin-install-vscode-extension.viv-plugin-install-webstorm-plugin.viv-plugin-install-sublime-package copies from plugins/sublime/ in the currently-fetched monorepo — it does not reach out to any package registry. Order matters: fetch the monorepo first (see above) so that the sublime directory reflects the correct version, then run the install. Under the default upgrade flow, the monorepo refresh fetches the freshest release of any flavor, guaranteeing the latest sublime is present.rm -rf ~/.claude/plugins/cache/siftystudio/viv — clear the cache so the bug can't bite.claude plugin install viv@siftystudio — triggers a fresh install from the marketplace.When an install or upgrade command fails — e.g., the WebStorm CLI launcher isn't on PATH, VS Code's code command isn't installed, Sublime Text isn't detected, or some other environmental prerequisite is missing — surface the failure to the user and offer to help. You (Claude) know how to install these tools and how to enable auto-updates inside each editor, so use AskUserQuestion to present structured recovery options, e.g.:
One blocked component should not block the rest of the sync. Continue with the other upgrades and report the skip at the end.
After any changes, run vivc --version and confirm the expected version. If you touched the compiler, also run vivc --test. If verification fails, report back to the user — do not update state as if the sync succeeded.
Use viv-plugin-write-state to persist the new versions:
viv-plugin-write-state --set compiler_version <version>
viv-plugin-write-state --set monorepo_tag <tag>
viv-plugin-write-state --set monorepo_cloned_at <date>
viv-plugin-write-state --project <path> runtime_version <version>
viv-plugin-write-state --project <path> last_checked <date>
Report what was done.
vivc --version fails entirely, npm complains about a corrupted package), this is a repair situation, not an upgrade. Diagnose the underlying issue and remediate before trying to move forward.