mirror of https://github.com/hanzoai/next.js.git synced 2026-10-30 14:46:38 +00:00

Files

T

Benjamin WoodruffandGitHub 0cfc85ceae Clarify AI-assisted contribution policy in PR template and AGENTS.md (#95629 )

## Summary

Documents the policy around AI-assisted contributions, for both humans
and agents:

- `.github/pull_request_template.md`: notes that AI use is encouraged
for researching, creating, and reviewing changes, but contributors must
deeply understand their contributions, and PR descriptions from external
contributors must be written by a human.
- `.github/ISSUE_TEMPLATE/1.bug_report.yml`: adds the equivalent note
for bug reports — issue descriptions from external contributors must be
written by a human, though AI may help create reproductions.
- `AGENTS.md`: replaces the old "PR Descriptions" section with two new
sections. "GitHub Pull Requests" distinguishes branch PRs (agents may
write descriptions) from fork PRs targeting `vercel/next.js` (agents may
not). "GitHub Issues, Comments, and Discussions" restricts agent-written
issues, discussions, and comments to members of the
`vercel`/`vercel-labs` GitHub orgs, tells agents how to check membership
via the GitHub API, lists what agents can still help non-members with
(drafting details, reviewing, reproductions, translation, searching for
duplicates), and carves out exceptions (commenting on the user's own PR,
Vercel-operated bots, GitHub/Graphite review bots, and forks of the
repo).
- Renames the LLM watermark marker from `NEXT_JS_LLM_PR` to
`NEXT_JS_LLM` everywhere it appears (`AGENTS.md`,
`contributing/repository/pull-request-descriptions.md`, and the
`create-pr`/`backport-pr` skills), since it now also applies to issues,
discussions, and comments. Nothing in the repo consumes the old marker
name.
- `.agents/skills/create-pr/SKILL.md`: adds a "Fork PRs vs Branch PRs"
section referencing the `AGENTS.md` policy. Assorted typo fixes along
the way.

## Verification

- `gh api /user/memberships/orgs` and `gh api
orgs/vercel/members/<login>` (confirmed the documented membership checks
work and return the documented statuses)
- Not run: no test/build commands (docs-only change; prettier applied
via the pre-commit hook)

<!-- NEXT_JS_LLM -->

2026-07-10 11:27:52 -07:00

3.7 KiB

Raw Permalink Blame History

name, description, metadata

name

description

metadata

create-pr

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, codex/ branch names, and Codex app git directives.

internal
true

Create PR

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

Fork PRs vs Branch PRs

Before writing a PR description, check whether this is a branch PR (the branch lives in vercel/next.js) or a fork PR (an external contribution from a fork). You may write full descriptions for branch PRs, but not for fork PRs — inform the user, offer to review their description or provide technical details, and give them the GitHub URL to create the PR themselves. See "GitHub Pull Requests and Issues" in AGENTS.md for the full policy.

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

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

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

3.7 KiB Raw Permalink Blame History