Menu
Open a pull request from the current branch with a clean title, body, and test plan. Use when the user asks to open/create a PR, push and PR, or ship a branch.
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
Create a new plan file under plans/ with the correct prefix, frontmatter, and skeleton sections. Use when the user asks to start a plan, open a charter, kick off a new feature/investigation, or when non-trivial work is about to start without an existing plan covering it.
Promote stable behavior from a plan into wiki/ and satisfy the plan's wiki_sync block. Use when a plan is moving toward implemented, when a feature has stabilised and isn't reflected in the wiki yet, or when the user asks to "sync the wiki", "update docs from the plan", or "close out the plan".
| name | open-pr |
| description | Open a pull request from the current branch with a clean title, body, and test plan. Use when the user asks to open/create a PR, push and PR, or ship a branch. |
| allowed-tools | Bash(git *) Bash(gh *) Read |
Open a pull request against main from the current branch.
git status # confirm working tree state
git branch --show-current # confirm we're on a feature branch, not main
git log --oneline main..HEAD
Stop if:
main. Ask the user to create a feature branch first.main. Nothing to open a PR for.Run a sanity check if the change is non-trivial:
bun lint
bun build
Don't open the PR with a broken build.
If the branch introduces or changes a route, store field, PB collection, S3 contract, or any rule that future agents will need to know about, the matching plans/*.md plan's wiki_sync block must be satisfied before this PR ships, or the work has to ship as a follow-up commit on the same branch.
rg -l "status: (verification|implemented)" plans/*.md
If a relevant plan has wiki_sync.required: true and wiki_sync.done: false, run the update-wiki-from-plan skill first.
If there's no plan covering the change, decide whether one should exist (see start-plan). Refactors and bug fixes with no rule change don't need one — proceed.
A repo PR template may exist later (.github/pull_request_template.md). If present, read it first and mirror the section headings verbatim. Otherwise use this default:
## What does this PR do?
<one paragraph; link related plans with plans/<plan-id>.md when applicable>
## How to test
1. <step — commands, what to click, expected outcome>
2. <…>
## Wiki / plan updates
- Plan: <plans/<plan-id>.md> — status now `<status>`
- Wiki: <wiki/architecture/<page>.md> — <one-line summary of the rule added/sharpened>
- N/A — non-rule change
## Screenshots / screen recording
<link, or "N/A — non-visual change">
## Checklist
- [x] `bun lint` passes
- [x] `bun build` passes
- [ ] Wiki updated (or N/A explained above)
git push -u origin HEAD
Check for an existing PR first:
gh pr view --json url 2>/dev/null
If none exists, create it with the body via HEREDOC to preserve markdown:
gh pr create --title "<short, scope-prefixed title>" --body "$(cat <<'EOF'
<body from step 3>
EOF
)"
Keep the title under ~70 characters. Use a scope prefix when there's an obvious one (hub:, editor:, play:, admin:, data:, docs:).
If a PR already exists, print its URL and stop — don't recreate.
Return: