메뉴
Cut a new zdx release. Use when the user asks to release, cut a release, ship a version, publish a build, bump the version, or generate release notes / changelog for zdx. Orchestrates version bump, changelog, and dispatching the manual GitHub Release workflow.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
| name | release |
| description | Cut a new zdx release. Use when the user asks to release, cut a release, ship a version, publish a build, bump the version, or generate release notes / changelog for zdx. Orchestrates version bump, changelog, and dispatching the manual GitHub Release workflow. |
zdx releases are manual and intentional — cut one when a set of features/fixes is ready, not on every commit. The mechanical build+publish lives in .github/workflows/release.yml (workflow_dispatch only). This skill is the human-facing flow that wraps it: pick a version, write a changelog, dispatch, verify.
Cargo.toml → [workspace.package] version. All crates inherit it via version.workspace = true, and zdx --version reports it (clap reads CARGO_PKG_VERSION). Bump it in this one place.v<version> (e.g. version 0.4.0 → tag v0.4.0).aarch64-apple-darwin (macOS), x86_64-unknown-linux-gnu.git fetch --tags
last=$(git tag --sort=-v:refname | head -1)
echo "Last release: ${last:-<none>}"
git log --oneline ${last:+$last..}HEAD
Group commits into a short changelog (Features / Fixes / Other). Prefer the user's framing of "what shipped" over raw commit subjects. If nothing meaningful changed, say so and stop.
Semver on root Cargo.toml → [workspace.package] version. Pre-1.0 (0.y.z), so y acts like "major" and z like "patch". Decide by scanning the conventional-commit types in git log <last-tag>..HEAD:
| Commits since last release | Bump | Example |
|---|---|---|
Any feat, or any breaking change (! / BREAKING CHANGE) | minor | 0.4.0 → 0.5.0 |
Only fix / perf / refactor / chore / docs / test / build / ci (nothing users can newly invoke, nothing breaking) | patch | 0.4.0 → 0.4.1 |
Rule of thumb: one feat or ! anywhere in the range forces a minor; an all-fixes/chores/docs range is a patch. Pre-1.0 keeps breaking changes in the minor slot (no major bump until 1.0). Confirm the version with the user if unsure.
This type-based decision assumes every commit follows Conventional Commits (
type(scope): summary), which thegit-workflowskill already enforces. If the range has non-conventional subjects you can't classify, fall back to judging by actual user-visible behavior — any new user-invocable capability → minor; otherwise patch — and lean on the user's framing of "what shipped" from step 1.
Edit crates/zdx-cli/Cargo.toml, then keep the lockfile in sync and verify:
cargo update -p zdx --precise <new-version> # refresh Cargo.lock entry
just ci-fast
Commit only the version bump:
git add crates/zdx-cli/Cargo.toml Cargo.lock
git commit -m "release: v<new-version>"
Push to master (ask first — pushing is remote-touching):
git push origin master
The workflow tags the current master HEAD, builds the binaries, and publishes a GitHub Release with auto-generated notes.
gh workflow run release.yml -f tag=v<new-version>
# add -f prerelease=true for a pre-release
Watch it:
gh run watch "$(gh run list --workflow=release.yml --limit 1 --json databaseId -q '.[0].databaseId')"
--generate-notes gives a baseline. To replace it with the curated changelog from step 1:
gh release edit v<new-version> --notes "<curated changelog markdown>"
gh release view v<new-version>
Confirm both .tar.gz assets are attached and the tag points at the intended commit. Report the release URL back to the user.
workflow_dispatch only by design — no automatic per-commit or nightly releases. Keep it that way unless the user explicitly wants automation.cargo-binstall metadata.GITHUB_TOKEN; no secrets needed for the build+publish itself.Create a ship-first (ship-shaped) implementation plan with demoable MVP phases. Use when a user asks for an implementation plan, MVP plan, shipping plan, or wants to break down a feature into incremental, demoable phases. Emphasizes user journey order and daily-usable increments over polished completeness.
Add, update, or remove models and providers in the zdx LLM registry. Use when the user asks to add a new model, add a new provider, update model pricing or context limits, regenerate default models/config, or says things like "add support for X model", "add the new Y provider", "update pricing for Z", "regenerate models", or "run models update".
Explore options and pick a direction before committing to a goal or plan. Use when the user wants to think through approaches, weigh trade-offs, or decide between alternatives — not yet ready to define success criteria or slice work. Hard rule: no code, files, or implementation until the user explicitly approves a direction.
Shape a fuzzy intention into a concrete, measurable goal with explicit success evidence before starting work. Use when the user asks to define a goal, clarify success criteria, sharpen an objective, or turn "make X better" into something verifiable. Useful as a quick pre-step before planning, debugging, performance work, research, or operations work.
Use for memory-related tasks: saved notes, factual questions that may already be documented, and saving durable information. Prefer Memory_Search and Memory_Get for discovery; use this skill for routing, note-saving, and filing conventions.
Create, edit, validate, and test ZDX automations stored in `$ZDX_HOME/automations/*.md`. Use when users ask to add or modify automation files, recurring jobs, scheduled prompts, or YAML-frontmatter automation definitions.