Open Pull Request
Create a reviewable pull request whose title, body, and commits explain the change and its evidence. The next consumer is the reviewer. Done means the requested description is returned or the remote pull request URL is confirmed.
Mandate
A description-only request is read-only. A request to open a pull request authorizes creating a feature branch when needed, staging only the task's files, committing those files, pushing the branch, and creating or updating its pull request. It does not authorize staging unrelated work, rewriting another contributor's work, merging, or changing remote settings.
Workflow
- Read repository state, current branch, intended changed files, remote, default branch, and any open pull request for the current head. Treat a failed pull-request lookup as unknown, not as proof that no pull request exists.
- Choose the route:
- Description only: compose and return the title and body. Do not modify the remote.
- Existing pull request: push the scoped commits, then update its body only when the request includes that change.
- New pull request: create a feature branch if the current branch is the default branch or detached, then commit, push, and create it.
- When a branch must be created from the default branch, read
references/branch-creation.md. Do not stash, reset, or switch through conflicting local changes automatically.
- Stage explicit files only. Keep unrelated working-tree changes out of the commit. Split commits only when the change has clearly independent reviewer value.
- Read
references/pr-description-writing.md. Compose from the complete change range, not the latest commit. Lead with the outcome, state validation or its limitation, and retain required project template fields.
- Recheck the branch and existing pull request immediately before pushing or creating one. If the state is still unknown, stop and report the blocker rather than risk a duplicate pull request.
- Apply the body through a temporary file so its literal content survives the command. Confirm the resulting URL, title, and body when the platform allows it.
Boundaries
Use the repository's active conventions for commit messages and pull request structure. Never add generated-by text, authorship claims, or co-author trailers to a commit message, title, or body. Do not claim a check ran unless captured output proves it.
Output
Lead with the pull request URL or the drafted title. State the branch, commits made, validation evidence, and any known limitation. For description-only work, return the title and body without applying it.
1---2name: open-pr3description: Commit scoped changes, push a branch, and open or update a GitHub pull request. Use when the user asks to open a pull request, commit and push work, or write or update a pull request description. Do not use to implement work or merge a pull request.4---56# Open Pull Request78Create a reviewable pull request whose title, body, and commits explain the change and its evidence. The next consumer is the reviewer. Done means the requested description is returned or the remote pull request URL is confirmed.910## Mandate1112A description-only request is read-only. A request to open a pull request authorizes creating a feature branch when needed, staging only the task's files, committing those files, pushing the branch, and creating or updating its pull request. It does not authorize staging unrelated work, rewriting another contributor's work, merging, or changing remote settings.1314## Workflow15161. Read repository state, current branch, intended changed files, remote, default branch, and any open pull request for the current head. Treat a failed pull-request lookup as unknown, not as proof that no pull request exists.172. Choose the route:18 1. Description only: compose and return the title and body. Do not modify the remote.19 2. Existing pull request: push the scoped commits, then update its body only when the request includes that change.20 3. New pull request: create a feature branch if the current branch is the default branch or detached, then commit, push, and create it.213. When a branch must be created from the default branch, read `references/branch-creation.md`. Do not stash, reset, or switch through conflicting local changes automatically.224. Stage explicit files only. Keep unrelated working-tree changes out of the commit. Split commits only when the change has clearly independent reviewer value.235. Read `references/pr-description-writing.md`. Compose from the complete change range, not the latest commit. Lead with the outcome, state validation or its limitation, and retain required project template fields.246. Recheck the branch and existing pull request immediately before pushing or creating one. If the state is still unknown, stop and report the blocker rather than risk a duplicate pull request.257. Apply the body through a temporary file so its literal content survives the command. Confirm the resulting URL, title, and body when the platform allows it.2627## Boundaries2829Use the repository's active conventions for commit messages and pull request structure. Never add generated-by text, authorship claims, or co-author trailers to a commit message, title, or body. Do not claim a check ran unless captured output proves it.3031## Output3233Lead with the pull request URL or the drafted title. State the branch, commits made, validation evidence, and any known limitation. For description-only work, return the title and body without applying it.
robsonrung