Menu
Approve (submit an approving review) and squash-merge a GitHub PR given only its number. Optionally file a follow-up issue at the same time. Use when the user says "approve and merge PR 123", "ship PR 123", "om-approve-merge 123", or gives a PR number with intent to merge.
| name | om-approve-merge-pr |
| description | Approve (submit an approving review) and squash-merge a GitHub PR given only its number. Optionally file a follow-up issue at the same time. Use when the user says "approve and merge PR 123", "ship PR 123", "om-approve-merge 123", or gives a PR number with intent to merge. |
Given a single PR number, submit an approving review and then squash-merge it. Optionally, if the user supplies a follow-up, file a tracking issue in the same run. Convenience skill for the code-review process — keep it fast and low-friction.
2805.owner/repo.Resolve the PR and sanity-check it. Run:
gh pr view <number> --json number,title,state,isDraft,mergeable,mergeStateStatus,reviewDecision,headRefName,url,author
state != OPEN, stop and report (already merged/closed).isDraft == true, stop and ask whether to mark ready first (gh pr ready <number>). Don't merge a draft silently.mergeable == "CONFLICTING", stop and report the conflict — do not attempt the merge.title, url, and author.login for the summary and any follow-up.Approve. Submit an approving review:
gh pr review <number> --approve --body "Approved."
gh rejects self-approval (you authored the PR), report that GitHub forbids approving your own PR and ask whether to proceed straight to merge anyway.Squash-merge. Default flags:
gh pr merge <number> --squash
--auto instead of a plain merge only if the user asked to merge once checks pass, or if required checks are still running (mergeStateStatus == "BLOCKED" / "BEHIND" due to pending CI).--delete-branch only if the user asks to delete the branch.mergeStateStatus and stop — don't force anything.Optional follow-up (only if one was provided — see below).
Report the outcome: PR title, number, url, whether it merged now or is queued for auto-merge, and the follow-up issue URL if one was created.
If the user provides a follow-up alongside the merge request, file it after the merge step succeeds (so the issue can reference a merged PR). Two shapes are supported:
author.login).## Follow-up from #<number> header linking the PR, the ask quoted verbatim, an ### Acceptance criteria checklist, and a Related: #<number> footer.gh issue create --repo <owner>/<repo> --title "<title>" --assignee <login> --label <labels> --body "<body>"
om-followup-issue-from-pr skill, which extracts the actionable comment and applies the same assignee rule (@-mention wins, else PR author). Don't duplicate its logic here.Report the created issue URL in the final summary. If no follow-up was provided, skip this entirely.
--admin to bypass branch protection unless the user explicitly asks.--repo <owner>/<repo> on every gh call when the user specified one or you're not inside the target repo.om-followup-issue-from-pr: an explicit @-mention wins; otherwise the PR author.--auto queue), so it references real merged work.Turn a review comment into a follow-up GitHub issue assigned to the PR author. Paste a link to a PR or a PR comment; the skill extracts the actionable ask from the comment, gathers PR context, and opens a tracking issue. Assignee is the comment's @-mention if present, otherwise the PR author. Use during code review when the user says "make a follow-up issue", "create an issue for this", "om-followup", or pastes a PR/comment link with that intent.
Browser-first GitHub issue fix workflow. Claims a GitHub issue, checks for existing solutions, creates an isolated worktree, reproduces the bug through the Browser against the ephemeral integration environment, records a failing Playwright integration test, fixes the bug, makes the test green, runs validation/review gates, pushes a branch, and opens a PR linked to the issue.
Scaffold a new module from scratch with all required files and conventions. Use when creating a new module, adding a new entity with CRUD, or bootstrapping module features (API routes, backend pages, DI, ACL, events, search). Triggers on "create module", "new module", "scaffold module", "add module", "bootstrap module", "generate module".
Implement a specification (or specific phases) using coordinated subagents with unit tests, integration tests, docs, and code-review compliance. Tracks progress by updating the spec. Triggers on "implement spec", "implement phases", "build from spec", "code the spec".
Review code changes for architecture, security, conventions, and quality compliance. Use when reviewing pull requests, code changes, or auditing code quality.
Design entities, relationships, and manage the migration lifecycle. Use when planning a data model, designing entities, choosing relationship patterns, adding cross-module references, or managing database migrations. Triggers on "design entity", "data model", "add entity", "database schema", "migration", "relationship", "many-to-many", "junction table", "foreign key", "jsonb", "add column".