菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/wass08/character-studio --skill open-pr命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
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: