القائمة
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.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| 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:
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".