Create A PR

Skill: Create an Octane PR

Use this when asked to prepare a branch and pull request for an Octane change.

Preflight

1. Ensure working tree state is understood:

   git status --short --branch
   git diff --stat

2. Read AGENTS.md and docs/packages.md.
3. For a new task, fetch the remote default branch and create a dedicated new worktree and non-default branch from it. For an existing pull request, use its already-dedicated worktree.
4. Verify the task worktree is not the primary checkout and its current branch is neither main nor master.
5. Confirm no unrelated local changes are included.

The primary checkout and local default branches are read-only. Never implement, install dependencies, generate artifacts, test with commands that write files, stage, or commit there. Preserve any state already present and move to the task worktree before doing work.

Branch and implementation hygiene

• Branch names: fix/<short-topic>, feat/<short-topic>, docs/<short-topic>, or test/<short-topic>.
• Keep commits focused.
• Add changesets for user-facing package changes; skip docs-only/test-only/internal tooling.
• If changing RuleSync source, edit .rulesync/rules/* or .rulesync/skills/* and run pnpm rules:generate.

Validation checklist

During iteration, format or check one or more changed files/directories without scanning the repository:

pnpm format:files <path...>
pnpm format:files:check <path...>

Then run the smallest meaningful final set and record results:

pnpm format:check
pnpm typecheck
pnpm test

Targeted alternatives are acceptable for small changes, but PR body must say what was and was not run.

Performance review gate

Load the perf-review skill and run it on the final diff before the first gh pr ready whenever the diff touches any of:

• packages/octane/src/: runtime, signals, hydration, server, or compiler;
• code that changes compiled output, such as vite-plugin-octane or rspack-plugin-octane transforms;
• a binding's hot path: code that runs per render, per event, per store or signal notification, or per layout measurement.

Put its report in the PR body under Validation. Resolve every must-fix finding. Each needs-evidence finding needs its evidence in the PR, or an entry under Risk / follow-ups that says why it is missing. For a diff outside these paths, write perf-review: not applicable.

Concision gate

Load the concise-code skill and run its simplification pass on the final diff before the first gh pr ready, for every PR with authored code. Put its report line in the PR body under Validation, including the smaller alternatives you rejected and why.

PR body template

## Summary
- ...

## Why
- ...

## Changes
- ...

## Validation
- [ ] `pnpm format:check`
- [ ] `pnpm typecheck`
- [ ] `pnpm test`
- [ ] targeted tests: ...
- [ ] `perf-review`: <findings and evidence, or not applicable>
- [ ] `concise-code`: <size, alternatives, bytes>

## Risk / follow-ups
- ...

Preserve managed sections when updating an existing PR

The template above is for creating a new pull request. Before editing an existing pull request body, fetch its current body with gh pr view and merge the desired changes into that body. Never replace it from a newly generated template.

Treat paired bot-managed HTML comment regions as opaque and preserve them byte-for-byte. In particular, Cursor Bugbot owns this region:

<!-- CURSOR_SUMMARY -->
...
<!-- /CURSOR_SUMMARY -->

Refetch the body immediately before writing because a bot can update it after a commit is pushed. After gh pr edit, fetch it again and verify that every managed region remains. If an edit races with a bot and removes one, recover the latest region from the pull request's edit history and restore it before ending the task. Adding or checking provenance is never a reason to discard an existing summary, description, comment region, or maintainer-authored text.

Create PR with GitHub CLI

Immediately before committing and pushing, synchronize the repository and review the resulting diff. Include every relevant generated change in the commit:

git branch --show-current
pnpm sync
git status --short
git add <files>
git commit -m "<type>: <summary>"
git push -u origin <branch>
gh pr create --draft --body-file <file>

Write the body to a temp file and pass it explicitly. Do not use --fill: it builds the body from your commits and drops the template, which would falsely classify an agent-produced diff as human-authored.

Apply no labels, and never pass --label. Your token has no rights to label at all when the PR comes from a fork, and .github/workflows/label-pr.yml applies both labels as a bot, which does.