## 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 -->
3.3 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| backport-pr | Backport a merged Next.js pull request from canary to a previous release branch such as next-16-2. Use when the user asks to backport, cherry-pick, or open a backport PR from a PR number to an older Next.js version. Covers finding the merged PR commit, creating a backport branch from the target release branch, cherry-picking from canary, validating, and opening the PR with the release branch as the base. |
|
Backport PR
Use this skill when a user asks to backport a merged Next.js PR to a release branch.
Inputs
- Require a PR number and a target release branch, for example
next-16-2. - If the target branch is not provided and cannot be inferred confidently from the user's request, ask before mutating git state.
- Treat the target branch as variable; do not hard-code
next-16-2except when the user explicitly asks for it.
Workflow
-
Inspect the current worktree before changing branches:
git status --short git branch --show-currentPreserve unrelated user changes. Do not overwrite, reset, or stash them without the user's consent.
-
Sync the source and target branches:
git fetch origin canary:refs/remotes/origin/canary <target-branch>:refs/remotes/origin/<target-branch> -
Identify the commit that landed the PR on
canary:gh pr view <pr-number> --repo vercel/next.js --json number,title,state,url,mergeCommit,baseRefName,headRefName git log origin/canary --oneline --fixed-strings --grep="(#<pr-number>)"Prefer
mergeCommit.oidwhen the PR isMERGEDand the commit is contained inorigin/canary. If GitHub does not return a usable merge commit, use thegit log --grepresult and verify the commit subject references the PR number. -
Create the backport branch from the release branch:
git switch -c backport-<pr-number>-to-<target-branch> origin/<target-branch>After switching branches in this repo, run
pnpm build-allbefore Next.js integration tests unless the user explicitly limits the task to preparing the cherry-pick or PR. -
Cherry-pick the landed commit with provenance:
git cherry-pick -x <merged-commit-sha>Resolve conflicts in favor of preserving the release branch's compatibility constraints. If the cherry-pick is empty, verify whether the change is already present on the release branch and report that instead of opening a duplicate PR.
-
Verify with the narrowest commands that cover the touched files. Prefer focused tests,
pnpm typesfor TypeScript-only risk, and the relevant integration test mode for behavior changes. -
Open the backport PR using
$create-pr.Override the normal
$create-prbase branch: use--base <target-branch>, notcanary. Keep the PR as a draft unless the user explicitly asks otherwise.
PR Shape
Use a title like:
[backport] <original PR title>
Use a concise PR body:
Backports <original PR title/link> to `<target-branch>`.
<!-- NEXT_JS_LLM -->
Related Skills
$create-pr- Create the branch commit, push it, and open the draft PR.$pr-status-triage- Check CI failures or review feedback after the PR exists.