Supervise a set of slay tasks through planning, execution, and verification
Commit changes, mark the current task as done, and close its tab
Manage tasks, subtasks, tags, and templates via the slay CLI
Automatically title tasks based on conversation context
Manage task artifacts (files, folders) via the slay CLI
Full CLI reference for slay — orchestrates all slay domain skills
| name | release |
| description | Create a new release for SlayZone |
| trigger | none |
Create a new release for SlayZone. The version argument is: $ARGUMENTS
Read the current version from packages/apps/app/package.json.
Interpret $ARGUMENTS:
patch — bump the patch number (e.g. 0.2.0 -> 0.2.1)minor — bump the minor number (e.g. 0.2.1 -> 0.3.0)major — bump the major number (e.g. 0.3.0 -> 1.0.0)0.5.0)Invoke the slay-auto-title skill to rename the current task to reflect the release (e.g. Release v<new-version>). Skip if the task title already matches.
Update "version" in both:
packages/apps/app/package.jsonpackages/apps/cli/package.jsonRun npx changelogen --from <previous-tag> --to main --output CHANGELOG.md --hideAuthorEmail (use pnpx if available).
The tool will prepend a ## <old-tag>...main section to CHANGELOG.md. After it runs:
## <old-tag>...main to ## v<new-version>compare/<old-tag>...v<new-version>Read packages/apps/app/src/renderer/src/components/changelog/changelog-data.json.
Add a new entry at the top of the JSON array for the new version:
version: the new version string (without v prefix)date: today's date in YYYY-MM-DD formattagline: a short, catchy 2-4 word tagline summarizing the release themeitems: user-facing changes only (breaking changes, features, improvements, fixes). Skip CI, docs, tests, chores, website-only changes. Keep descriptions concise (1 sentence). Match the tone and style of existing entries. List breaking items first, then features, improvements, fixes.Categories:
breaking — backwards-incompatible changes that require user action (migrations, removed features, changed defaults, renamed settings)feature — new user-facing capabilitiesimprovement — enhancements to existing featuresfix — bug fixes users would noticeDeduplicate by feature, not by commit. One feature often spans multiple commits (initial impl + follow-up fixes + polish + refactor). Collapse all commits touching the same user-facing capability into a single entry. Group by what the user sees, not by git history. If a feature was added then later fixed in the same release window, emit one entry describing the final state (usually feature, not feature + fix). Same for iterative improvements to one area — merge into one improvement entry.
git add CHANGELOG.md packages/apps/app/package.json packages/apps/cli/package.json packages/apps/app/src/renderer/src/components/changelog/changelog-data.json
git commit -m "release: v<new-version>"
Stop and ask the user to confirm before tagging and pushing. Show them:
Only after confirmation:
git tag v<new-version>
git push && git push origin v<new-version>
Print a summary:
v* tag push — builds macOS/Linux/Windows + deploys Convexpackage.json in the monorepo root — only packages/apps/app/package.json matters for electron-buildergit push