release
release - Versioning Stage
Invariants
- Release only merged
Ready To Shiptasks. - Keep changelog entries user-focused.
- Do not include unmerged pull requests.
- Do not rewrite existing tags without explicit user approval.
Runtime adapters may expose this stage as a slash command, menu action, or natural-language skill invocation. The portable stage name is release.
Invocation
Supported version inputs:
More from eljun/workflow-skills
document
Use this skill after verification passes and the user approves the result. Updates feature docs, user guides, task retrospectives, LEARNINGS.md, and durable project instructions when the completed task changes reusable workflow knowledge.
43task
Use this skill when the user wants to plan a new feature, bug fix, enhancement, documentation update, or chore before implementation. Creates or updates a reviewed task document in docs/task/ and updates TASKS.md, then stops for human approval.
42test
Use this skill after implementation passes the quality gate and the user wants verification. Runs capability-based checks from the task document, including unit, integration, browser, API, CLI, CI, or manual checks, and writes docs/testing/*.md.
42implement
Use this skill when an approved task document already exists and the user wants code or content changes implemented. Reads docs/task/*.md, follows the implementation steps, updates TASKS.md, and can run the approved auto chain from implementation onward.
42simplify
Use this skill after implementation and before testing to run a quality gate. Reviews changed files against the task document, checks maintainability standards, classifies plan deviations, and decides whether the work can proceed to verification.
41ship
Use this skill after documentation is complete and the task is approved. Runs pre-ship checks, prepares a branch or pull request, updates TASKS.md, and leaves release timing to the release stage.
40