Pull Request Manager
Open PR
Open or update a pull request on pascalorg/editor from the current branch, describing only what the branch actually did. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo.
--- name: open-pr description: Open or update a pull request on pascalorg/editor from the current branch, describing only what the branch actually did. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo. metadata: internal: true allowed-tools: Bash(git *) Bash(gh *) Read --- Open (or refresh) a pull request against `pascalorg/editor` from the current branch. ## 1. What is actually on the branch ```bash git branch --show-current # not main git status --short # nothing uncommitted you weren't asked to commit base=$(git merge-base HEAD origin/main) git log --oneline --first-parent --no-merges "$base"..HEAD git diff --stat "$base"..HEAD
Overview
Open (or refresh) a pull request against pascalorg/editor from the current branch.
Manual install (npx, ZIP)
Claude Code
npx skills add pascalorg/editor --skill open-pr -g -a claude-codeClaude Code (degit)
npx degit pascalorg/editor/.agents/skills/open-pr#main ~/.claude/skills/open-prClaude.ai / desktop
Codex, Cursor, other agents
Connects with Agent Alley MCP · agentalley.io/mcp
Files included
SKILL.md2.4 KB
Read SKILL.md here
SKILL.md
Show the full text51 lines
Open (or refresh) a pull request against pascalorg/editor from the current branch.
1. What is actually on the branch
git branch --show-current # not main
git status --short # nothing uncommitted you weren't asked to commit
base=$(git merge-base HEAD origin/main)
git log --oneline --first-parent --no-merges "$base"..HEAD
git diff --stat "$base"..HEAD
The PR describes only these commits and this diff. Work that arrived by merging main, reverted commits, and patch-equivalent cherry-picks are not this PR's claims. If a file in the diff has no commit on the branch explaining it, stop and ask.
Run bun run check-types when the change is non-trivial; never claim a check you did not run.
2. Body = the repo template
.github/pull_request_template.md is the source of truth for headings and checklist. Fill it from §1, not from memory:
- What does this PR do? — the result, one paragraph or a short list;
Fixes #123when applicable. - How to test — numbered, concrete reviewer steps with the expected outcome. Automated commands only if you ran them.
- Screenshots / screen recording — link,
Not added yet.for a visual change without media, orN/A — non-visual change. - Checklist — copy verbatim; tick only what was verified (
bun devonly after a real local run).
Title: under ~70 characters, a concrete result (not "update"/"improve"), scope-prefixed when one package owns it (core:, viewer:, editor:, nodes:, mcp:).
3. Push and open, or update
git push -u origin HEAD
gh pr view --json number,url,body 2>/dev/null # existing PR?
- None →
gh pr create --title … --body "$(cat <<'EOF' … EOF)". - Exists →
gh pr edit <n> --body …: rebuild "What" and "How to test" from the current branch, keep the media section and the reviewer's checklist ticks verbatim, keep any extra sections at the end. Change the title only if the scope changed.
End the body with the attribution lines the session asks for, if any.
4. Report
PR URL, title, which checks you ran, and anything left unchecked for the reviewer.
| 1 | |
| 2 | name open-pr |
| 3 | description Open or update a pull request on pascalorg/editor from the current branch, describing only what the branch actually did. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo. |
| 4 | metadata |
| 5 | internal true |
| 6 | allowed-tools Bash(git *) Bash(gh *) Read |
| 7 | |
| 8 | |
| 9 | Open (or refresh) a pull request against `pascalorg/editor` from the current branch. |
| 10 | |
| 11 | ## 1. What is actually on the branch |
| 12 | |
| 13 | |
| 14 | git branch --show-current # not main |
| 15 | git status --short # nothing uncommitted you weren't asked to commit |
| 16 | base=$(git merge-base HEAD origin/main) |
| 17 | git log --oneline --first-parent --no-merges "$base"..HEAD |
| 18 | git diff --stat "$base"..HEAD |
| 19 | |
| 20 | |
| 21 | The PR describes **only** these commits and this diff. Work that arrived by merging `main`, reverted commits, and patch-equivalent cherry-picks are not this PR's claims. If a file in the diff has no commit on the branch explaining it, stop and ask. |
| 22 | |
| 23 | Run `bun run check-types` when the change is non-trivial; never claim a check you did not run. |
| 24 | |
| 25 | ## 2. Body = the repo template |
| 26 | |
| 27 | `.github/pull_request_template.md` is the source of truth for headings and checklist. Fill it from §1, not from memory: |
| 28 | |
| 29 | **What does this PR do?** — the result, one paragraph or a short list; `Fixes #123` when applicable. |
| 30 | **How to test** — numbered, concrete reviewer steps with the expected outcome. Automated commands only if you ran them. |
| 31 | **Screenshots / screen recording** — link, `Not added yet.` for a visual change without media, or `N/A — non-visual change`. |
| 32 | **Checklist** — copy verbatim; tick only what was verified (`bun dev` only after a real local run). |
| 33 | |
| 34 | Title: under ~70 characters, a concrete result (not "update"/"improve"), scope-prefixed when one package owns it (`core:`, `viewer:`, `editor:`, `nodes:`, `mcp:`). |
| 35 | |
| 36 | ## 3. Push and open, or update |
| 37 | |
| 38 | |
| 39 | git push -u origin HEAD |
| 40 | gh pr view --json number,url,body 2>/dev/null # existing PR? |
| 41 | |
| 42 | |
| 43 | None → `gh pr create --title … --body "$(cat <<'EOF' … EOF)"`. |
| 44 | Exists → `gh pr edit <n> --body …`: rebuild "What" and "How to test" from the current branch, keep the media section and the reviewer's checklist ticks verbatim, keep any extra sections at the end. Change the title only if the scope changed. |
| 45 | |
| 46 | End the body with the attribution lines the session asks for, if any. |
| 47 | |
| 48 | ## 4. Report |
| 49 | |
| 50 | PR URL, title, which checks you ran, and anything left unchecked for the reviewer. |
| 51 |
Details
- License
- MIT
- Stars on the repo
- ★ 24,602
- Checked
- Source
- pascalorg/editor ↗
- Creator
- pascalorg · 3 listings
Similar skills
See all →
SkillCI/CD Pipeline Setup
addyosmani/agent-skills · by addyosmaniAutomates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.★ 98.7k GitHub stars
SkillSemantic Release Automation
thedotmack/claude-mem · by thedotmackAutomated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, plugin.json manifests, build verification, git tagging, GitHub releases, and changelog generation. NPM publishing is the final human-required handoff because the maintainer raised npm security.★ 95.6k GitHub stars
SkillOrca CLI
stablyai/orca · by stablyaiOperate Orca-managed worktrees, folder contexts, terminals, repos, automations, artifacts, skill sharing, worktree comments, and Orca's embedded browser through the `orca` CLI. Use when the user says "$orca-cli", "Orca worktree", "child worktree", "spawn codex/claude in a worktree", "read/wait/send Orca terminal", "handoff" / "handover" / "give this to another agent", "Orca browser", "orca artifacts", or "share skills". Prefer it over raw git worktree, ad hoc PTYs, or Computer Use when Orca state is involved. Use Computer Use only when a visible window needs GUI control that a CLI, filesystem, or API cannot do.★ 84.5k GitHub stars
SkillWorker Coordination Enginestablyai/orca · by stablyaiCoordinate supervised Orca workers: threaded messages, blocking ask/reply, task dispatch, worker_done/escalation waits, task DAGs, decision gates, coordinator loops, and decomposing work across agents. Use `orca-cli` for full ownership handoffs — "hand off", "handoff", "handover", "give this to another agent", "another worktree" — unless asked to supervise, monitor, or coordinate a DAG, and for terminal control, lightweight terminal prompts, shell commands, Orca worktree management, and reading or waiting on terminals.★ 84.5k GitHub stars
SkillVercel Deployment Tool
bytedance/deer-flow · by bytedanceDeploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as "Deploy my app", "Deploy this to production", "Create a preview deployment", "Deploy and give me the link", or "Push this live". No authentication required - returns preview URL and claimable deployment link.★ 83.5k GitHub stars
SkillBranch PR Creator
Gentleman-Programming/gentle-ai · by Gentleman-ProgrammingCreate Gentle AI pull requests with issue-first checks. Trigger: creating, opening, or preparing PRs for review.★ 7.5k GitHub starsMore from pascalorg
SkillPascal 3D Scene Builder
pascalorg/editor · by pascalorgConnect to Pascal and use its MCP tools to create, inspect, edit, validate, save, or hand off editable 3D building scenes. Use this skill whenever a user asks an agent to work in Pascal, make a room or building model, inspect a Pascal project, perform spatial edits, connect Pascal MCP, or return a verified Pascal editor link. It also governs safe local, existing-account, and explicitly authorized autonomous setup.★ 24.6k GitHub stars
SkillArchitecture Pattern Reviewerpascalorg/editor · by pascalorgReview a PR against the Pascal architectural rules — package boundaries (core/viewer/editor/nodes), the registry-driven composition model (def.geometry / def.renderer / def.system), legacy-dispatch regressions, the slots + world-scale-UV convention for new nodes/geometry, hook hygiene (useEditor/useScene/useViewer), and selector performance. Use when the user asks to review a PR, audit a branch, or check that changes respect the codebase's architecture.★ 24.6k GitHub stars