open-pr

Open Pull Request

Finish the requested work as a narrow pull request and shepherd its pre-merge checks. Treat opening a PR as authorization to commit and push only the changes in scope; do not treat it as authorization to merge.

Ground Rules

• Preserve user work. Never stage, rewrite, revert, or clean up unrelated changes.
• Use non-interactive git and gh commands.
• Never commit secrets, local environment files, build output, or unrelated generated files.
• Never push directly to main.
• Never merge, enable auto-merge, or press a merge button unless the user explicitly asks to merge that specific PR.
• Keep the PR narrow. Stop and ask for direction if the safe scope is materially ambiguous.
• Do not rewrite published history or force-push unless the user explicitly requests it and the consequences are clear.

1. Establish Scope and State

Read repository instructions and inspect the worktree before changing Git state:

git status --short --branch
git diff --stat
git diff
git diff --cached
git remote -v
git symbolic-ref refs/remotes/origin/HEAD

Infer the intended file set from the current task and conversation. Treat all other modifications and untracked files as user-owned. If an intended file overlaps unrelated edits, preserve both when safe; otherwise stop and explain the conflict.

Confirm GitHub CLI access and repository metadata when needed:

gh auth status
gh repo view --json nameWithOwner,defaultBranchRef

Before creating a PR, check whether the current branch already has one. Update and shepherd the existing PR instead of opening a duplicate.

gh pr list --head "$(git branch --show-current)" --state open --json number,title,url,baseRefName,headRefName

2. Validate the Change

Run the smallest useful local checks for the touched area, then run broader CI-equivalent checks when the change affects shared code, dependencies, builds, infrastructure, or deployment.

Core repository checks are:

bun run typecheck
bun test
bun --cwd apps/server build
bun --cwd apps/web build