Run all quality checks (tests, lint, typecheck), fix failures, update the changelog, commit, push, and create/update the pull request or merge request.

Verify and Ship After implementing your changes, follow these steps to verify quality and ship the work. 1. Acceptance Criteria Validation (CRITICAL) Use the issue tracker get issue tool to fetch the current issue details. Extract ALL acceptance criteria from the issue description and verify each one is satisfied by the implementation. If no explicit criteria exist, validate against the implied requirements from the issue title and description. 2. Quality Checks Run all applicable quality checks: Tests — Run the full test suite. If tests fail, fix the issues and re run. Retry up to 3 times. If you cannot resolve failures after 3 attempts, proceed and note the failures in your summary. Linting — Run linting tools and fix any issues found. Type checking — Run TypeScript type checking (if applicable) and fix any errors. Code review — Review your changes for quality, consistency, and best practices. Remove any debug code, console.logs, or commented out sections. 3. Changelog Update Check if the project has changelog files: If changelog files exist, diff against the base branch to detect entries already added by this branch: Handling existing entries: If the diff shows this branch already added a changelog entry for the current issue (matching the issue identifier), update that entry in place (e.g., to add the PR/MR link or refine the description). Do NOT add a duplicate entry. If the diff shows this branch added changelog entries for a different issue or no entries at all, add a new entry. Adding or updating entries: Place entries under [Unreleased] in the appropriate subsection ( Added , Changed , Fixed , Removed ) Focus on end user impact — be concise but descriptive Include the Linear issue identifier and PR/MR link (format: ([ISSUE ID](linear url), [ NUMBER](PR OR MR URL)) ) Follow [Keep a Changelog](https://keepachangelog.com/) format 4. Commit and Push Stage all relevant changes (including changelog updates) Commit with clear, descriptive messages following the project's commit conventions Push to the remote repository 5. Create or Update PR/MR Determine the platform from the repository context ( <github url or <gitlab url in the issue context). Use the appropriate tool for the platform. GitHub (when <github url is present) GitLab (when <gitlab url is present) PR/MR Description Update the PR/MR with a comprehensive description: Assignee attribution : If <github username is available in the assignee context, add Assignee: @username ([Display Name](linear profile url)) at the top of the body. If only a linear profile URL is available, use Assignee: [Display Name](linear profile url) . Summary of changes, implementation approach, and testing performed Link to the Linear issue Cyrus marker : Include <! generated by cyrus as a hidden HTML comment at the end of the body Interaction tip : Add this at the end (before the marker), using the bot username from <github bot username or <gitlab bot username in the <agent context block of the system prompt. If <agent context is not present, default to cyrusagent : Remove any "WIP:" or "Draft:" prefix from the title. Check <agent guidance — only mark the PR/MR as ready if guidance does NOT specify keeping them as drafts. Verify the PR/MR targets the correct base branch from <base branch in the issue context.

verify-and-ship