菜单
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".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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".
| name | make-a-release |
| description | 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". |
Full release procedure for the cozy project.
git status shows no uncommitted changes)## [Unreleased] in CHANGELOG.md has entries to releasemaster — this repo's default branch (or the branch the user intends to release from)If any prerequisite fails, stop and tell the user what needs to happen first.
Ask the user if they don't specify one. Suggest based on changes:
Run git log --oneline <previous-tag>..HEAD to see all commits since the last release. Cross-reference each commit against the [Unreleased] entries in CHANGELOG.md.
Look for:
If you find missed changes, draft new entries and show them to the user before adding. Not every commit needs a changelog entry — skip internal refactors, CI tweaks, and implementation details that don't affect the user.
Read CHANGELOG.md. The writing policy lives in cozy/CLAUDE.md ("Changelog" section) — entries target potential new users evaluating cozy, with the KEEP/DROP filters and the "one line per entry, two at most" norm (also stated in the CHANGELOG header).
Before cutting the release, every [Unreleased] entry should clear these release-time checks:
(abc1234) or (abc1234, def5678)Release-specific skip list (in addition to CLAUDE.md's DROP rules):
Past released sections are frozen. Do not rewrite them while tidying — only the new entries are in scope.
If entries need cleanup, fix them before proceeding. Show the user what you changed.
## [X.Y.Z] - YYYY-MM-DD (today's date, ISO 8601)[Unreleased] entries under the new version heading## [Unreleased] empty (no category subsections)[Unreleased] and the previous latest version[Unreleased] link: compare new tag to HEAD0.0.9), not v-prefixedExample link update for releasing 0.0.9 after 0.0.8:
[Unreleased]: https://github.com/nushell-prophet/cozy/compare/0.0.9...HEAD
[0.0.9]: https://github.com/nushell-prophet/cozy/compare/0.0.8...0.0.9
Commit message: release: X.Y.Z
Body includes a brief summary of what's in this release (2–4 lines, not the full changelog).
git tag X.Y.Z
No v prefix. Lightweight tag (no -a), matching existing convention.
Treat the release commit as final once tagged. If the user asks to tweak the changelog after this point, ask whether to amend + retag (clean history, safe while the tag is unpushed) or add a follow-up commit (preserves the tag but leaves it pointing at the pre-tweak version). Default to follow-up commit if they don't have a preference.
After completing, tell the user:
git push && git push --tags — pushing is what makes the release live, since the sbx kit clones cozy from GitHub on every sbx rundocker path: rebuild the image (docker build -t cozy:<version> .). It is not used by sbx