Commit Push Pr
Ship one GitHub-issue iteration by committing, pushing, and opening a PR that closes the linked issue with validated labels and shared ship policy.
Overview
commit-push-pr is an agent skill most often used in Ship (also Build integrations) that commits, pushes, and opens a GitHub PR closing one validated issue per shared ship policy.
Install
npx skills add https://github.com/devarfeen/agent-skills-kit --skill commit-push-prWhat is this skill?
- Shared ship policy with `commit-push-pr` and `commit-push-close`—same rules except final step (PR vs issue close with co
- Label gate: exactly one category (`bug` or `enhancement`) plus `ready-for-agent` or `ready-for-human`; blocks on triage
- No `HITL:` or `AFK:` in commit subjects, branches, PR titles, or issue titles—routing lives only on issue labels
- Validates state via `gh issue view <num> --json state,labels,title,url` with exact label name matching
- Inline issue creation path when no linked issue exists, only for valid ad hoc work
- 2 paired ship skills (commit-push-pr vs commit-push-close) share one byte-identical policy file
Adoption & trust: 1 installs on skills.sh; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You finished an issue-scoped fix but lack a repeatable way to validate GitHub labels, push once, and open a PR that properly closes the linked issue.
Who is it for?
Solo builders using GitHub issues with `ready-for-agent` / `ready-for-human` and gh CLI who want PR-based shipping instead of direct issue close.
Skip if: Repos without GitHub Issues, teams that do not use label-gated agent routing, or work that should bypass PR review entirely without an approved inline-issue path.
When should I use this skill?
You are ready to ship one GitHub-issue iteration via commit, push, and PR with `Closes #N` after label validation.
What do I get? / Deliverables
You get a pushed branch and a PR with policy-compliant title and body linked to `Closes #N`, or a explicit stop with triage routing when labels are invalid.
- Git commit and push
- PR title and body closing issue #N
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because the skill’s end state is a pushed branch and opened PR—the handoff from implemented work to reviewable change. Launch subphase fits PR creation and issue linkage (`Closes #N`) as the release-prep step before merge, distinct from in-repo code review alone.
Where it fits
After fixing a backend bug on a `bug` + `ready-for-agent` issue, run the skill to push and open a PR for human review.
Open the PR with `Closes #N` as the standard launch-prep artifact before merge to main.
When the issue is `ready-for-human`, keep decision notes in the PR body while still using the same label gate.
Ship a small production hotfix tied to a single enhancement issue without skipping label validation.
How it compares
Use instead of ad-hoc “commit and open PR” chat steps when you need label validation and a paired close-vs-PR ship policy.
Common Questions / FAQ
Who is commit-push-pr for?
Indie and solo developers who ship agent-done work through GitHub issues and want one PR per iteration with enforced label rules.
When should I use commit-push-pr?
After implementation on a labeled `bug` or `enhancement` issue in `ready-for-agent` or `ready-for-human` during Ship; also at the end of Build tasks when your workflow requires a PR rather than closing the issue in place.
Is commit-push-pr safe to install?
It drives git push and GitHub PR creation via gh; review the Security Audits panel on this page and confirm repo write access before enabling in production repos.
SKILL.md
READMESKILL.md - Commit Push Pr
# Shared Ship Policy Shared rules for the `commit-push-close` and `commit-push-pr` skills. Both ship one GitHub-issue iteration; they differ only in the final step (close the issue with a comment vs. open a PR with `Closes #N`). Everything in this file applies to both. Where a rule says **ship output**, it means the commit message plus the skill's final artifact — the issue-close comment for `commit-push-close`, or the PR title and body for `commit-push-pr`. > This file is duplicated in both `commit-push-close/references/` and `commit-push-pr/references/` so each skill installs self-contained. Keep the two copies byte-identical when editing. ## Label validation Routing state lives in the linked issue's labels. Do not add `HITL:` or `AFK:` to commit subjects, branch names, PR titles, or GitHub issue titles. | Issue labels | Action | | ------------ | ------ | | exactly one category label (`bug` or `enhancement`) and state `ready-for-agent` | proceed | | exactly one category label (`bug` or `enhancement`) and state `ready-for-human` | proceed, keeping any human-decision notes in the commit body or ship output | | missing/conflicting labels, `needs-triage`, `needs-info`, or `wontfix` | stop and route through `/triage` unless this is valid ad hoc inline issue creation | | no linked issue | create one inline only for valid ad hoc work (see **Inline issue creation**) | Read state with: `gh issue view <num> --json state,labels,title,url`. Match label names exactly. ## Authorship policy (all supported coding agents) Apply this policy to outputs from every supported coding-agent path: Codex CLI, Claude CLI, Antigravity CLI, Cursor CLI, Opencode CLI, and GitHub Copilot CLI. - Never keep co-author, generated-by, or AI attribution text in authored output. - Forbidden patterns include `Co-authored-by:`, `Co-Authored-By:`, `Made with [Cursor]`, `Made-with:`, `Generated by`, `AI-assisted`, and agent signature footer lines. - If any tool auto-injects attribution, scrub and regenerate the draft before presenting it and before running any commit/close/PR command. ## Env parity policy (.env family + sample/example + docs) When env keys are touched in any way (add/remove/rename/value-contract change), enforce all of the following in the same iteration: - Keep key sets synchronized across `.env`, `.env.staging`, and `.env.production` (do not update only one file). - Keep `.sample.env` or `.example.env` updated with the latest keys and safe placeholder values. - Update README/docs where env keys, setup steps, or env behavior are referenced. - If `.env.staging` / `.env.production` are gitignored in that repo, still update local filesystem copies and report them explicitly as local-only updates. ## Inline issue creation Inline issue creation is only for small ad hoc work that started from a short request with no linked GitHub issue. Planned work should already have gone through `/to-prd` and `/to-issues`; if a planned issue is missing, not ready, ambiguous, cross-project, or multi-slice, stop and route back to `/feature-prompt` or `/to-issues` instead of fabricating a ship-time issue. Use `/triage` only when an existing issue needs label/state repair, reporter follow-up, `ready-for-human`, `wontfix`, or an agent brief. Do not use the ship flow to resolve planning ambiguity. If scope is still broad or unclear, route to `/feature-prompt` first. If blockers are high-fidelity ("needs to feel/see it"), route to `/handoff` + `/prototype` before returning to ship. When the workflow can't locate an issue for valid ad hoc work, create one before committing. Do **not** invent an issue number, and do **not** continue without an issue. 1. Draft from the diff: - **Title** — imperative, concise, no `HITL:`/`AFK:` marker. This title becomes the commit subject (and the PR title when shipping as a PR), so make it specific and traceable. - **Body** — generate from the original request, final diff, decisions made during the fix, files changed, an