Create or update a GitHub pull request for the current branch from the repository's fixed PR template (.github/PULLREQUESTTEMPLATE.md) and the branch changes.

MITAuto-check passedDevelopment

Install Create PR

skills CLI
$ npx skills add javierbrea/eslint-plugin-boundaries --skill create-pr -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install javierbrea/eslint-plugin-boundaries create-pr --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/javierbrea/eslint-plugin-boundaries.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/create-pr .claude/skills/create-pr && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
create-pr
GitHub stars
997
Token cost
~2.3k tokens
SKILL.md length
1,241 words
Files
1
Skills in repo
5
Repo updated
First seen
Licence
MIT

At a glance

Create or update a GitHub pull request for the current branch from the repository's fixed PR template (.github/PULLREQUESTTEMPLATE.md) and the branch changes.

  • Works in 12 steps: Resolve inputs. Determine target_branch… → Read the PR template. It always lives at… → Infer the PR type from the branch name.… → …
  • Tasks that involve Pull requests
  • SKILL.md covers When to use this skill, Inputs, Procedure and Output format, plus 2 more sections
  • Calls git and gh

What it does

Create PR is an agent skill from javierbrea/eslint-plugin-boundaries. Create or update a GitHub pull request for the current branch from the repository's fixed PR template (.github/PULLREQUESTTEMPLATE.md) and the branch changes. Infers PR type from the branch name, discovers the related GitHub issue number from the branch name or from the commits on the branch, enriches the description from that issue when it can be read, asks clarifying questions, and always shows a preview for explicit confirmation before creating the PR in draft state.

Its SKILL.md is about 2.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Pull requests and Requirements gathering. It works with GitHub, ESLint and Git. The repository describes itself as: Enforce architectural boundaries in your JavaScript and TypeScript projects. The licence is MIT.

When your agent uses it

  • Tasks that involve Pull requests
  • Tasks that involve Requirements gathering

Example prompts

  • “/create-pr”

Workflow steps

12 steps, taken from the first numbered list in SKILL.md.

  1. Resolve inputs. Determine target_branch from the arguments, defaulting to release.
  2. Read the PR template. It always lives at .github/PULL_REQUEST_TEMPLATE.md in this repository — read it directly, no discovery needed. If…
  3. Infer the PR type from the branch name. Map the branch prefix to the PR
  4. Discover the related GitHub issue.
  5. Gather change context. Inspect the branch changes against target_branch (for example git diff ...HEAD and git log ..HEAD) to understand…
  6. Enrich the description (issue conditional).
  7. Build the title and description. is one of feat, fix, docs, chore, refactor`.
  8. Show a mandatory preview. Present the full title and description and ask for explicit confirmation before any create or update call. When…
  9. Determine labels from the actual changes. This repository uses these labels (match the strings exactly, including the space after the colon)
  10. Prefer GitHub MCP tools. Use GitHub MCP tools for all supported operations (for example create_pull_request, update_pull_request…
  11. Create or update the pull request. Check whether a pull request already exists for the current branch. If one exists, update it and leave…
  12. Label and assign. Apply the labels determined in step 9 (adding to, not replacing, any labels already present on an existing PR unless…

What it can do on your machine

Read from SKILL.md and the folder at commit 50f2d31. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Create PR loads about 2.3k tokens when it runs. Until then it costs about 122 tokens; SKILL.md has 1,241 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~122
When it runs · the whole SKILL.md, loaded when a task matches
~2.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from javierbrea/eslint-plugin-boundaries at commit 50f2d31, republished under its MIT licence (© javierbrea). 1,241 words, ~2,338 tokens.

Download SKILL.mdSave it as .claude/skills/create-pr/SKILL.md (or your agent's skills folder).
name
create-pr
description
Create or update a GitHub pull request for the current branch from the repository's fixed PR template (.github/PULL_REQUEST_TEMPLATE.md) and the branch changes. Infers PR type from the branch name, discovers the related GitHub issue number from the branch name or from the commits on the branch, enriches the description from that issue when it can be read, asks clarifying questions, and always shows a preview for explicit confirmation before creating the PR in draft state.
argument-hint
[target_branch=release]

Create Pull Request

When to use this skill

Use this skill when you need to open or update a GitHub pull request for the current branch, filling the repository's PR template from the actual branch changes and, when possible, from the linked GitHub issue.

Inputs

Provide (optional; a sensible default applies):

  • target_branch (default release): the base branch for the pull request.

Procedure

  1. Resolve inputs. Determine target_branch from the arguments, defaulting to release.

  2. Read the PR template. It always lives at .github/PULL_REQUEST_TEMPLATE.md in this repository — read it directly, no discovery needed. If it is somehow missing, build a sensible default description structure from the changes.

  3. Infer the PR type from the branch name. Map the branch prefix to the PR <type>:

    Branch prefixPR title <type>
    feat/feat
    fix/fix
    docs/docs
    chore/chore
    refactor/refactor

    If the PR type cannot be inferred with confidence, ask the user before proceeding.

  4. Discover the related GitHub issue.

    • Look for a number in the branch name (for example 466 in feat/466/category-type-accumulation).
    • If none, inspect the commits on this branch that are not on target_branch (git log <target_branch>..HEAD) for a (#<number>) token — this repository's commit convention is <type>(#<number>): <description> (for example feat(#466): ...).
    • If still none, ask the user whether the change relates to a GitHub issue. If the user confirms there is none, proceed in issue-less mode (see step 7).
  5. Gather change context. Inspect the branch changes against target_branch (for example git diff <target_branch>...HEAD and git log <target_branch>..HEAD) to understand what the pull request introduces, and to determine which parts of the codebase were touched (for the scope labels in step 9).

  6. Enrich the description (issue conditional).

    • If an issue number was found, fetch it — prefer a GitHub MCP tool (for example get_issue); otherwise gh issue view <number> --json title,body — and use its title/body together with the diff to write an accurate change description.
    • If no issue was found, or it cannot be read, derive the description from the branch changes only.
    • In both cases, ask the user any clarifying questions about the changes or intent before showing the preview.
  7. Build the title and description. <type> is one of feat, fix, docs, chore, refactor.

    • The title must follow the pattern <type>: Title (conventional-commit style, matching this repository's own commit messages).
    • Fill the template sections (Description, Agreement) from the issue and the diff. Leave the Agreement checkboxes unchecked for the user to confirm themselves.
    • When an issue number was found, add a closes #<number> line following the template's "Closing issues" convention. In issue-less mode, omit it.
  8. Show a mandatory preview. Present the full title and description and ask for explicit confirmation before any create or update call. When updating an existing pull request, make clear which content will be replaced, and preserve any manually added sections not covered by the template rather than overwriting them.

  9. Determine labels from the actual changes. This repository uses these labels (match the strings exactly, including the space after the colon):

    • Type: type: bug (branch prefix fix//bug/, or fix(...) commits) or type: feature (branch prefix feat/). For other prefixes, do not force type: bug/type: feature; ask the user if a type label should be applied (for example type: task).
    • Scope, one or more depending on which files changed in the diff:
      • scope: code — functional code under packages/*/src.
      • scope: tests — test files (test/, *.spec.*, *.test.*).
      • scope: documentation — docs/website content and *.md files.
      • Other existing labels (scope: dependencies, scope: CI-CD, scope: refactor) may also apply — use them when the diff matches.
  10. Prefer GitHub MCP tools. Use GitHub MCP tools for all supported operations (for example create_pull_request, update_pull_request, get_issue). Fall back to gh CLI or REST only for operations MCP does not support.

  11. Create or update the pull request. Check whether a pull request already exists for the current branch. If one exists, update it and leave its existing draft/ready state unchanged (never promote or demote it). Otherwise create a new pull request targeting target_branch, explicitly setting draft: true so it starts in draft state; do not switch a newly created pull request to ready for review.

  12. Label and assign. Apply the labels determined in step 9 (adding to, not replacing, any labels already present on an existing PR unless they conflict, e.g. a stale type label). On creation, assign the pull request to the authenticated user; on update, keep the existing assignee (do not reassign).

  13. Report. Respond to the user with the pull request URL.

Show full SKILL.md (496 more words)Show less
Authorization Failure Handling (Required)
  • Never enter retry loops with shell commands when authorization or authentication failures are detected.
  • Treat errors such as 401, 403, Bad credentials, Requires authentication, Resource not accessible by integration, permission denied, or not authorized as terminal for the current automation attempt.
  • On such failures, stop automation immediately and inform the user that authorization is required.
  • Always include the computed PR title and full PR description in the response so the user can copy and paste them manually.
  • Do not keep attempting alternative shell-based GitHub flows after an auth failure has been detected.

Output format

Return results with:

  • Summary: the pull request URL, whether it was created or updated, its draft state, the title, the applied labels, and the base branch.
  • Details: the final title and the template sections that were filled, plus how the description was sourced (GitHub issue plus diff, or diff only).
  • On authorization failure: the copyable PR title and full PR description, and a clear statement that authorization is required.

Include assumptions, risks, and follow-ups when relevant.

Examples

Example A (feature, issue from branch name)

Input

  • Goal: open a PR for branch feat/466/category-type-accumulation.
  • Context: default target_branch=release; GitHub MCP not available, gh CLI available.

Expected output

  • Issue #466 discovered from the branch name; description enriched from gh issue view 466 plus the diff; a preview confirmed by the user; a draft PR titled feat: Support disabling category accumulation at file descriptors targeting release, with closes #466, labeled type: feature and scope: code (plus scope: tests/scope: documentation if those files also changed), and its URL.
Example B (fix, issue discovered from commits)

Input

  • Goal: open a PR for a branch with no issue number in its name, whose commits on top of release include fix(#460): boundaries/dependencies no longer skips external/core dependencies ....
  • Context: default target_branch=release.

Expected output

  • No number found in the branch name, so the commit (#460) token is used instead; issue #460 fetched to enrich the description; draft PR titled fix: ... with closes #460, labeled type: bug and scope: code, plus its URL.
Example C (issue-less)

Input

  • Goal: open a PR for branch chore/update-dependencies.
  • Context: default target_branch=release; no issue number in the branch name or in the commits; the user confirms there is no related GitHub issue.

Expected output

  • Issue-less mode: description written from the diff only, no closes line, a preview confirmed by the user, and a draft PR titled chore: Update dependencies targeting release, labeled scope: dependencies, plus its URL.

Notes / Constraints

  • The pull request title and description MUST ALWAYS be written in English, regardless of the user's language. This is a mandatory requirement.
  • Do not use hard line breaks within paragraphs in the PR description. Each paragraph must be a single unbroken line; only blank lines separate paragraphs.
  • One pull request per branch: verify existing pull requests before creating a new one.
  • The pull request must remain in draft state after creation.
  • Always show a preview and obtain explicit confirmation before creating or updating the pull request.

© javierbrea, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/create-pr of javierbrea/eslint-plugin-boundaries.

Open the folder on GitHubat commit 50f2d31

Compare with similar skills

Create PR next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Create PR compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Create PR this skilljavierbrea/eslint-plugin-boundaries997—~2.3kAutomated safety check: PassMIT
Contributor-First PR MergeHKUDS/OpenHarness16k1 repos~847Automated safety check: PassMIT
Create Pull Requestcline/cline70k1 repos~1.6kAutomated safety check: PassApache-2.0
Pull Request Title and Body Writeropeninterpreter/openinterpreter69k2 repos~1.1kAutomated safety check: PassApache-2.0
PR Review State Fetchprisma/orm48k—~767Automated safety check: PassApache-2.0
Creating Description For Gh PRredis/jedis12k—~838Automated safety check: PassMIT

Similar skills

  • Merges external GitHub pull requests while keeping the original author credited, and fixes conflicts after the merge instead of rewriting the contribution.

    16k GitHub starsUsed in 1 repo~847 tokens
    DevelopmentAuto-check passed
  • Opens a GitHub pull request from your current branch with the gh CLI, after reviewing the commits and diff and gathering the details the PR needs.

    70k GitHub starsUsed in 1 repo~1.6k tokens
    DevelopmentAuto-check passed
  • Pull Request Title and Body Writer

    openinterpreter/openinterpreter

    Rewrites the title and body of one or more pull requests with gh, leading with why the change was made, then what changed, and describing only the net result.

    69k GitHub starsUsed in 2 repos~1.1k tokens
    DevelopmentAuto-check passed
  • Official

    Fetches a pull request's canonical review state as JSON, validates it, and renders markdown, a text summary and triage target files from it using bundled scripts.

    48k GitHub stars~767 tokensUpdated yesterday
    DevelopmentAuto-check passed
  • Official

    Generate a clear, concise GitHub PR title and description from the diff between two local git branches, and save it to prDescription.md in the repo root.

    12k GitHub stars~838 tokensUpdated today
    DevelopmentAuto-check passed
  • Opens a pull request for the current branch using the repo's template, a work item ID in the title and a description filled in from the actual diff.

    60k GitHub stars~824 tokensUpdated yesterday
    DevelopmentAuto-check passed

More from javierbrea/eslint-plugin-boundaries

  • Boundaries Architect

    javierbrea/eslint-plugin-boundaries

    Act as a software architect: analyze a repository's folder structure and cross-file import dependencies, detect its architectural pattern, design element/file boundaries with the user, and configure…

    997 GitHub stars~4.2k tokensUpdated 2 days ago
    Auto-check passed
  • Review PR

    javierbrea/eslint-plugin-boundaries

    Review a GitHub pull request from three perspectives — functional fit against its linked issue, code correctness/quality, and architectural boundaries — then post a single GitHub review: one general…

    997 GitHub stars~2.9k tokensUpdated 2 days ago
    Auto-check passed
  • Unit Testing

    javierbrea/eslint-plugin-boundaries

    Complete or maximize unit test coverage for a specific TypeScript file in this repo.

    997 GitHub stars~618 tokensUpdated 2 days ago
    Auto-check passed
  • Repo Architecture

    javierbrea/eslint-plugin-boundaries

    Cross-cutting architecture reference for the eslint-plugin-boundaries monorepo — the dependency graph between packages, the Nx target graph, and the release flow.

    997 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed

Works with

Categories

Questions about Create PR

What does Create PR do?

Create or update a GitHub pull request for the current branch from the repository's fixed PR template (.github/PULLREQUESTTEMPLATE.md) and the branch changes. Create PR is an agent skill from javierbrea/eslint-plugin-boundaries.md) and the branch changes.

When should I use Create PR?

Create PR fits situations like: tasks that involve Pull requests; tasks that involve Requirements gathering.

How do I install Create PR in Claude Code?

Run `npx skills add javierbrea/eslint-plugin-boundaries --skill create-pr -a claude-code`. Or copy the skill folder (.agents/skills/create-pr in javierbrea/eslint-plugin-boundaries) into .claude/skills/create-pr in your project. Claude Code loads it when a task matches its description.

How do I install Create PR in Codex?

Run `npx skills add javierbrea/eslint-plugin-boundaries --skill create-pr -a codex`. Or copy the skill folder (.agents/skills/create-pr in javierbrea/eslint-plugin-boundaries) into .agents/skills/create-pr in your project. Codex loads it when a task matches its description.

Can I use Create PR in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add javierbrea/eslint-plugin-boundaries --skill create-pr -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/create-pr, .gemini/skills/create-pr, .github/skills/create-pr and .opencode/skills/create-pr in your project.

What does Create PR need to run?

Going by SKILL.md and its folder, Create PR needs the command-line tools its instructions call (git and gh).

Does Create PR access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Create PR safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Create PR use?

Create PR is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Create PR use?

About 2.3k tokens (SKILL.md is roughly 9.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Create PR?

Skills that share tags, products or a category with Create PR: Contributor-First PR Merge (HKUDS/OpenHarness, 16k stars), Create Pull Request (cline/cline, 70k stars), Pull Request Title and Body Writer (openinterpreter/openinterpreter, 69k stars) and PR Review State Fetch (prisma/orm, 48k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Create PR?

javierbrea (a GitHub user) maintains it in javierbrea/eslint-plugin-boundaries, which has 997 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 5, 2026.

Source: javierbrea/eslint-plugin-boundaries on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.