
Open Pr
- 1 installs
- 21.1k repo stars
- Updated August 4, 2026
- pascalorg/editor
Helps with ai & agent building tasks.
About
open-pr is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.
- open-pr
- AI & Agent Building
- AI-coding skill
Open Pr by the numbers
- 1 all-time installs (skills.sh)
- Ranked #14,102 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/pascalorg/editor --skill open-prAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 21.1k |
| Last updated | August 4, 2026 |
| Repository | pascalorg/editor ↗ |
What it does
Helps with ai & agent building tasks.
Files
Open a pull request against pascalorg/editor from the current branch.
1. Pre-flight
git status # confirm working tree state
git branch --show-current # confirm we're on a feature branch, not main
git log --oneline main..HEADStop if:
- The current branch is
main. Ask the user to create a feature branch first. - The branch has no commits ahead of
main. Nothing to open a PR for. - There are uncommitted changes the user hasn't asked to commit.
Run a build sanity check if the change is non-trivial:
bun typecheck
bun buildDon't open the PR with a broken build.
2. Read the PR template
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.mdMirror the template exactly:
## What does this PR do?— one paragraph or a short bullet list. Link related issues withFixes #123when 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.
3. Push and open
git push -u origin HEADCheck for an existing PR first:
gh pr view --json url 2>/dev/nullIf none exists, create it. 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:).
If a PR already exists, print its URL and stop — don't recreate.
4. Report
Return:
- PR URL
- Title used
- Local typecheck/build status (if you ran them)
- A note for the reviewer if anything in the checklist is left unchecked