Create a pull request that follows the project's template and title conventions. Check existing behavior and test coverage, document testing limits, and coordinate self-review or bot review with follow-up on reported issues.
Open a pull request with proper PR template, test coverage, and review workflow. Guides agents through creating a PR that follows repo conventions, ensures existing behaviors aren't broken, covers new behaviors with tests, and handles review via bot when local testing isn't possible. TRIGGER when user asks to "open a PR", "create a PR", "make a PR", "submit a PR", "open pull request", "push and create PR", or any variation of opening/submitting a pull request.
Run score Not tested
See how to installopen-pr handles pull request creation from initial checks through review follow-up. It checks that changes are committed and pushed to the remote, reviews formatting checks across the repository, and checks existing tests for affected areas and tests for new behavior. It fills out the PR description while preserving the structure of .github/PULL_REQUEST_TEMPLATE.md, then creates the PR with a title in the required format.
Use it when you want to follow a project's submission rules and organize both the changes and their testing status. When the environment supports sufficient testing, it proceeds with functional testing and self-review. When local verification is limited, it records which tests could not be run and follows the review bot's response.
The skill uses Git and the GitHub CLI, gh. The default target branch is dev. Its review workflow uses the related skills /pr-test, /pr-review, and /pr-address. It waits up to 60 minutes for bot review and reports to the user if no response arrives. Merging requires human approval.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 23, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Before opening the PR:
git push -u origin <branch>)This is critical. Before opening the PR, verify:
If you cannot run the full test suite locally, note which tests you ran and which you couldn't in the test plan.
Read the canonical PR template at .github/PULL_REQUEST_TEMPLATE.md and use it verbatim as your PR body:
cat .github/PULL_REQUEST_TEMPLATE.md### Why / What / How### Changes 🏗️### Checklist 📋<!-- ... -->) with actual content; do not leave them in- [ ] until each step is actually completedPR title must use conventional commit format (e.g., feat(backend): add new block, fix(frontend): resolve routing bug, dx(skills): update PR workflow). See CLAUDE.md for the full list of scopes.
Use gh pr create with the base branch (defaults to dev if no [base-branch] was provided). Use --body-file to avoid shell interpretation of backticks and special characters:
BASE_BRANCH="${BASE_BRANCH:-dev}"
PR_BODY=$(mktemp)
cat > "$PR_BODY" << 'PREOF'
<filled-in template from .github/PULL_REQUEST_TEMPLATE.md>
PREOF
gh pr create --base "$BASE_BRANCH" --title "<type>(scope): short description" --body-file "$PR_BODY"
rm "$PR_BODY"
/pr-test to do E2E manual testing of the PR using docker compose, agent-browser, and API calls. This is the most thorough way to validate your changes before review./pr-review to self-review the PR for correctness, security, code quality, and testing gaps before requesting human review.This is common for agents running in worktrees without a full stack. In this case:
/pr-review locally to catch obvious issues before pushing/review on the PR after creating it to trigger the review botgh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginate and the GraphQL inline threads query. The bot typically responds within 30 minutes, but polling lets the agent react as soon as it arrives./review comment, the same budget
/pr-address and /pr-polish use. If nothing has arrived by then, stop
waiting and tell the user the requested review never came. Never block
indefinitely on a bot./pr-address which has a full polling loop with CI + comment tracking# After creating the PR:
PR_NUMBER=$(gh pr view --json number -q .number)
gh pr comment "$PR_NUMBER" --body "/review"
# Then use /pr-address to poll for and address the review when it arrives
Once the review bot or human reviewers leave comments:
/pr-address to address review comments. It will loop until CI is green and all comments are resolved.| Skill | When to use |
|---|---|
/pr-test | E2E testing with docker compose, agent-browser, API calls — use when you have a running workspace |
/pr-review | Review for correctness, security, code quality — use before requesting human review |
/pr-address | Address reviewer comments and loop until CI green — use after reviews come in; it can also post the /review trigger itself if the PR has no review yet |
After the PR is created and review is triggered:
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Coordinate multiple Claude Code agents in separate Git worktrees and tmux windows. Assign tasks, inspect progress, help stalled agents resume, and verify PR checks and review feedback before treating work as complete.
Compare performance across releases, environments, or time windows using Sentry data. Report request counts, latency percentiles, and failure rates, with statistical checks that distinguish faster or slower behavior from noise and flag insufficient data.
Work through PR review feedback by fixing code, pushing commits, replying to reviewers, and resolving addressed threads. Monitor automated checks, merge conflicts, and new comments until checks pass and the review work is complete.
Prepare a pull request for merging by repeatedly reviewing changes and addressing feedback. Verify resolved discussions, passing automated checks, and mergeability, then check twice for late comments after the checks finish.
Review a pull request, a proposed code change, for correctness, security, design, and test coverage. Check its explanation and existing feedback, then post findings on relevant code lines with severity labels.
Test a PR or branch through a running application using browser actions and API calls. Compare expected behavior with actual state changes, include failure cases, and post a report with before-and-after screenshots to the PR.