菜单
Open a pull request on pascalorg/editor using the repo's PR template. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/pascalorg/editor --skill open-pr命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | open-pr |
| description | Open a pull request on pascalorg/editor using the repo's PR template. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo. |
| allowed-tools | Bash(git *) Bash(gh *) Read |
Open a pull request against pascalorg/editor 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 build sanity check if the change is non-trivial:
bun typecheck
bun build
Don't open the PR with a broken build.
The template is at .github/pull_request_template.md. Read it before composing the body — the section headings and checklist items are the source of truth, not your memory of them.
cat .github/pull_request_template.md
Mirror the template exactly:
## What does this PR do? — one paragraph or a short bullet list. Link related issues with Fixes #123 when applicable.## How to test — numbered, concrete reviewer steps (commands to run, what to click, expected outcome).## Screenshots / screen recording — if the change is visual, paste a recording link or note that one will be added. If purely non-visual (refactor, internal API), say so explicitly so the reviewer knows nothing is missing.## Checklist — copy the boxes verbatim, ticking the ones already verified.git push -u origin HEAD
Check for an existing PR first:
gh pr view --json number,url,title,body 2>/dev/null
Pass the body via HEREDOC to preserve markdown formatting:
gh pr create --title "short, scope-prefixed title" --body "$(cat <<'EOF'
## What does this PR do?
<one-paragraph description; link issues>
## How to test
1. <step>
2. <step>
3. <step>
## Screenshots / screen recording
<link or "N/A — non-visual change">
## Checklist
- [x] I've tested this locally with `bun dev`
- [x] My code follows the existing code style (run `bun check` to verify)
- [ ] I've updated relevant documentation (if applicable)
- [x] This PR targets the `main` branch
EOF
)"
Keep the title under ~70 characters. Use a scope prefix when there's an obvious one (viewer:, core:, editor:, mcp:).
Do not recreate the PR. Refresh the existing body so it reflects everything currently on the branch, while keeping the template structure and any reviewer-meaningful state the user already set.
Capture the existing body and the full branch history:
gh pr view --json number,body -q '.number, .body' > /tmp/existing-pr.txt
git log --oneline main..HEAD
git diff --stat main..HEAD
Reconstruct the body section-by-section. Keep the four template headings in the same order (## What does this PR do?, ## How to test, ## Screenshots / screen recording, ## Checklist). For each section:
Fixes #123 / Refs #123 lines from the old body.[x] vs [ ]) for every item that still exists in the template. Add any new template items as unchecked.If the old body contains extra sections the template doesn't have (e.g. a manual "Notes" block), keep them at the end.
Apply the update:
gh pr edit <number> --body "$(cat <<'EOF'
## What does this PR do?
…
EOF
)"
Use gh pr edit --title only if the branch's scope has clearly changed; otherwise leave the title alone.
Print the PR URL so the user can confirm the edit.
Return: