Spec Commit Push PR

Git Commit, Push, and PR

Go from working changes to an open pull request, rewrite an existing PR description, or generate a description without touching git state.

Invocation And Authorization Boundary

This is an internal-only helper. A public workflow may delegate the full commit/push/PR path only after the current user or a visible upstream handoff has established both commit_authorization: authorized and landing_authorization: authorized. workflow invocation does not authorize commit, push, or PR creation; mode:pipeline, tool permission, a feature branch, a green test suite, or an existing PR are execution facts, not authority. Missing commit authority stops before staging/commit with commit_authorization_missing; missing landing authority stops before push or PR mutation with landing_authorization_missing.

Description-only generation remains non-mutating, but applying a description with gh pr edit is a landing mutation and still requires explicit landing authority. This helper never broadens the caller's run-owned file scope or absorbs unrelated dirty paths.

Asking the user: When this skill says "ask the user", use the platform's blocking question tool: AskUserQuestion in Claude Code (call ToolSearch with select:AskUserQuestion first if its schema isn't loaded) or request_user_input in Codex. Fall back to presenting the question in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.

Mode detection

Three flavors of intent. Pick one and follow the matching path; otherwise default to the full workflow.

• Description-only generation. If the user asked for just a PR description with no commit or push intent (e.g., "write a PR description", "draft a PR description for this branch", "describe this PR", or pasted a PR URL/number alone), skip Steps 4-5 AND Step 1's decision tree (its stop gates are full-workflow only and would terminate common cases like "feature branch, all pushed, open PR -> stop"). Use the data from the Context section above instead. Then go to Step 6 to compose. If the user pasted a PR URL/number, pass it to Step 6 as the PR ref so Pre-A resolves the right commit range (otherwise Pre-A defaults to current-branch mode). Print the result back to the user; apply via gh pr edit/gh pr create only if the user asks.
• Description update on existing PR. If the user is asking to update, refresh, or rewrite an existing PR description (with no mention of committing or pushing), follow the Description Update workflow below. The user may also provide a focus (e.g., "update the PR description and add the benchmarking results"). Note any focus for DU-3.
• Full workflow. Otherwise, follow the Full workflow below.

mode:pipeline modifier: Set by orchestrated callers such as spec-lfg. Run the resolved mode non-interactively and suppress every blocking ask. The existing-PR rewrite question defaults to not rewriting; in description-update mode the preview ask is skipped and the rewrite applies directly because the update invocation is already the apply intent. Any other suppressed ask takes its conservative documented default: keep the current branch when possible, and stop/report instead of guessing when a base, PR, or branch state cannot be resolved. After an authorized full-workflow landing, return a structured watch_handoff containing the PR number/URL, head SHA, base ref/SHA when available, and the caller's existing authorization source and scope. This handoff lets the pipeline owner enter its bounded review/CI/head/base-currency watch; it grants no new authority. Ordinary standalone and description-only runs do not start or recommend a watch by default.

The landing disclosure for mode:pipeline includes bounded PR-feedback fixes and only a repo-policy-approved, non-rewriting branch-currency update. This helper never authorizes or performs merge, rebase, force-push, or history rewrite as part of that handoff. If the repository policy is absent or currency requires rewriting history, return branch-currency-update-required to the caller.

Context

On platforms other than Claude Code, skip to the "Context fallback" section below and run the command there to gather context.

In Claude Code, the six labeled sections below contain pre-populated data. Use them directly -- do not re-run these commands.

Git status: !git status

Working tree diff: !git diff HEAD

Current branch: !git branch --show-current

Recent commits: !git log --oneline -10

Remote default branch: !git rev-parse --abbrev-ref origin/HEAD

Existing PR check: !gh pr view --json url,title,state

Context fallback

In Claude Code, skip this section — the data above is already available.

Run these commands separately to gather context without interleaving unrelated output:

git status
git diff HEAD
git branch --show-current
git log --oneline -10
git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'
gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'

Description Update workflow

DU-1: Confirm intent

Ask the user: "Update the PR description for this branch?" If declined, stop.

DU-2: Find the PR

Use the current branch and existing PR check from context. If the current branch is empty (detached HEAD), report no branch and stop. If the PR check returned state: OPEN, note the PR url and proceed to DU-3. Otherwise, report no open PR and stop.

DU-3: Write and apply the updated description

Read references/pr-description-writing.md once now — the core principle at the top governs every step. DU-3 walks through Pre-A then Steps A through H without re-reading. Run Pre-A in PR mode using the existing PR's URL from DU-2 (it resolves the commit range, diff, and current body). Then continue with Steps A through H from the already-loaded reference to compose the title and body. If the user provided focus (e.g., "include the benchmarking results"), apply it as steering — do not let it override the writing principles or fabricate content the diff does not support.

Evidence decision: the writing reference preserves any existing ## Demo or ## Screenshots block from the current body by default. If the user's focus asks to refresh or remove evidence, honor that. If no evidence block exists and one would benefit the reader, ask for an existing URL/path or state that evidence capture is not available in this workflow.

Compare and confirm. Briefly explain what the new description covers differently from the old one. Ask the user to confirm before applying. If the user provided focus, confirm it was addressed.

If confirmed, apply with gh pr edit. Substitute <TITLE> verbatim; if it contains ", `, $, or \, escape them or switch to single quotes.

The body must be written to a temp file and passed via --body-file <path>. Never use --body-file -, stdin pipes, heredoc-to-stdin, or --body "$(cat ...)" — wrappers and stdin handling can silently produce an empty PR body while gh still exits 0 and returns a URL.

BODY_FILE=$(mktemp "${TMPDIR:-/tmp}/spec-pr-body.XXXXXX")

Use the platform's file-write tool to write the composed body markdown to $BODY_FILE verbatim. Do not embed the body in a shell heredoc, stdin pipe, command substitution, or inline shell string.

gh pr edit --title "<TITLE>" --body-file "$BODY_FILE"

Report the PR URL.

Full workflow

Step 1: Gather context

Use the context above. All data needed for this step and Step 3 is already available -- do not re-run those commands.

The remote default branch value returns something like origin/main. Strip the origin/ prefix. If it returned DEFAULT_BRANCH_UNRESOLVED, an error, or a bare HEAD, try:

gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'

If both fail, fall back to main.

If the current branch is empty (detached HEAD), explain that a branch is required. Ask whether to create a feature branch now.

• If yes, derive a branch name from the change content, validate it with git check-ref-format --branch "$BRANCH_NAME", create with git checkout -b "$BRANCH_NAME", and use that for the rest of the workflow.
• If no, stop.

If the working tree is clean (no staged, modified, or untracked files), determine the next action:

1. Run git rev-parse --abbrev-ref --symbolic-full-name @{u} to check upstream.
2. If upstream exists, run git log <upstream>..HEAD --oneline for unpushed commits.

Decision tree:

• On default branch, unpushed commits or no upstream -- pushing default directly is not supported. Ask whether to create a feature branch. If yes, read references/branch-creation.md, follow its decision flow, then continue from Step 5. If no, stop.
• On default branch, all pushed, no open PR -- report no feature branch work. Stop.
• Feature branch, no upstream -- skip Step 4, continue from Step 5.
• Feature branch, unpushed commits -- skip Step 4, continue from Step 5.
• Feature branch, all pushed, no open PR -- skip Steps 4-5, continue from Step 6.
• Feature branch, all pushed, open PR -- report up to date. Stop.

Step 2: Determine conventions

Priority order for commit messages and PR titles:

1. Repo conventions in context -- follow project instructions if they specify conventions. Do not re-read; they load at session start.
2. Recent commit history -- match the pattern in the last 10 commits.
3. Default -- type(scope): description (conventional commits).

When using conventional commits, choose the type that most precisely describes the change. Where fix: and feat: both seem to fit, default to fix:: a change that remedies broken or missing behavior is fix: even when implemented by adding code. Reserve feat: for capabilities the user could not previously accomplish. Other types (chore:, refactor:, docs:, perf:, test:, ci:, build:, style:) remain primary when they fit better. The user may override for a specific change.

Step 3: Check for existing PR

Use the current branch and existing PR check from context. If the branch is empty, report detached HEAD and stop.

If the PR check returned state: OPEN, note the URL -- this is the existing-PR flow. Continue to Step 4 and 5 (commit any pending work and push), then go to Step 7 to ask whether to rewrite the description. Only run Step 6 if the user confirms the rewrite. Otherwise (no open PR), continue through Steps 6, 7, and 8 in order.

Step 4: Branch, stage, and commit

1. If on the default branch, branch creation must handle stale local base state, unpushed commits on local <base>, and uncommitted checkout collisions. Read references/branch-creation.md and follow its decision flow, then continue to step 2 below.
2. Scan changed files for naturally distinct concerns. If files clearly group into separate logical changes, create separate commits (2-3 max). Group at the file level only (no git add -p). When ambiguous, one commit is fine.
3. Stage and commit each group. Avoid git add -A or git add .. Follow conventions from Step 2 and use -F for the message body:

   COMMIT_MSG=$(mktemp "${TMPDIR:-/tmp}/spec-commit-message.XXXXXX")
   cat > "$COMMIT_MSG" <<'EOF'
   commit message here
   EOF
   git add file1 file2 file3
   git commit -F "$COMMIT_MSG"

Step 5: Push

git push -u origin HEAD