[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71EHV3A0APBFZQ32239TY9S":3,"skill-same:01M71EHV3A0APBFZQ32239TY9S":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71EHV3A0APBFZQ32239TY9S","git-commit-push-pr",null,"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\", \"rewrite the PR body\", \"write a PR description\", \"draft a PR description\", or \"describe this PR\" — the skill will produce a description without committing or pushing if that is all the user wants. Produces PR descriptions that scale in depth with the complexity of the change, avoiding cookie-cutter templates.","JGXC100\u002FGaleHarnessCodingCLI","JGXC100","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F11926809?v=4","01M71EEBHJ3EGYSNNDDSVDKXNG","JGX","01M71EEBJ995S5J2HDEQCBA268",0,"MIT","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit-push-pr\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"git commit push","commit","git","push","pr","commit push pr","commit push","git commit","git commit push pr","cutter","pr body","update","request","change","create","when","open pull request","open","cookie","complexity","2026-11-10 10:12:30",false,"---\nname: git-commit-push-pr\ndescription: 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\", \"rewrite the PR body\", \"write a PR description\", \"draft a PR description\", or \"describe this PR\" — the skill will produce a description without committing or pushing if that is all the user wants. Produces PR descriptions that scale in depth with the complexity of the change, avoiding cookie-cutter templates.\n---\n\n# Git Commit, Push, and PR\n\nGo from working changes to an open pull request, rewrite an existing PR description, or generate a description without touching git state.\n\n**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), `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). 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.\n\n## Mode detection\n\nThree flavors of intent. Pick one and follow the matching path; otherwise default to the full workflow.\n\n- **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\u002Fnumber 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\u002Fnumber, 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`\u002F`gh pr create` only if the user asks.\n- **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.\n- **Full workflow.** Otherwise, follow the Full workflow below.\n\n## Context\n\n**On platforms other than Claude Code**, skip to the \"Context fallback\" section below and run the command there to gather context.\n\n**In Claude Code**, the six labeled sections below contain pre-populated data. Use them directly -- do not re-run these commands.\n\n**Git status:**\n!`git status`\n\n**Working tree diff:**\n!`git diff HEAD`\n\n**Current branch:**\n!`git branch --show-current`\n\n**Recent commits:**\n!`git log --oneline -10`\n\n**Remote default branch:**\n!`git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo 'DEFAULT_BRANCH_UNRESOLVED'`\n\n**Existing PR check:**\n!`gh pr view --json url,title,state 2>\u002Fdev\u002Fnull || echo 'NO_OPEN_PR'`\n\n### Context fallback\n\n**In Claude Code, skip this section — the data above is already available.**\n\nRun this single command to gather all context:\n\n```bash\nprintf '=== 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\u002FHEAD 2>\u002Fdev\u002Fnull || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\\n=== PR_CHECK ===\\n'; gh pr view --json url,title,state 2>\u002Fdev\u002Fnull || echo 'NO_OPEN_PR'\n```\n\n---\n\n## Description Update workflow\n\n### DU-1: Confirm intent\n\nAsk the user: \"Update the PR description for this branch?\" If declined, stop.\n\n### DU-2: Find the PR\n\nUse 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.\n\n### DU-3: Write and apply the updated description\n\n**Read `references\u002Fpr-description-writing.md` once now** — 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.\n\n**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, invoke `gh-demo-reel` separately to capture, then re-compose with the captured URL\u002Fpath spliced in.\n\n**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.\n\nIf confirmed, apply with `gh pr edit`. Substitute `\u003CTITLE>` verbatim; if it contains `\"`, `` ` ``, `$`, or `\\`, escape them or switch to single quotes. The body is best written to a temp file first to avoid shell-escaping the whole markdown body:\n\n```bash\nBODY_FILE=$(mktemp \"${TMPDIR:-\u002Ftmp}\u002Fgh-pr-body.XXXXXX\") && cat > \"$BODY_FILE\" \u003C\u003C'__GH_PR_BODY_END__'\n\u003Cthe composed body markdown goes here, verbatim>\n__GH_PR_BODY_END__\ngh pr edit --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n```\n\nThe quoted sentinel keeps `$VAR`, backticks, and any literal `EOF` inside the body from being expanded.\n\nReport the PR URL.\n\n---\n\n## Full workflow\n\n### Step 1: Gather context\n\nUse the context above. All data needed for this step and Step 3 is already available -- do not re-run those commands.\n\nThe remote default branch value returns something like `origin\u002Fmain`. Strip the `origin\u002F` prefix. If it returned `DEFAULT_BRANCH_UNRESOLVED` or a bare `HEAD`, try:\n\n```bash\ngh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'\n```\n\nIf both fail, fall back to `main`.\n\nIf the current branch is empty (detached HEAD), explain that a branch is required. Ask whether to create a feature branch now.\n- If yes, derive a branch name from the change content, create with `git checkout -b \u003Cbranch-name>`, and use that for the rest of the workflow.\n- If no, stop.\n\nIf the working tree is clean (no staged, modified, or untracked files), determine the next action:\n\n1. Run `git rev-parse --abbrev-ref --symbolic-full-name @{u}` to check upstream.\n2. If upstream exists, run `git log \u003Cupstream>..HEAD --oneline` for unpushed commits.\n\nDecision tree:\n\n- **On default branch, unpushed commits or no upstream** -- ask whether to create a feature branch (pushing default directly is not supported). If yes, create and continue from Step 5. If no, stop.\n- **On default branch, all pushed, no open PR** -- report no feature branch work. Stop.\n- **Feature branch, no upstream** -- skip Step 4, continue from Step 5.\n- **Feature branch, unpushed commits** -- skip Step 4, continue from Step 5.\n- **Feature branch, all pushed, no open PR** -- skip Steps 4-5, continue from Step 6.\n- **Feature branch, all pushed, open PR** -- report up to date. Stop.\n\n### Step 2: Determine conventions\n\nPriority order for commit messages and PR titles:\n\n1. **Repo conventions in context** -- follow project instructions if they specify conventions. Do not re-read; they load at session start.\n2. **Recent commit history** -- match the pattern in the last 10 commits.\n3. **Default** -- `type(scope): description` (conventional commits).\n\nWhen 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.\n\n### Step 3: Check for existing PR\n\nUse the current branch and existing PR check from context. If the branch is empty, report detached HEAD and stop.\n\nIf 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.\n\n### Step 4: Branch, stage, and commit\n\n1. If on the default branch, branch creation needs to handle three conditional cases: stale local `\u003Cbase>`, unpushed commits on local `\u003Cbase>` (intent unclear without asking), and uncommitted changes that collide with the fresh remote base. Read `references\u002Fbranch-creation.md` and follow its decision flow, then continue to step 2 below.\n2. 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.\n3. Stage and commit each group in a single call. Avoid `git add -A` or `git add .`. Follow conventions from Step 2:\n   ```bash\n   git add file1 file2 file3 && git commit -m \"$(cat \u003C\u003C'EOF'\n   commit message here\n   EOF\n   )\"\n   ```\n\n### Step 5: Push\n\n```bash\ngit push -u origin HEAD\n```\n\n### Step 6: Generate the PR title and body\n\nThe working-tree diff from Step 1 only shows uncommitted changes at invocation time. The PR description must cover **all commits** in the PR.\n\n**Read `references\u002Fpr-description-writing.md` once now** — Step 6 walks through it in order (Pre-A through H) with one interruption (the evidence decision below). Do not re-read the file later; refer to it by step letter.\n\n**Resolve the commit range and diff.** Run Step Pre-A from the reference (current-branch mode by default; PR mode if a PR ref was passed in from description-only mode). Pre-A handles base detection, in-repo SHA fetching with the `refs\u002Fpull\u002FN\u002Fhead` fallback, and the API-only fallback for fork-PRs and any local-git failure. Use Pre-A's commit list and diff (not Step 1's working-tree diff or `git log -10`) for both the evidence decision below and the rest of the reference.\n\n**Evidence decision (before composition).** Before running the full decision, two short-circuits:\n\n1. **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.\n\n2. **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.\n\nOtherwise, 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?\"\n\n- **Capture now** -- load the `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, splice it into the body as a `## Demo` section. If capture returns a local `Path` instead (user chose local save), note in the body 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.\n- **Use existing evidence** -- ask for the URL or markdown embed, then splice it in as a `## Demo` section.\n- **Skip** -- proceed with no evidence section.\n\nWhen evidence is not possible (docs-only, markdown-only, changelog-only, release metadata, CI\u002Fconfig-only, test-only, or pure internal refactors), skip without asking.\n\n**Compose the title and body.** Continue with Steps A through H from the already-loaded reference (commit classification, evidence handling, narrative framing, sizing, writing voice and principles, visual communication, title format, body assembly, the GaleHarness CLI badge, and the compression pass). For an existing PR, the current body was already read in Pre-A.\n\n### Step 7: Create or update the PR\n\nApply via `gh pr create` (new PR) or `gh pr edit` (existing PR). The body is best written to a temp file first to avoid shell-escaping the whole markdown body. Substitute `\u003CTITLE>` verbatim; if it contains `\"`, `` ` ``, `$`, or `\\`, escape them or switch to single quotes:\n\n```bash\nBODY_FILE=$(mktemp \"${TMPDIR:-\u002Ftmp}\u002Fgh-pr-body.XXXXXX\") && cat > \"$BODY_FILE\" \u003C\u003C'__GH_PR_BODY_END__'\n\u003Cthe composed body markdown goes here, verbatim>\n__GH_PR_BODY_END__\n```\n\nThe quoted sentinel keeps `$VAR`, backticks, and any literal `EOF` inside the body from being expanded.\n\n#### New PR (no existing PR from Step 3)\n\n```bash\ngh pr create --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n```\n\nKeep the title under 72 characters; the writing reference already emits a conventional-commit title in that range.\n\n#### Existing PR (found in Step 3)\n\nThe new commits are already on the PR from Step 5. Report the PR URL, then ask whether to rewrite the description.\n\n- If **no** -- skip Step 6 entirely and finish. Do not run composition or evidence capture when the user declined the rewrite.\n- If **yes**, perform these three actions in order. They are separate steps with a hand-off boundary between them -- do not stop between actions.\n  1. Run Step 6 to compose the new title and body.\n  2. **Preview and confirm.** Read the first two sentences of the Summary, plus the total line count. Ask the user (per the \"Asking the user\" convention at the top of this skill): \"New title: `\u003Ctitle>` (`\u003CN>` chars). Summary leads with: `\u003Cfirst two sentences>`. Total body: `\u003CL>` lines. Apply?\" The first two sentences of the Summary carry most of the reviewer's attention. If the user declines, they may pass focus text back for a regenerate; do not apply.\n  3. If confirmed, apply with `gh pr edit`:\n\n     ```bash\n     gh pr edit --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n     ```\n\n  Then report the PR URL (Step 8).\n\n### Step 8: Report\n\nOutput the PR URL.\n","# Git Commit, Push, and PR\n\nGo from working changes to an open pull request, rewrite an existing PR description, or generate a description without touching git state.\n\n**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), `request_user_input` in Codex, `ask_user` in Gemini, `ask_user` in Pi (requires the `pi-ask-user` extension). 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.\n\n## Mode detection\n\nThree flavors of intent. Pick one and follow the matching path; otherwise default to the full workflow.\n\n- **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\u002Fnumber 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\u002Fnumber, 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`\u002F`gh pr create` only if the user asks.\n- **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.\n- **Full workflow.** Otherwise, follow the Full workflow below.\n\n## Context\n\n**On platforms other than Claude Code**, skip to the \"Context fallback\" section below and run the command there to gather context.\n\n**In Claude Code**, the six labeled sections below contain pre-populated data. Use them directly -- do not re-run these commands.\n\n**Git status:**\n!`git status`\n\n**Working tree diff:**\n!`git diff HEAD`\n\n**Current branch:**\n!`git branch --show-current`\n\n**Recent commits:**\n!`git log --oneline -10`\n\n**Remote default branch:**\n!`git rev-parse --abbrev-ref origin\u002FHEAD 2>\u002Fdev\u002Fnull || echo 'DEFAULT_BRANCH_UNRESOLVED'`\n\n**Existing PR check:**\n!`gh pr view --json url,title,state 2>\u002Fdev\u002Fnull || echo 'NO_OPEN_PR'`\n\n### Context fallback\n\n**In Claude Code, skip this section — the data above is already available.**\n\nRun this single command to gather all context:\n\n```bash\nprintf '=== 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\u002FHEAD 2>\u002Fdev\u002Fnull || echo 'DEFAULT_BRANCH_UNRESOLVED'; printf '\\n=== PR_CHECK ===\\n'; gh pr view --json url,title,state 2>\u002Fdev\u002Fnull || echo 'NO_OPEN_PR'\n```\n\n---\n\n## Description Update workflow\n\n### DU-1: Confirm intent\n\nAsk the user: \"Update the PR description for this branch?\" If declined, stop.\n\n### DU-2: Find the PR\n\nUse 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.\n\n### DU-3: Write and apply the updated description\n\n**Read `references\u002Fpr-description-writing.md` once now** — 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.\n\n**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, invoke `gh-demo-reel` separately to capture, then re-compose with the captured URL\u002Fpath spliced in.\n\n**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.\n\nIf confirmed, apply with `gh pr edit`. Substitute `\u003CTITLE>` verbatim; if it contains `\"`, `` ` ``, `$`, or `\\`, escape them or switch to single quotes. The body is best written to a temp file first to avoid shell-escaping the whole markdown body:\n\n```bash\nBODY_FILE=$(mktemp \"${TMPDIR:-\u002Ftmp}\u002Fgh-pr-body.XXXXXX\") && cat > \"$BODY_FILE\" \u003C\u003C'__GH_PR_BODY_END__'\n\u003Cthe composed body markdown goes here, verbatim>\n__GH_PR_BODY_END__\ngh pr edit --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n```\n\nThe quoted sentinel keeps `$VAR`, backticks, and any literal `EOF` inside the body from being expanded.\n\nReport the PR URL.\n\n---\n\n## Full workflow\n\n### Step 1: Gather context\n\nUse the context above. All data needed for this step and Step 3 is already available -- do not re-run those commands.\n\nThe remote default branch value returns something like `origin\u002Fmain`. Strip the `origin\u002F` prefix. If it returned `DEFAULT_BRANCH_UNRESOLVED` or a bare `HEAD`, try:\n\n```bash\ngh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'\n```\n\nIf both fail, fall back to `main`.\n\nIf the current branch is empty (detached HEAD), explain that a branch is required. Ask whether to create a feature branch now.\n- If yes, derive a branch name from the change content, create with `git checkout -b \u003Cbranch-name>`, and use that for the rest of the workflow.\n- If no, stop.\n\nIf the working tree is clean (no staged, modified, or untracked files), determine the next action:\n\n1. Run `git rev-parse --abbrev-ref --symbolic-full-name @{u}` to check upstream.\n2. If upstream exists, run `git log \u003Cupstream>..HEAD --oneline` for unpushed commits.\n\nDecision tree:\n\n- **On default branch, unpushed commits or no upstream** -- ask whether to create a feature branch (pushing default directly is not supported). If yes, create and continue from Step 5. If no, stop.\n- **On default branch, all pushed, no open PR** -- report no feature branch work. Stop.\n- **Feature branch, no upstream** -- skip Step 4, continue from Step 5.\n- **Feature branch, unpushed commits** -- skip Step 4, continue from Step 5.\n- **Feature branch, all pushed, no open PR** -- skip Steps 4-5, continue from Step 6.\n- **Feature branch, all pushed, open PR** -- report up to date. Stop.\n\n### Step 2: Determine conventions\n\nPriority order for commit messages and PR titles:\n\n1. **Repo conventions in context** -- follow project instructions if they specify conventions. Do not re-read; they load at session start.\n2. **Recent commit history** -- match the pattern in the last 10 commits.\n3. **Default** -- `type(scope): description` (conventional commits).\n\nWhen 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.\n\n### Step 3: Check for existing PR\n\nUse the current branch and existing PR check from context. If the branch is empty, report detached HEAD and stop.\n\nIf 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.\n\n### Step 4: Branch, stage, and commit\n\n1. If on the default branch, branch creation needs to handle three conditional cases: stale local `\u003Cbase>`, unpushed commits on local `\u003Cbase>` (intent unclear without asking), and uncommitted changes that collide with the fresh remote base. Read `references\u002Fbranch-creation.md` and follow its decision flow, then continue to step 2 below.\n2. 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.\n3. Stage and commit each group in a single call. Avoid `git add -A` or `git add .`. Follow conventions from Step 2:\n   ```bash\n   git add file1 file2 file3 && git commit -m \"$(cat \u003C\u003C'EOF'\n   commit message here\n   EOF\n   )\"\n   ```\n\n### Step 5: Push\n\n```bash\ngit push -u origin HEAD\n```\n\n### Step 6: Generate the PR title and body\n\nThe working-tree diff from Step 1 only shows uncommitted changes at invocation time. The PR description must cover **all commits** in the PR.\n\n**Read `references\u002Fpr-description-writing.md` once now** — Step 6 walks through it in order (Pre-A through H) with one interruption (the evidence decision below). Do not re-read the file later; refer to it by step letter.\n\n**Resolve the commit range and diff.** Run Step Pre-A from the reference (current-branch mode by default; PR mode if a PR ref was passed in from description-only mode). Pre-A handles base detection, in-repo SHA fetching with the `refs\u002Fpull\u002FN\u002Fhead` fallback, and the API-only fallback for fork-PRs and any local-git failure. Use Pre-A's commit list and diff (not Step 1's working-tree diff or `git log -10`) for both the evidence decision below and the rest of the reference.\n\n**Evidence decision (before composition).** Before running the full decision, two short-circuits:\n\n1. **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.\n\n2. **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.\n\nOtherwise, 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?\"\n\n- **Capture now** -- load the `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, splice it into the body as a `## Demo` section. If capture returns a local `Path` instead (user chose local save), note in the body 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.\n- **Use existing evidence** -- ask for the URL or markdown embed, then splice it in as a `## Demo` section.\n- **Skip** -- proceed with no evidence section.\n\nWhen evidence is not possible (docs-only, markdown-only, changelog-only, release metadata, CI\u002Fconfig-only, test-only, or pure internal refactors), skip without asking.\n\n**Compose the title and body.** Continue with Steps A through H from the already-loaded reference (commit classification, evidence handling, narrative framing, sizing, writing voice and principles, visual communication, title format, body assembly, the GaleHarness CLI badge, and the compression pass). For an existing PR, the current body was already read in Pre-A.\n\n### Step 7: Create or update the PR\n\nApply via `gh pr create` (new PR) or `gh pr edit` (existing PR). The body is best written to a temp file first to avoid shell-escaping the whole markdown body. Substitute `\u003CTITLE>` verbatim; if it contains `\"`, `` ` ``, `$`, or `\\`, escape them or switch to single quotes:\n\n```bash\nBODY_FILE=$(mktemp \"${TMPDIR:-\u002Ftmp}\u002Fgh-pr-body.XXXXXX\") && cat > \"$BODY_FILE\" \u003C\u003C'__GH_PR_BODY_END__'\n\u003Cthe composed body markdown goes here, verbatim>\n__GH_PR_BODY_END__\n```\n\nThe quoted sentinel keeps `$VAR`, backticks, and any literal `EOF` inside the body from being expanded.\n\n#### New PR (no existing PR from Step 3)\n\n```bash\ngh pr create --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n```\n\nKeep the title under 72 characters; the writing reference already emits a conventional-commit title in that range.\n\n#### Existing PR (found in Step 3)\n\nThe new commits are already on the PR from Step 5. Report the PR URL, then ask whether to rewrite the description.\n\n- If **no** -- skip Step 6 entirely and finish. Do not run composition or evidence capture when the user declined the rewrite.\n- If **yes**, perform these three actions in order. They are separate steps with a hand-off boundary between them -- do not stop between actions.\n  1. Run Step 6 to compose the new title and body.\n  2. **Preview and confirm.** Read the first two sentences of the Summary, plus the total line count. Ask the user (per the \"Asking the user\" convention at the top of this skill): \"New title: `\u003Ctitle>` (`\u003CN>` chars). Summary leads with: `\u003Cfirst two sentences>`. Total body: `\u003CL>` lines. Apply?\" The first two sentences of the Summary carry most of the reviewer's attention. If the user declines, they may pass focus text back for a regenerate; do not apply.\n  3. If confirmed, apply with `gh pr edit`:\n\n     ```bash\n     gh pr edit --title \"\u003CTITLE>\" --body \"$(cat \"$BODY_FILE\")\"\n     ```\n\n  Then report the PR URL (Step 8).\n\n### Step 8: Report\n\nOutput the PR URL.\n",{"name":5,"description":7},"main","94fc651a7c5ff227f3e8f4b9678dc4566f535677","plugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit-push-pr",2,"https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI","https:\u002F\u002Fgithub.com\u002FJGXC100","2026-05-19 17:04:59",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add JGXC100\u002FGaleHarnessCodingCLI --skill git-commit-push-pr",{"tool":57,"command":58},"bunx","bunx skills add JGXC100\u002FGaleHarnessCodingCLI --skill git-commit-push-pr",{"tool":60,"command":61},"pnpm","pnpm dlx skills add JGXC100\u002FGaleHarnessCodingCLI --skill git-commit-push-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit-push-pr\u002FSKILL.md",true,[65,71],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fbranch-creation.md","REFERENCE","参考文档",3707,"https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit-push-pr\u002Freferences\u002Fbranch-creation.md",{"path":72,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fpr-description-writing.md",19509,"https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Fgit-commit-push-pr\u002Freferences\u002Fpr-description-writing.md",[76,92,106,118,126,134],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":87,"publishedAt":39},"01M71EJT9M91X2T91N4ZPCWHN3","skill-one","Sample skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fskill-one\u002FSKILL.md",[82],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[88,89,90,91],"skill one","one","sample skill","sample",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":99,"publishedAt":39},"01M71EJRH7M0DGZ1QXJ9PSFMB5","disabled-skill","A skill with model invocation disabled","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fdisabled-skill\u002FSKILL.md",[98],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[100,101,102,103,104,105],"disabled skill","a skill","with model","with","true","model",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":39},"01M71EJQMRH6JC9H9V5BQWM7RJ","claude-only-skill","A skill restricted to Claude Code only","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fsample-plugin\u002Fskills\u002Fclaude-only-skill\u002FSKILL.md",[112],{"categoryNo":83,"categoryName":84,"taxonomyType":85,"taxonomyTypeDesc":86},[114,115,116,117,101],"only","claude only skill","claude only","code",{"skillNo":119,"name":120,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"01M71EJPXZ0644M41M587FVKYQ","default-skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fskills\u002Fdefault-skill\u002FSKILL.md",[],[124,125],"default skill","default",{"skillNo":127,"name":128,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":39},"01M71EJP6RPF6PDAJ2SY4VMBDT","custom-skill","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fcustom-paths\u002Fcustom-skills\u002Fcustom-skill\u002FSKILL.md",[],[132,133],"custom skill","custom",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":143,"publishedAt":39},"01M71EJK74AZ929S8GF55G5CDV","test-xcode","Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator.","https:\u002F\u002Fgithub.com\u002FJGXC100\u002FGaleHarnessCodingCLI\u002Fblob\u002Fmain\u002Fplugins\u002Fgaleharness-cli\u002Fskills\u002Ftest-xcode\u002FSKILL.md",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":85,"taxonomyTypeDesc":86},"01JBSEEDCAT000000000000008","测试与质量",[144,145,146,147,148,149,23,150,125,104,151,152,153,34,117,154,155,156,157,158],"test","xcode","test xcode","apps","app","build and test","for","xcodebuildmcp","use","scheme","changes","build","ios","name","behavior"]