Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
pascalorg avatar

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-pr

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars21.1k
Last updatedAugust 4, 2026
Repositorypascalorg/editor

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

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..HEAD

Stop 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 build

Don'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.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.

3. Push and open

git push -u origin HEAD

Check for an existing PR first:

gh pr view --json url 2>/dev/null

If 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

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.