菜单
Check whether the scripts vendored under packages/mochi/src/vendor/ are on the latest upstream release, and update the ones that aren't. Use when the user asks to "check vendored versions", "update vendored scripts", "refresh vendored deps", or "/update-vendored".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use whenever the user asks to build, add, or modify anything in this Mochi app — pages, routes, islands, selective/lazy/server hydration, forms, JSON/WS/SSE endpoints, cookies, caching, or request context. Before writing any framework code, invoke the "mochi" skill to fetch the relevant Mochi docs and demos.
Add a new lifecycle event to Mochi's event bus (`packages/mochi/src/events.ts`). Use when the user asks to "add an event", "emit a new event", "create a new mochiEvents emission", or "/add-event <name>". Walks the payload type, the `MochiEventMap` registry, the emission site, public exports, optional logger wiring, tests, and docs.
Mutation-test unit tests to verify they catch real failures. For each test, temporarily breaks the source code it exercises, confirms the test fails, then reverts. Flags mock-only tests and suggests fixes. Use when the user says "validate tests", "test-validator", or wants to check test quality.
Take a 16:9 screenshot of a single component via the /shot/:name endpoint (`packages/site/src/shot/`). Use when the user asks to "screenshot a component", "take a component screenshot", "generate an image of <component>", "grab a shot of X for the docs", or "/component-screenshot <component>". Covers registering a new subject, sizing, and driving the browser.
Stage and commit the current working changes with a short release-please-style commit title. Does not push. Use when the user says "commit", "commit my changes", or "/commit". Optional args list paths to skip (e.g. "/commit ignore IMPROVEMENTS.md").
Add a new hook or filter to Mochi's extension API (`packages/mochi/src/extensions.ts`). Use when the user asks to "add a hook", "add a filter", "create an extension point", or "/add-extension <name>". Walks both halves of the type/runtime kind-map registry and the call-site wiring.
| name | update-vendored |
| description | Check whether the scripts vendored under packages/mochi/src/vendor/ are on the latest upstream release, and update the ones that aren't. Use when the user asks to "check vendored versions", "update vendored scripts", "refresh vendored deps", or "/update-vendored". |
| user-invocable | true |
Every folder under packages/mochi/src/vendor/ is a copy of a small upstream npm package (see Dependencies → Vendoring in /CLAUDE.md). This skill checks each one against its latest npm release and, for anything behind, replaces it wholesale with the new version's published source.
Files must be added AS IS from what npm published for that version. Do not diff the old and new upstream sources and hand-patch changes into the existing vendored file, and do not otherwise edit, refactor, or "fix" the vendored code yourself — that risks silently introducing behavior the upstream package never had. The only permitted mechanical step is re-applying the same file-format treatment already established for that vendor folder (e.g. the .ts extension, the ESM/CJS-build merge via the typeof process !== 'undefined' runtime switch) so it fits the existing build — never a judgment-based content edit.
bun run check-vendored-versions
This prints, per vendored script: the pinned version (parsed from the // Vendored from https://github.com/<owner>/<repo> <version> comment at the top of its index.ts) and the latest version on npm. If everything is current, report that and stop — do not proceed to Step 2.
For every script where pinned ≠ latest:
Note the npm package name (matches the vendor folder name so far in this repo) and the latest version.
Download only the latest tarball into the scratchpad dir and extract it:
cd <scratchpad>
npm pack <pkg>@<latest-version>
mkdir new && tar -xzf <pkg>-<latest-version>.tgz -C new --strip-components=1
Take the new version's source file(s) as published — unmodified — and use them to replace packages/mochi/src/vendor/<name>/index.ts wholesale, applying only the mechanical treatment described above (extension, ESM/CJS merge if the original vendoring did that). Do not carry forward or hand-merge anything from the old vendored file's content.
Bump the version in the // Vendored from ... comment to <latest-version>.
Compare the upstream LICENSE (old vs new, as published — not hand-edited) — if the copyright year or contributor list changed, replace packages/mochi/src/vendor/<name>/LICENSE with the new one as-is.
Remove the downloaded tarball and new/ extraction dir from the scratchpad.
If the new version doesn't fit the established mechanical treatment (new required peer deps, a different module system, split across more files than before), stop and report it to the user instead of guessing — re-vendoring from scratch is a judgment call for them, not something to push through silently.
Delegate bun run checks to a sub-agent per the repo convention (never run it directly from the main context — its output is too large). Report back only pass/fail and any failures.
Summarize what changed, e.g. slugify: 1.6.9 → 1.7.0, list the files touched (index.ts, LICENSE if applicable), and stop. Per repo convention, never git commit on your own — wait for the user to say so.