| name | port-pr |
| description | Port PRs from a GitHub repository. Use when you need to bring changes from a source repo. Invoke with /port-pr <github-pr-url> |
| argument-hint | <github-pr-url> |
| disable-model-invocation | true |
Port PR Skill
This skill enables porting PRs from a GitHub repository into this repository.
Required Inputs
This skill receives arguments via $ARGUMENTS:
$ARGUMENTS: GitHub PR URL (e.g., https://github.com/owner/repo/pull/123)
Workflow
1. Extract PR Information
gh pr view <url> --json mergeCommit,title,body,headRepository
git diff <mergeCommit>^..<mergeCommit> -- . ':!pnpm-lock.yaml' ':!package-lock.json' ':!yarn.lock'
Run these commands in the source repository using workdir parameter.
Important: Never read or port lockfile changes (pnpm-lock.yaml, package-lock.json, yarn.lock). Always regenerate the lockfile by running pnpm install after updating package.json dependencies.
2. Analyze Changes
- Identify all files changed, added, and deleted
- Understand the purpose and scope of the change
- Note any dependencies or related changes
3. Map to Target Repository
- Find equivalent files in this repository
- Identify any structural differences between repos
- Note files that don't exist or have different paths
4. Ask for Guidance
Before implementing, ask the user for clarification when:
- A file doesn't exist in the target repo
- The code structure differs significantly between repos
- The feature/change may not apply to this repository
- There's ambiguity about how to adapt the changes
5. Implement Changes
Apply similar changes following this repository's conventions:
- Follow AGENTS.md guidelines (formatting, imports, naming)
- Maintain consistent code style with surrounding code
- Use explicit file extensions (
.js) for local imports
- Use
node: prefix for Node.js built-ins
6. Verification
After implementation, run:
pnpm code:checks 2>&1 | tail -20
This runs formatting, linting, and TypeScript checks. Only the tail of the output is shown to see the result.
7. Run Unit Tests
After code checks pass, run only the unit tests from the tests-unit package:
pnpm --filter tests-unit test 2>&1 | tail -20
Important: Do NOT run pnpm test (which runs all tests), pnpm e2e:test, or any full test suite. Only unit tests from the tests-unit package should be run during the porting process.
8. Ask for Package
Before creating the changeset, determine which package the changes apply to:
Ask the user: "Which package should this changeset be for - @opennextjs/aws or @opennextjs/cloudflare?"
Store the answer in $PACKAGE_NAME (e.g., "@opennextjs/cloudflare").
9. Create Changeset
Create a patch changeset with the link to the PR:
PR_NUMBER=$(echo "$ARGUMENTS" | grep -oE '[0-9]+$')
echo "---
\"$PACKAGE_NAME\": patch
---
Ported PR #$PR_NUMBER from source repository
$ARGUMENTS" > .changeset/port-pr-$PR_NUMBER.md
10. Stage All Files
Stage all files that were modified or created during the port:
git status --short
git add .changeset/port-pr-$PR_NUMBER.md <other-modified-files>
11. Ask for Commit
Ask the user if they want to commit the changes directly:
Ask the user: "Should I stage all files and commit the ported PR changes now?"
Options:
- "Yes, commit now" - Stage all files and commit with the prepared message
- "No, I'll commit manually" - Let the user stage and commit themselves
If the user chooses to commit:
git add <all-modified-files>
git commit -m "chore: port PR #$PR_NUMBER from source repository
$ARGUMENTS
Changeset: .changeset/port-pr-$PR_NUMBER.md"
12. Summary
Provide a summary of:
- What was ported
- Any adaptations made
- Files modified/created
- Whether the changes were committed
- Any remaining TODOs or follow-up items
