Ticket → Ship

The ticket-shaped parts of shipping. The PR mechanics live in their own skills — this is what a tracker adds on top.

Steps

Read the ticket and its latest comments, then list existing PRs before starting (acli, Jira, Linear, gh). With acli, request --fields summary,description,status,comment,issuelinks --json: the default view omits comments, which can contain reopened QA scope. Read the existing PR diff as well as its body; follow-up commits can invalidate the body's implementation claims.
Confirm the correct base branch(es) before starting — some orgs need a release branch plus the default (stacked-pr). Never assume; verify the org's rule.
Find the existing PR or start one (work → pr-update), then drive it mergeable (pr-ready) and polish before handoff (clean).
Read the repository's ticket/label guidance before selecting a handoff state; don't substitute generic workflow names. In MR, use .claude/skills/create-pr/SKILL.md and teams.md for label rules. For an existing DOTCOMPB PR returned by QA and then fixed, the user's retest handoff is In Test with Pending QA Review, not a reset to In Code Review. Preserve the ticket-driven Needs UI Review label. Report CI/deployment blockers separately; In Test does not mean merge-ready. Link the PR and add a factual retest update when the user requests the handoff.
Draft the stakeholder update — Slack or a ticket comment, short, no-tropes. Don't send it unless asked.