Ring:opening Pull Requests

Open a GitHub Pull Request against the correct base branch, with a title that will pass scope validation and a body that fills the repo's PR template. Verifies the base after creation and corrects it automatically if GitHub defaulted to the wrong target.

⛔ HARD STOP — DO NOT CALL gh pr create BEFORE COMPLETING STEPS 1–6

Skipping detection steps is how PRs end up targeting main when the repo expects develop, or how PRs fail validation due to a missing or invalid scope. MUST complete every step in order.

Step 1 — Detect Base Branch

NEVER assume the base. Run all three probes first, then apply the precedence rules below.

Probes (run in parallel)

# Probe A — GitHub API default
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
# Fallback if gh unavailable: git remote show origin | grep 'HEAD branch' | awk '{print $NF}'

# Probe B — PR template hint
# Read .github/pull_request_template.md — note any explicit branch name mentioned

# Probe C — develop branch existence
git ls-remote --heads origin develop

Precedence (apply in order — first match wins)

State the resolved $BASE and which source determined it before proceeding.

Step 2 — Detect Scope Policy

MUST detect the allowlist before proposing the PR title. A title with a wrong or missing scope will fail PR validation and block the merge.

2.1 — Locate the policy file

Check in this order:

1. .github/workflows/pr-validation.yml (primary)
2. .github/workflows/pr-title.yml
3. .github/workflows/commitlint.yml
4. .github/workflows/semantic-pull-request.yml
5. Root configs: commitlint.config.{js,cjs,mjs,ts}, .commitlintrc*

2.2 — Extract allowed scopes and types

Also extract any type restrictions — some repos limit allowed types beyond the default Conventional Commits set.

2.3 — Apply the policy

NEVER omit the scope. NEVER invent a scope not in the allowlist.

State the policy source and chosen scope before proceeding.

Step 3 — Verify Preconditions

git status --porcelain                                  # check for uncommitted changes
git branch --show-current                               # confirm current branch name (empty in detached HEAD)
git fetch origin <current-branch> --quiet               # refresh remote ref before checking push state
git ls-remote --heads origin <current-branch>           # confirm branch exists on remote
git rev-list origin/<current-branch>..HEAD --count      # confirm no local commits ahead

Fail closed. Check in this order: uncommitted changes → detached HEAD → branch on remote → no local commits ahead. Only continue when all four checks pass. Do NOT interpolate an empty branch name into git ls-remote or git rev-list.

Step 4 — Read PR Template

cat .github/pull_request_template.md 2>/dev/null

If the template exists, use it as the body structure and fill in every section. If no template exists, use this default structure:

## Summary

<!-- What does this PR do and why? -->

## Type of Change

- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Breaking Changes

None.

## Testing

- [ ] Unit tests pass
- [ ] Manually tested

## Related Issues

<!-- Closes #issue -->

Step 5 — Gather Diff Context

git log origin/$BASE..HEAD --oneline
git diff origin/$BASE...HEAD --stat

Use this output to fill the PR body accurately.

Step 6 — Draft PR Title and Body

Title

<type>(<scope>): <description>

Requirements:

• Under 70 characters
• Lowercase, no period at the end
• Scope MUST come from the allowlist (Step 2)
• Type MUST be allowed per policy (Step 2)

Examples:

• feat(auth): add OAuth2 refresh token support
• fix(api): handle null response in user endpoint
• chore(deps): update authentication dependencies

Body

Fill the PR template completely:

Step 7 — Show Full Draft for Approval

Present the complete draft to the user:

PR Draft — waiting for your approval
─────────────────────────────────────
Base branch:  develop   (from: git ls-remote)
Scope policy: .github/workflows/pr-validation.yml → scopes: [api, auth, docs, ci]
Chosen scope: auth

Title:
  feat(auth): add OAuth2 refresh token support

Body:
  ## Summary
  Adds automatic token refresh when access token expires...
  ...

Command that will run:
  gh pr create --title "feat(auth): add OAuth2 refresh token support" \
               --body "..." \
               --base develop

Approve and create? [Yes / Edit title / Edit body / Cancel]

MUST wait for explicit user approval before executing gh pr create.

Step 8 — Create the PR

gh pr create \
  --title "<title>" \
  --body "<body>" \
  --base $BASE

Capture the PR number from the output.

Step 9 — Verify Base Branch

MUST verify the PR was opened against the expected base before reporting success. GitHub sometimes defaults to a different base.

gh pr view <number> --json baseRefName --jq '.baseRefName'

After retargeting, verify again:

gh pr view <number> --json baseRefName --jq '.baseRefName'

Only report success after the base is confirmed correct.

Step 10 — Return PR URL

gh pr view <number> --json url --jq '.url'

Return the PR URL to the user.

Anti-Patterns (FORBIDDEN)

• Do NOT call gh pr create before completing Steps 1–7 — bypassing detection causes PRs targeting the wrong base
• Do NOT hardcode --base develop or --base main — always pass --base $BASE resolved in Step 1
• Do NOT skip Step 9 (post-create verification) — GitHub may default to the wrong base
• Do NOT invent scopes — a scope not in the allowlist fails PR validation
• Do NOT omit the scope — every PR title MUST carry type(scope): description, never type: description

Anti-Rationalization Table