Menu
Create a new release by bumping versions, tagging, pushing, and generating release notes. Use when the user wants to release a new version.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
List tasks with optional filters. Use when the user wants to see their tasks.
List tasks with optional filters. Use when the user wants to see their tasks.
Get the next recommended task to work on. Use when the user asks what to work on next or needs a task assignment.
Create a new task file following the taskmd specification. Use when the user wants to add a new task to the project.
Split a large task into smaller sub-tasks. Accepts a task ID, evaluates complexity, and creates sibling task files if warranted.
Update an existing task's fields (status, priority, title, tags, dependencies, etc.). Use when the user wants to modify a task's properties.
| name | release |
| description | Create a new release by bumping versions, tagging, pushing, and generating release notes. Use when the user wants to release a new version. |
| metadata | {"internal":true} |
Create a new versioned release of the project. This skill mirrors the process in scripts/release.sh โ keep them in sync.
The user's input is in $ARGUMENTS (a semver version like 1.2.3 or v1.2.3, optionally followed by flags).
--dry-run: Perform all validation steps but make no changes. Report what would happen.--no-push: Create the commit and tag locally but do not push to remote.Parse arguments: Extract the version from $ARGUMENTS. Strip any leading v prefix. If no version is provided, ask the user for one.
Validate version format: Must be valid semver (e.g., 0.1.0, 1.2.3, 2.0.0-beta.1).
Pre-flight validation:
git status --porcelain โ if there are uncommitted changes, stop and tell the user to commit or stash first.git fetch origin and verify local/remote are in sync.If --dry-run, stop here and report that validation passed.
Generate release notes from the commit history since the last tag:
git log $(git describe --tags --abbrev=0 HEAD~1 2>/dev/null || git rev-list --max-parents=0 HEAD)..HEAD --pretty=format:"- %s" --no-merges
Don't use these raw commit messages as the release notes. Instead, investigate what each commit/task actually did (read task files, check diffs) and write polished, user-facing release notes grouped by category (e.g., New Commands, CLI Improvements, Web Dashboard, Core, Documentation, Removed). Present the release notes to the user before proceeding.
Write the release notes to a file at /tmp/taskmd-release-notes-X.Y.Z.md using the Write tool.
If --no-push, run the script without pushing:
echo "y" | scripts/release.sh --no-push --notes-file /tmp/taskmd-release-notes-X.Y.Z.md X.Y.Z
Report what was created locally and stop.
Run the release script to handle the full release lifecycle:
echo "y" | scripts/release.sh --notes-file /tmp/taskmd-release-notes-X.Y.Z.md X.Y.Z
The script has an interactive confirmation prompt โ piping echo "y" auto-confirms it. The user already approved the release when they confirmed the release notes, so no second confirmation is needed. The script handles everything: version bumps, commit, tag, push, CI workflow monitoring, and applying release notes after CI creates the release.
Report success with the release tag and a link to the GitHub releases page.