Run any Skill in Manus with one click

create-pr

Stars140,200

Forks31,287

UpdatedJune 17, 2026 at 18:52

Create Git branches, commits, pushes, and GitHub pull requests for Next.js. Use when the user asks to create a branch, commit current changes, open a PR or draft PR, publish a pull request, or recover from gh pr create / PR template issues. Covers .github/pull_request_template.md, --body formatting, NEXT_JS_LLM_PR, codex/ branch names, and Codex app git directives.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

vercel

vercel/next.js

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	create-pr
description	Create Git branches, commits, pushes, and GitHub pull requests for Next.js. Use when the user asks to create a branch, commit current changes, open a PR or draft PR, publish a pull request, or recover from gh pr create / PR template issues. Covers .github/pull_request_template.md, --body formatting, NEXT_JS_LLM_PR, codex/ branch names, and Codex app git directives.
metadata	{"internal":true}

Create PR

Use this skill when turning local work into a GitHub pull request.

Workflow

Inspect the current state before mutating Git:
```
git status --short
git branch --show-current
git diff -- <paths>
```
Stage only files that belong to the requested change. Preserve unrelated user changes.
Create or confirm the branch:
```
git switch -c codex/<short-topic>
```
Use the codex/ prefix unless the user asks for a different name. If a .git/*lock or Operation not permitted error appears, rerun the same Git command with sandbox escalation. Do not assume a branch namespace conflict until checking refs with git branch --list, git show-ref, or git for-each-ref.
Validate and commit:
```
git add <paths>
git diff --cached --check
git commit -m "<concise message>"
```
Keep commit messages concise and do not add generated-tool or co-author footers.
Push the branch:
```
git push -u origin <branch>
```
Create the PR as a draft unless the user explicitly asks otherwise:
```
gh pr create --draft --base canary --head <branch> --title "<title>" --body '<body>'
```
For this repo, prefer canary as the base branch. If GitHub network access fails in the sandbox, rerun with escalation.

PR Body

Use this PR body format:

## Summary

<what changed and why>

## Verification

- `<command that passed>`
- Not run: `<command>` (`<reason>`)

<!-- NEXT_JS_LLM_PR -->

The "what" should be explained from the end-user perspective or developer perspective. Only include implementation changes if they're not obvious from the diff.

A "why" should be included if the change isn't self-explanatory, or if the motivation is not clear from the diff. Omitting the "why" should be used sparringly and only for small changes.

Do not include trivial verification commands that CI already covers (e.g. pnpm run build), but do include any manual verification steps. If the PR changes a test, you don't need to repeat the command to run that test. But if you used an existing test to validate some behavior didn't change, include that test.

Use --body with this filled content.

Recovery

If a PR may already exist, check before creating a duplicate:
```
gh pr view --head <branch> --json url,isDraft,title
```
If approval is denied for gh pr create, report that the branch is pushed but the PR was not created, and provide the exact corrected command.
After successful Codex app Git actions, include the appropriate final-response directives for branch creation, staging, committing, pushing, and PR creation.

Related Skills

$pr-status-triage - Analyze CI failures and PR review feedback after the PR exists.
$gh-stack - Manage stacked branches and dependent pull requests.

More from this repository

same repository

next-cache-components-adoption

vercel/next.js

Turn on Cache Components in a Next.js app and resolve the blocking routes it surfaces. Use when the user wants to enable, adopt, or migrate to Cache Components, flip the `cacheComponents` flag, work through a flood of blocking-prerender / instant validation errors, run the `cache-components-instant-false` codemod, or decide between opting routes out with `export const instant = false` and fixing them in place.

2026-06-29140.2k

next-dev-loop

vercel/next.js

Verify Next.js runtime behavior after editing app code. Use this skill to confirm a change actually works in a running app — not just that it compiles or type-checks. Combines /_next/mcp (Next.js's view) with agent-browser (the browser's view). Requires a running `next dev`.

2026-06-26140.2k

insight-error-page

vercel/next.js

Write or audit an insight-kind error page for the Next.js dev overlay. Use when creating a new `errors/<slug>.mdx` page, auditing an existing one, or checking that a page matches the framework fix cards. Covers page structure, title alignment, FixOption cards with Copy AI prompt button, code snippets, terminology verification against canonical docs, and Vercel technical writing style.

2026-06-24140.2k

next-rspack

vercel/next.js

Maintain @next/rspack-core and @next/rspack-binding packages. Use when editing rspack/package.json, rspack/crates/binding/Cargo.toml, rspack/rust-toolchain.toml, or packages/next-rspack/package.json. Covers upgrading @rspack/core npm version, rspack_* crate versions, Rust toolchain version, building and linking for local testing, and NEXT_RSPACK environment variable usage. Does NOT apply to root rust-toolchain.toml (that's for Turbopack).

2026-06-22140.2k

next-cache-components-optimizer

vercel/next.js

Optimize a Next.js app that has `cacheComponents: true` — either the static shell on first paint, or the in-app navigation between routes. Picks the matching diagnostic loop and runs it.

2026-06-09140.2k

router-act

vercel/next.js

How to write end-to-end tests using createRouterAct and LinkAccordion. Use when writing or modifying tests that need to control the timing of internal Next.js requests (like prefetches) or assert on their responses. Covers the act API, fixture patterns, prefetch control via LinkAccordion, fake clocks, and avoiding flaky testing patterns.

2026-06-09140.2k

name	create-pr
description	Create Git branches, commits, pushes, and GitHub pull requests for Next.js. Use when the user asks to create a branch, commit current changes, open a PR or draft PR, publish a pull request, or recover from gh pr create / PR template issues. Covers .github/pull_request_template.md, --body formatting, NEXT_JS_LLM_PR, codex/ branch names, and Codex app git directives.
metadata	{"internal":true}

Create PR

Use this skill when turning local work into a GitHub pull request.

Workflow

Inspect the current state before mutating Git:
```
git status --short
git branch --show-current
git diff -- <paths>
```
Stage only files that belong to the requested change. Preserve unrelated user changes.
Create or confirm the branch:
```
git switch -c codex/<short-topic>
```
Use the codex/ prefix unless the user asks for a different name. If a .git/*lock or Operation not permitted error appears, rerun the same Git command with sandbox escalation. Do not assume a branch namespace conflict until checking refs with git branch --list, git show-ref, or git for-each-ref.
Validate and commit:
```
git add <paths>
git diff --cached --check
git commit -m "<concise message>"
```
Keep commit messages concise and do not add generated-tool or co-author footers.
Push the branch:
```
git push -u origin <branch>
```
Create the PR as a draft unless the user explicitly asks otherwise:
```
gh pr create --draft --base canary --head <branch> --title "<title>" --body '<body>'
```
For this repo, prefer canary as the base branch. If GitHub network access fails in the sandbox, rerun with escalation.

PR Body

Use this PR body format:

## Summary

<what changed and why>

## Verification

- `<command that passed>`
- Not run: `<command>` (`<reason>`)

<!-- NEXT_JS_LLM_PR -->

The "what" should be explained from the end-user perspective or developer perspective. Only include implementation changes if they're not obvious from the diff.

A "why" should be included if the change isn't self-explanatory, or if the motivation is not clear from the diff. Omitting the "why" should be used sparringly and only for small changes.

Use --body with this filled content.

Recovery

If a PR may already exist, check before creating a duplicate:
```
gh pr view --head <branch> --json url,isDraft,title
```
If approval is denied for gh pr create, report that the branch is pushed but the PR was not created, and provide the exact corrected command.
After successful Codex app Git actions, include the appropriate final-response directives for branch creation, staging, committing, pushing, and PR creation.

Related Skills

$pr-status-triage - Analyze CI failures and PR review feedback after the PR exists.
$gh-stack - Manage stacked branches and dependent pull requests.