Menu
Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | open-pr |
| description | Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR. |
Prepare the current worktree branch for a pull request: rebase, self-review, quality checks, and open a draft PR.
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.
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.
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.
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.
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.
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.
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.
Integrate and use @stll/folio-agents, the framework-neutral LLM tool layer over @stll/folio-core: function-calling tools that read and mutate a .docx document, with every mutation landing as a tracked change or comment pending human review. Load this skill when wiring folio's tools into an agent's tool-use loop (TanStack AI, Vercel AI SDK, raw Anthropic/OpenAI SDKs, or a custom loop), choosing between the headless reviewer bridge and the live-editor-ref bridge, or summarizing what changed between two document versions.
Create a new implementation plan in the repo's planning area.
Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity.
Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
Track down a behavior that used to work and now fails, changed, or regressed. Use this when a bug report points to a recent breakage, especially when the cause is not obvious yet.
Run a security-focused code audit with a generic checklist first, then layer on repo-specific risks.