cozy

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".

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".

Create a jj (Jujutsu) commit. Use only when the user explicitly asks for a jj commit — git is the default workflow. Trigger on "jj commit", "commit with jj", "/jj-commit".

Improve jj (Jujutsu) commit messages while preserving original authorship. Use only when the user explicitly asks — git is the default workflow. Trigger on "improve jj history", "rewrite jj messages", "/jj-improve-history". Optional argument: base revision to compare against (default: main).

Split unrelated changes within a single file into separate jj (Jujutsu) commits. Use only when the user explicitly asks — git is the default workflow. Trigger on "split this file into commits with jj", "/jj-split-file-for-commit <file>". Argument: the file to split.

Cross-reference project documentation against actual code, configs, scripts, and directory structure to find and fix stale or incorrect references. Use this skill whenever the user asks to "validate docs", "check docs against code", "are my docs up to date", "cross-check README", "verify documentation", "docs consistency check", or any variation of reviewing documentation for accuracy. Also trigger when the user has just done a rename, refactor, or dependency change and wants to make sure docs still match reality.

Process commits as instructions — execute `!!` inline markers and `gi: <text>` commit-subject instructions, propagate user-committed choices through the codebase. Use when the user says "git-intent", "process commits", "apply intent", or pastes a `git log` containing `!!` markers or `gi:` subjects.

Squash all commits on the current branch into one, preserving the original history in a git tag. Use when the user says "squash branch" or "git-intent-squash-archive".

Reconcile the cozy design/ notes against the code and patch them in place. Use when the user says "update the design", "reconcile the design notes", "the design notes are stale", "refresh design/", "/update-design" (or the older "update the spec" / "refresh spec/"), or after changing the build order, an install step, the Dockerfile/bootstrap.nu, or the reason something is compiled from source, vendored, or shipped. The target is cozy/design/ — the build-and-rationale notes (one map + per-subsystem files), NOT the README or CLAUDE.md.

Render a Nushell table as an ASCII chart in the terminal using gnuplot's dumb terminal. Use when the user asks to "plot", "chart", "graph", or "visualize" tabular data they have in a Nushell pipeline or variable, or asks for a line chart, scatter plot, bar chart, or histogram of nu data shown as text in the terminal (no image file). Trigger on "plot this table", "show a chart of", "graph these numbers", "ascii chart", "gnuplot".

Structured problem-framing discipline before solving non-trivial problems. Activate ONLY when the user explicitly requests it — phrases like "frame this", "think through this first", "elegance-first", "analyze before solving", "structure this problem", or "step back and think". Do NOT auto-trigger on general coding or implementation requests.

Audit whether user intent has been preserved in code artifacts. Use this skill when the user asks to check, audit, or verify that their reasoning and decisions were captured in commits, comments, or documentation. Also trigger when the user says "check intent", "did you capture why", "audit the session", "review what was lost", "verify commits match discussion", or references preserving decision context. Trigger at the end of a coding session if the user asks for a final review before finishing.

Extract a minimal, revision-ready specification from an existing codebase. Use this skill whenever the user wants to understand what their project does without reading all the code, needs a spec document generated from existing implementation, asks to "reverse-engineer a spec," wants a project overview or summary for handoff, or says things like "what do we have," "summarize the project," "generate a spec from code," "I need to review the architecture," or "document what exists." Also trigger when the user mentions extracting contracts, interfaces, or feature maps from code. Works best on projects up to ~5K LOC but handles larger ones by focusing on public interfaces.

This skill should be used when the user asks to "create a changelog", "add a changelog entry", "update the changelog", "release a new version", "cut a release", "validate the changelog", "init changelog", "add to unreleased", "prepare release notes", "bump version", mentions "CHANGELOG.md", "keep a changelog", "what changed", or works on release management involving a changelog file. Provides the Keep a Changelog 1.1.0 format and operations.