open-pr
- Repo stars 184,730
- Author updated Live
- Author repo AutoGPT
- Domain
- AI
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @Significant-Gravitas · no license declared
- Token usage
- Moderate
- Setup complexity
- Manual integration
- External API key
- Not required
- Operating systems
- Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: open-pr
description: Open a pull request with proper PR template, test coverage, and review workflow. Guides agents t…
category: ai
runtime: Docker
---
# open-pr output preview
## PART A: Task fit
- Use case: 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..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Step 1: Pre-flight checks / Step 2: Test coverage / Existing behavior is not broken” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “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.”.
- **02** When the source has headings, the agent prioritizes “Step 1: Pre-flight checks / Step 2: Test coverage / Existing behavior is not broken” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/pr-test`, `/pr-review`, `/review`, `/pr-address`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Step 1: Pre-flight checks / Step 2: Test coverage / Existing behavior is not broken”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: open-pr
description: Open a pull request with proper PR template, test coverage, and review workflow. Guides agents t…
category: ai
source: Significant-Gravitas/AutoGPT
---
# open-pr
## When to use
- Open a pull request with proper PR template, test coverage, and review workflow. Guides agents through creating a PR t…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Step 1: Pre-flight checks / Step 2: Test coverage / Existing behavior is not broken” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "open-pr" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Step 1: Pre-flight checks / Step 2: Test coverage / Existing behavior is not broken
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Open a Pull Request
Step 1: Pre-flight checks
Before opening the PR:
- Ensure all changes are committed
- Ensure the branch is pushed to the remote (
git push -u origin <branch>) - Run linters/formatters across the whole repo (not just changed files) and commit any fixes
Step 2: Test coverage
This is critical. Before opening the PR, verify:
Existing behavior is not broken
- Identify which modules/components your changes touch
- Run the existing test suites for those areas
- If tests fail, fix them before opening the PR — do not open a PR with known regressions
New behavior has test coverage
- Every new feature, endpoint, or behavior change needs tests
- If you added a new block, add tests for that block
- If you changed API behavior, add or update API tests
- If you changed frontend behavior, verify it doesn't break existing flows
If you cannot run the full test suite locally, note which tests you ran and which you couldn't in the test plan.
Step 3: Create the PR using the repo template
Read the canonical PR template at .github/PULL_REQUEST_TEMPLATE.md and use it verbatim as your PR body:
- Read the template:
cat .github/PULL_REQUEST_TEMPLATE.md - Preserve the exact section titles and formatting, including:
### Why / What / How### Changes 🏗️### Checklist 📋
- Replace HTML comment prompts (
<!-- ... -->) with actual content; do not leave them in - Do not pre-check boxes — leave all checkboxes as
- [ ]until each step is actually completed - Do not alter the template structure, rename sections, or remove any checklist items
PR 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"
Step 4: Review workflow
If you have a workspace that allows testing (docker, running backend, etc.)
- Run
/pr-testto 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. - After testing, run
/pr-reviewto self-review the PR for correctness, security, code quality, and testing gaps before requesting human review.
If you do NOT have a workspace that allows testing
This is common for agents running in worktrees without a full stack. In this case:
- Run
/pr-reviewlocally to catch obvious issues before pushing - Comment
/reviewon the PR after creating it to trigger the review bot - Poll for the review rather than blindly waiting — check for new review comments every 30 seconds using
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews --paginateand the GraphQL inline threads query. The bot typically responds within 30 minutes, but polling lets the agent react as soon as it arrives. - Do NOT proceed or merge until the bot review comes back
- Address any issues the bot raises — use
/pr-addresswhich 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
Step 5: Address review feedback
Once the review bot or human reviewers leave comments:
- Run
/pr-addressto address review comments. It will loop until CI is green and all comments are resolved. - Do not merge without human approval.
Related skills
| 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 |
Step 6: Post-creation
After the PR is created and review is triggered:
- Share the PR URL with the user
- If waiting on the review bot, let the user know the expected wait time (~30 min)
- Do not merge without human approval
Decide Fit First
Design Intent
How To Use It
Boundaries And Review