# Open Pr

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

- Skill: `stella/open-pr` (Agent Skill)
- Install (CLI): `npx skillmds@latest add stella/open-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/stella/open-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: stella (https://skillmd.com/u/stella)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/stella/open-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**:

   ```bash
   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:

   ```bash
   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**:

   ```bash
   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:

   ```bash
   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**:

   ```bash
   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.