From galeharness-cli
Commit, push, and open a PR with an adaptive, value-first description. Use when the user says "commit and PR", "push and open a PR", "ship this", "create a PR", "open a pull request", "commit push PR", or wants to go from working changes to an open pull request in one step. Also use when the user says "update the PR description", "refresh the PR description", "freshen the PR", or wants to rewrite an existing PR description. Produces PR descriptions that scale in depth with the complexity of the change, avoiding cookie-cutter templates.
npx claudepluginhub wangrenzhu-ola/galeharnesscodingcli --plugin galeharness-cliThis skill uses the workspace's default tool permissions.
Go from working changes to an open pull request, or rewrite an existing PR description.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Go from working changes to an open pull request, or rewrite an existing PR description.
Asking the user: When this skill says "ask the user", use the platform's blocking question tool (AskUserQuestion in Claude Code, request_user_input in Codex, ask_user in Gemini, ask_user in Pi (requires the pi-ask-user extension)). If unavailable, present the question and wait for a reply.
If the user is asking to update, refresh, or rewrite an existing PR description (with no mention of committing or pushing), this is a description-only update. The user may also provide a focus (e.g., "update the PR description and add the benchmarking results"). Note any focus for DU-3.
For description-only updates, follow the Description Update workflow below. Otherwise, follow the full workflow.
If you are not Claude Code, skip to the "Context fallback" section below and run the command there to gather context.
If you are 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 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'
Existing PR check:
!gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'
If you are Claude Code, skip this section — the data above is already available.
Run this single command to gather all context:
printf '=== STATUS ===\n'; git status; printf '\n=== DIFF ===\n'; git diff HEAD; printf '\n=== BRANCH ===\n'; git branch --show-current; printf '\n=== LOG ===\n'; git log --oneline -10; printf '\n=== DEFAULT_BRANCH ===\n'; git rev-parse --abbrev-ref origin/HEAD 2>/dev/null || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\n=== PR_CHECK ===\n'; gh pr view --json url,title,state 2>/dev/null || echo 'NO_OPEN_PR'
Ask the user: "Update the PR description for this branch?" If declined, stop.
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 from the context block — this is the unambiguous reference to pass downstream — and proceed to DU-3. Otherwise, report no open PR and stop.
Read the current PR description to drive the compare-and-confirm step later:
gh pr view --json body --jq '.body'
Generate the updated title and body — load the gh-pr-description skill with the PR URL from DU-2 (e.g., https://github.com/owner/repo/pull/123). The URL preserves repo/PR identity even when invoked from a worktree or subdirectory where the current repo is ambiguous. If the user provided a focus (e.g., "include the benchmarking results"), append it as free-text steering after the URL. The skill returns a {title, body_file} block (body in an OS temp file) without applying or prompting.
If gh-pr-description returns a "not open" or other graceful-exit message instead of a {title, body_file} pair, report that message and stop.
Evidence decision: gh-pr-description preserves any existing ## Demo or ## Screenshots block from the current body by default. If the user's focus asks to refresh or remove evidence, pass that intent as steering text — the skill will honor it. If no evidence block exists and one would benefit the reader, invoke gh-demo-reel separately to capture, then re-invoke gh-pr-description with updated steering that references the captured evidence.
Compare and confirm — briefly explain what the new description covers differently from the old one. This helps the user decide whether to apply; the description itself does not narrate these differences. Summarize from the body already in context (from the bash call that wrote body_file); do not cat the temp file, which would re-emit the body.
If confirmed, apply with the returned title and body file:
gh pr edit --title "<returned title>" --body "$(cat "<returned body_file>")"
Report the PR URL.
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 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.
git checkout -b <branch-name>, and use that for the rest of the workflow.If the working tree is clean (no staged, modified, or untracked files), determine the next action:
git rev-parse --abbrev-ref --symbolic-full-name @{u} to check upstream.git log <upstream>..HEAD --oneline for unpushed commits.Decision tree:
Priority order for commit messages and PR titles:
type(scope): description (conventional commits).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 (which generates a new description via gh-pr-description) if the user confirms the rewrite; Step 7's existing-PR sub-path consumes the {title, body_file} that Step 6 produces. Otherwise (no open PR), continue through Steps 6, 7, and 8 in order.
git checkout -b <branch-name>.git add -p). When ambiguous, one commit is fine.git add -A or git add .. Follow conventions from Step 2:
git add file1 file2 file3 && git commit -m "$(cat <<'EOF'
commit message here
EOF
)"
git push -u origin HEAD
The working-tree diff from Step 1 only shows uncommitted changes at invocation time. The PR description must cover all commits in the PR.
Detect the base branch and remote. Resolve both the base branch and the remote (fork-based PRs may use a remote other than origin). Stop at the first that succeeds:
gh pr view --json baseRefName,url
Extract baseRefName. Match owner/repo from the PR URL against git remote -v fetch URLs to find the base remote. Fall back to origin.origin/ prefix. Use origin.gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
Use origin.main, master, develop, trunk in order:
git rev-parse --verify origin/<candidate>
Use origin.If none resolve, ask the user to specify the target branch.
Gather the full branch diff (before evidence decision). The working-tree diff from Step 1 only reflects uncommitted changes at invocation time — on the common "feature branch, all pushed, open PR" path, Step 1 skips the commit/push steps and the working-tree diff is empty. The evidence decision below needs the real branch diff to judge whether behavior is observable, so compute it explicitly against the base resolved above. Only fetch when the local ref isn't available — if <base-remote>/<base-branch> already resolves locally, run the diff from local state so offline / restricted-network / expired-auth environments don't hard-fail:
git rev-parse --verify <base-remote>/<base-branch> >/dev/null 2>&1 \
|| git fetch --no-tags <base-remote> <base-branch>
git diff <base-remote>/<base-branch>...HEAD
Use this branch diff (not the working-tree diff) for the evidence decision. If the branch diff is empty (e.g., HEAD is already merged into the base or the branch has no unique commits), skip the evidence prompt and continue to delegation.
Evidence decision (before delegation). Before running the full decision, two short-circuits:
User explicitly asked for evidence. If the user's invocation requested it ("ship with a demo", "include a screenshot"), proceed directly to capture. If capture turns out to be not possible (no runnable surface, missing credentials, docs-only diff) or clearly not useful, note that briefly and proceed without evidence -- do not force capture for its own sake.
Agent judgment on authored changes. If you authored the commits in this session and know the change is clearly non-observable (internal plumbing, backend refactor without user-facing effect, type-level changes, etc.), skip the prompt without asking. The categorical skip list below is not exhaustive -- trust judgment about the change you just wrote.
Otherwise, run the full decision: if the branch diff changes observable behavior (UI, CLI output, API behavior with runnable code, generated artifacts, workflow output) and evidence is not otherwise blocked (unavailable credentials, paid services, deploy-only infrastructure, hardware), ask: "This PR has observable behavior. Capture evidence for the PR description?"
gh-demo-reel skill with a target description inferred from the branch diff. gh-demo-reel returns Tier, Description, URL, and Path. Exactly one of URL or Path contains a real value; the other is "none". If capture returns a public URL, pass it as steering to gh:pr-description (e.g., "include the captured demo: as a ## Demo section") or splice into the returned body before apply. If capture returns a local Path instead (user chose local save), pass steering that notes evidence was captured but is local-only (e.g., "evidence was captured locally -- note in the PR that a demo was recorded but is not embedded because the user chose local save"). If capture returns Tier: skipped or both URL and Path are "none", proceed with no evidence.gh:pr-description or splice in before apply.When evidence is not possible (docs-only, markdown-only, changelog-only, release metadata, CI/config-only, test-only, or pure internal refactors), skip without asking.
Delegate title and body generation to gh-pr-description. Load the gh-pr-description skill:
base:<base-remote>/<base-branch> using the already-resolved base from earlier in this step, so gh-pr-description describes the correct commit range even when the branch targets a non-default base (e.g., develop, release/*). Append any captured-evidence context or user focus as free-text steering (e.g., "include the captured demo: as a ## Demo section", or "evidence captured locally -- not embedded" for local saves).https://github.com/owner/repo/pull/123). The URL preserves repo/PR identity even when invoked from a worktree or subdirectory; the skill reads the PR's own baseRefName so no base: override is needed. Append any focus steering as free text after the URL.gh-pr-description returns a {title, body_file} block (body in an OS temp file). It applies the value-first writing principles, commit classification, sizing, narrative framing, writing voice, visual communication, numbering rules, and the GaleHarness CLI badge footer internally. Use the returned values verbatim in Step 7; do not layer manual edits onto them unless a focused adjustment is required (e.g., splicing an evidence block captured in this step that was not passed as steering text — in that case, edit the body file directly before applying).
If gh-pr-description returns a graceful-exit message instead of {title, body_file} (e.g., closed PR, no commits to describe, base ref unresolved), report the message and stop — do not create or edit the PR.
Using the {title, body_file} returned by gh-pr-description:
gh pr create --title "<returned title>" --body "$(cat "<returned body_file>")"
Keep the title under 72 characters; gh-pr-description already emits a conventional-commit title in that range.
The new commits are already on the PR from Step 5. Report the PR URL, then ask whether to rewrite the description.
If yes, run Step 6 now to generate {title, body_file} via gh-pr-description (passing the existing PR URL as pr:), then apply the returned title and body file:
gh pr edit --title "<returned title>" --body "$(cat "<returned body_file>")"
If no -- skip Step 6 entirely and finish. Do not run delegation or evidence capture when the user declined the rewrite.
Output the PR URL.