菜单
Re-vendor modules from upstream into cozy/vendor/ and prepare atomic commits grouped by repo. Use when the user says "vendor updated versions", "I vendored, commit", "nu toolkit/vendor.nu then commit", "refresh vendor", "bump vendored modules", or "vendor the latest, commit by groups".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | vendor-bump |
| description | Re-vendor modules from upstream into cozy/vendor/ and prepare atomic commits grouped by repo. Use when the user says "vendor updated versions", "I vendored, commit", "nu toolkit/vendor.nu then commit", "refresh vendor", "bump vendored modules", or "vendor the latest, commit by groups". |
Refresh the cozy vendor/ tree and produce one atomic commit per upstream repo
whose files changed. The user has repeatedly asked for this split-by-repo
grouping ("commit by groups"); never combine multiple repos into one commit.
cd to the cozy repo root (the dir with toolkit/vendor.nu and vendor/)git status is clean under vendor/. If there are pending vendor changes from
a previous run, stop and ask the user whether to commit, stash, or discard
them before re-vendoringnu toolkit/vendor.nu --no-commit # all repos, github tarballs (anonymous unless GH_TOKEN set)
nu toolkit/vendor.nu --local --no-commit # all repos, rsync from sibling ../<repo>/ dirs (dev workflow)
nu toolkit/vendor.nu <repo> --no-commit # just one repo from vendor.yml
Always pass --no-commit. vendor.nu auto-commits its result by default,
with a generic vendor: refresh all modules (no repo named) or
vendor: update <repo> subject — that has no body and
violates the Intent Preservation rule this skill exists to honor. --no-commit
leaves the changes unstaged so steps 2–4 below can compose richer per-repo
commits.
Default fetch is tarballs. Use --local only when the user has unpushed work
in sibling clones they want to vendor before pushing — confirm with them if
unclear. Without a <repo> arg, vendor.nu deletes and rewrites all of
vendor/ from scratch; with one, it wipes and rewrites only that repo's dir.
vendor/ is laid out as vendor/<repo>/<module>/... where <repo> and
<module> come from toolkit/vendor.yml (authoritative). Each top-level
vendor/<repo>/ dir with any change is one commit unit.
git status -s vendor/ | lines | each { split column ' ' status path }
| flatten | get path | split row '/' | get 0..1 | str join '/' | uniq
The dotfiles repo is an exception worth noting: it contains many per-app
modules (broot/, claude/, helix/, lazygit/, nushell/, zellij/,
wezterm/, ...). When changes span only one or two of those, prefer a tighter
subject like vendor: updated dotfiles/zellij and stage only that subdir. When
many apps changed at once, one vendor: updated dotfiles commit is fine.
Subject conventions (verified against git log --oneline -- vendor/):
vendor: updated <repo> (e.g. vendor: updated nu-goodies)vendor: updated <filename> (e.g. vendor: updated wezterm.lua)vendor: <repo> <short description>
(e.g. vendor: dotfiles XDG_CONFIG_HOME fallback in env.nu)Body MUST paraphrase what changed upstream. Get it by reading the sibling repo's git log between the previously-vendored revision and now:
git -C ../<repo> fetch
git -C ../<repo> log --oneline <last-vendored-sha>..HEAD
If the user knows the previously-vendored revision, ask. Otherwise diff the
just-rewritten vendor/<repo>/ against the index (git diff --staged vendor/<repo>/) and describe the substance — what behavior changed for the
user, not which lines moved.
If the upstream change is purely whitespace, formatting, or a re-run of topiary, say so plainly in the body. Don't pad with fake reasoning — the Intent Preservation rule means the body reflects the actual upstream intent, not a generic "refresh".
git add vendor/<repo>/
git commit -m "<subject>" -m "<body>"
Files removed upstream show as D in git status — include them in the same
per-repo commit, don't split. If an entire repo disappeared (dropped from
vendor.yml), the subject should say vendor: drop <repo> and the body
should reference the vendor.yml change.
After the vendor commits, check whether the bump invalidated any README claim.
README documents module command lists (claude-nu, nu-goodies, numd, dotnu) and
behavior of vendored dotfiles (keybindings, broot-paste, prompt). For each
change you just committed, ask: does README state something this change added,
removed, or altered? New exported commands and changed user-visible behavior
are the usual cases. If so, edit README.md and commit it separately as
docs(readme): <what was synced>, referencing the vendor commit hash(es) in
the body. Internal refactors need nothing.
List the commits created — one line each with subject. Note any repo where the body is sparse because upstream history was unavailable; flag it so the user can amend.
toolkit/vendor.yml is the source of truth for which repos and which
submodule subdirs are vendored. If vendor/ contains a repo not in
vendor.yml after the run, that's a bug in vendor.nu, not something to
commit around.nutest (vyadh/nutest) is third-party; its commit bodies should clearly
attribute upstream rather than imply local authorship.Verify a cozy build by running `cozy verify` against a target you name — a locally-built docker container (default), a running sbx sandbox, or a host checkout. The checks live in cozy-module/verify.nu. Use when you say "verify the build", "build-check", "smoke test the sandbox", "is everything wired up", "/verify-cozy docker", after building the image, or after creating a sandbox.
This skill should be used when working alongside a user in a shared Nushell terminal (e.g. the cozy sandbox) — coaching Nushell in everyday tasks and practicing literate programming with numd (executable markdown), dotnu (.nu scripts that embed their own output as `# =>` comments), REPL capture, and claude-nu session archiving. It governs interaction style: build a common space where the user runs Nushell themselves and grows fluency, instead of the agent executing everything for them. Relevant when the user says "numd," "dotnu," "teach me," "show me how," "let me run it," "literate programming," "run the code blocks in this markdown," "update the embeds," "capture this session," "keep this doc in sync," "export this claude session," "self-updating README," or asks how to document, share, practice, or verify Nushell work.
Turn the current chat into a gi canvas, or open an existing one. Use when the user says "gi canvas", "start a canvas", "переведи в канвас", "продолжим в канвасе", "open the canvas", or asks to move this conversation into a canvas document.
Reduce a canvas document to its current-state meaning, letting spent rejected paths and process scaffolding fall into git history (recoverable via `git log -p -- <doc>`). Use when the user says "distill", "git-intent-distill", or "reduce the canvas".
This skill should be used when inspecting, querying, or rewriting the user's Nushell command history. Relevant when the user asks "what did I run", "show my recent commands", "what was I trying", "find commands I ran in <dir>", "remove these history entries", "move/retag these history entries to <path>", "fix the cwd on these rows", or when you need to understand what the user has been doing in a directory by looking at their shell history.
Cut a new release for the cozy project: finalize CHANGELOG.md, create a git tag, and summarize what to do next. Use when the user says "make a release", "cut a release", "release", "bump version", "tag a release", or "prepare release".