Menu
Use when opening a pull request, pushing changes for review, or when the user says "open PR", "create PR", "send for review", or "get this merged".
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
CLI tool for interacting with MCP (Model Context Protocol) servers. Use when invoking MCP tools, managing MCP servers, or working with MCP-based APIs. Triggers on "MCP server", "mcpli", "invoke MCP tool", or any MCP server interaction.
Use when executing a plan or implementing a coding task. Turns a plan or clear request into working code, tests, and verification.
Use for researching, checking facts, looking things online, comparing options, etc.
Use when asked to plan a coding task. Produces a written implementation plan (research plus steps) for a code change.
Use before performing a rebase or resolving rebase conflicts.
Reflect on the current conversation to find ways to improve agent skills and config. Use for "retro", "retrospective", "reflect on this conversation", "what could be improved", or "extract a skill from this".
| name | open-pr |
| description | Use when opening a pull request, pushing changes for review, or when the user says "open PR", "create PR", "send for review", or "get this merged". |
Follow the workflow below, don't skip any steps. The goal is to drive the current work to a merge-ready PR. Opening the PR is not the finish line: the task completes only when the PR is approved with CI green, or the user tells you to stop.
Load other pull request and commit related skills if available, they may add different requirements.
Determine where things stand and pick the path to a pushed branch with an open PR.
Examples:
Before opening the PR, make sure the work sits on top of the latest remote main. Run a git fetch to make sure and rebase before pushing when on a branch.
Name the branch after the ticket if one exists (e.g. PROJ-123-short-description) and reference the ticket in the PR body. Commit the relevant changes.
Push the branch and open the PR, using the repository template if present. Request reviewers (from CODEOWNERS, recent PR reviewers, or collaborators). If none can be determined, say so and ask. Do not open with no reviewers silently.
Use a succint pull request description that describes in high level why we're doing this and the general strategy used. Don't include explanation of individual technical details unless they're surprising.
Opening the PR is not done. Actively wait for CI and react until the PR is merge-ready:
gh pr checks --watch to block until checks finish. Do not stop while checks are queued or running.Post a status block (PR URL, CI state, reviewers requested, merge-ready: yes/no) only when you stop. merge-ready: no is not a reason to stop on its own. Stop only when merge-ready is yes (approved + CI green) or the user tells you to stop.