pr-open

PR Open Skill

End-to-end workflow for committing work and opening a merge-ready PR in bklit-ui.

Read this skill when the user wants to add, commit, validate, push, and open a PR — or references @pr-open.

---

Before you start

1. Confirm branch context

   • If the user merged an earlier PR on this branch and there are new changes, branch from latest main instead of stacking on a stale feature branch:

     git fetch origin main
     git checkout -b <new-branch-name> origin/main
     

   • Re-apply or cherry-pick only the intended changes; do not commit unrelated registry:build noise (e.g. reformatted packages/ui/registry/examples/* unless those edits are intentional).

2. Never commit secrets — skip .env, credentials, API keys, etc. Warn the user if they ask to commit them.

3. Git safety (required)

   • Do not update git config.
   • Do not run destructive commands (push --force, reset --hard) unless the user explicitly asks.
   • Do not skip hooks (--no-verify) unless the user explicitly asks.
   • Do not git commit --amend unless all amend rules in the user's git rules are satisfied (HEAD commit is yours, not pushed, or user requested amend).
   • If a commit fails due to a hook, fix the issue and create a new commit — do not amend a failed commit.
   • Use HEREDOC for commit messages (see below).
   • Do not push unless the user asked to push or open a PR.

---

Step 1 — Inspect changes

Run in parallel from the repo root:

git status
git diff
git diff --staged
git log -5 --oneline

If opening a PR, also check divergence from base:

git fetch origin main
git log origin/main..HEAD --oneline
git diff origin/main...HEAD --stat

Draft a commit message that explains why, not just what. Match recent repo style (e.g. feat(charts): …, fix(web): …).

---

Step 2 — Stage and commit (pre-commit loop)

Stage

git add <paths>   # prefer explicit paths over blind git add -A