ship
ship - Pull Request Stage
Invariants
- Ship only approved and documented tasks.
- Run available pre-ship checks before creating a pull request.
- Do not auto-merge.
- Keep released-version work for the
releasestage.
Runtime adapters may expose this stage as a slash command, menu action, or natural-language skill invocation. The portable stage name is ship.
Workflow
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.
41release
Use this skill when one or more ready-to-ship tasks have been merged and the user wants a versioned release. Generates changelog entries, creates tags or release notes, and moves merged tasks to Shipped.
39