open-pr

name	open-pr
description	Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR.

Open PR

Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR.

Instructions

1. Verify you are on an isolated feature branch:

   CURRENT=$(git branch --show-current)
   if [ -z "$CURRENT" ] || [ "$CURRENT" = "main" ] || [ "$CURRENT" = "master" ]; then
     echo "Error: /open-pr must run from an active feature branch."
     exit 1
   fi
   

   If on a default branch or detached HEAD, abort and ask the user which feature branch to use.

   Check whether the current checkout is safe to use for PR prep:

   git status --short
   

   If the checkout is the user's shared root checkout, has unrelated local changes, or the work spans multiple repos or submodules, stop and move to clean worktree(s) before rebasing or committing. Create the worktree from the current feature branch and continue the rest of this skill there; do not rewrite history in the dirty root checkout.

2. Bootstrap the worktree before trusting failures:

   Before running lint, typecheck, tests, or hooks, verify that the worktree actually has the repo toolchain available (bun, workspace dependencies, turbo, oxlint, project bins, and env links if the repo expects them).

   If the worktree is missing the toolchain, run the repo's normal install/setup flow first, then rerun the same command. Do not treat missing-bin or module-resolution failures as product-code regressions. Keep setup-only churn such as accidental lockfile changes out of the PR unless the task explicitly requires them.

3. Rebase onto the remote default branch:

   DEFAULT_BRANCH="$(git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null | sed 's@^origin/@@')"
   if [ -z "$DEFAULT_BRANCH" ]; then
     DEFAULT_BRANCH="$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name' 2>/dev/null)"
   fi
   if [ -z "$DEFAULT_BRANCH" ]; then
     DEFAULT_BRANCH="main"
   fi
   
   git fetch origin "$DEFAULT_BRANCH"
   git rebase "origin/$DEFAULT_BRANCH"
   

   If conflicts arise, resolve them. After resolving, continue the rebase. If a conflict is ambiguous, ask the user.

4. Self-review against CLAUDE.md conventions:

   Get the full diff against the default branch:

   git diff "origin/$DEFAULT_BRANCH" --name-only
   

   Read every changed file in full. Review against the conventions in CLAUDE.md (TypeScript strictness, error handling, security, naming, i18n, patterns). Fix any violations directly; don't just list them. Commit fixes separately with fix: address self-review findings.

5. Run quality checks using the repo's actual commands:

   Run the checks the repository already defines for linting, typechecking, tests, and non-mutating format verification. If the repo defines format:check, use it. If it only defines a mutating format script, do not run it as verification unless you also commit the formatter output. Prefer documenting a missing format check in the PR body over inventing a one-off command that is inconsistent with the repo.

   If any check fails, fix the issue and re-run. Commit fixes with fix: lint/format/type errors.

6. Security audit:

   Run /security-audit. Fix any critical or high findings in files changed in this PR before opening it. Commit fixes with fix: address security audit findings.

7. Open the PR as draft:

   Push the branch and create the PR as a draft:

   git push --force-with-lease -u origin HEAD
   gh pr create --fill --draft
   

   If --fill produces a poor title/body, write a proper one following Conventional Commits (feat:, fix:, etc.) with a very concise summary. Do not add a separate test plan unless the user explicitly asks for one. Do not mention deployment choices or attribute the motivation for the PR to a specific person's feedback, request, or experience.

   This repository is public. Never include marketing language, internal business context, pricing, competitive analysis, user identities, conversation specifics, deployment specifics, or security architecture beyond what the diff obviously shows. Do not add details that would help a motivated attacker exploit the code, especially a vulnerable previous version being fixed. Assume the PR may be read by hostile adversaries, not only friendly collaborators. When sensitive context would improve readability, omit it by default; ask the user only if omission would make the PR hard to review.