Push the current issue branch and create a GitHub pull request with an explicit user approval gate before any push. Embeds verification screenshots/GIFs in the PR body by default when evidence exists under tmp/issue-<N>-*/.
Orchestrate the full plan-branch-implement-review-verify-commit-push-pr pipeline for a GitHub issue, ending in a pushed branch and an open PR. Invokes plan-github-issue, then branch-from-issue, then capture-before + implement-plan, then code-review + verify-fix-evidence (in parallel), then commit-issue, then push-pr-issue, pausing at user approval gates (unless --auto). Heavy stages run in worker subagents (default composer-2.5-fast) while planning, gates, branch, commit, and push stay inline. Use only when the user explicitly wants to ship end to end through push + PR, e.g. "ship
Create a new local git branch off `origin/qa` named after a GitHub issue, using the format `<prefix>/<issue-number>-<2-4-word-slug>` (for example `feat/1111-judge-dashboard-fix`). The prefix is picked from the issue's labels (`feat/`, `fix/`, `chore/`). Use when the user asks to create a branch from a GitHub issue, start work on an issue, branch off qa for issue #N, or says things like "make a branch for issue 1234".
Review code for correctness, security, readability, performance, and test coverage, with general best practices first and a Rails-specific section for Ruby on Rails projects (RSpec, Pundit, ActiveRecord N+1, Stimulus/Turbo, StandardRB, Brakeman). Use when the user asks for a code review, says "review this", looks at a PR/diff, or asks for feedback on a change.
Stage and commit changes on an issue branch with a one-line Conventional Commits message aligned to the branch prefix (`feat:`, `fix:`, `chore:`) and the issue number as the scope. No body, no footer. Shows the drafted message for user approval, then runs a single `git commit`. Never pushes. Use when the user asks to commit the changes, finalize the issue with a commit, or says "commit this", "make the commit", "wrap up issue #N with a commit".
Implement a feature from a Cursor plan file produced by the CreatePlan tool. Use when the user asks to implement, build, execute, run, or start a plan - especially right after a plan was created by a planning skill like plan-github-issue. Stops before any git commit so the user can review.
Plan the implementation of a GitHub issue by issue number. Fetches the issue and its comments via the gh CLI, explores the repo for relevant code, and produces a concrete implementation plan via CreatePlan. Use when the user asks to plan, scope, or design the implementation of a GitHub issue / ticket by number (for example "plan issue #123", "plan GH 456", "scope ticket #789").
Verify a code change against the issue's acceptance criteria by mapping each AC item to a before/after screenshot pair (for static UI items), a before/after pair plus an animated GIF (for action-based UI items), or a test (for non-UI items), capturing numbered evidence into tmp/issue-<N>-<fix-slug>/, and re-running the modified test files. Use when the user asks to verify the fix, capture evidence, prove this works, take screenshots, record the action, capture a GIF, or demonstrate that a bug is resolved.