How do I install the Publish Pr skill?

Run npx skillmds@latest add gitt510/publish-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Publish Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Publish Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Publish Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Publish Pr?

gitt510 (@gitt510) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Publish Pr by gitt510 — Agent Skill

Name: Publish Pr
Author: gitt510

Publish Pr

Publish the current local changes to GitHub in one shot — confirm scope, commit, push, and open a ready pull request. Use whenever the user wants to ship finished local work to a PR ("open a PR for this", "publish this", "commit, push, and PR", "ship it"), even when the ask is terse, as long as there are local changes meant to go up. This is git + PR mechanics only: it does NOT merge (stop at opening the PR) and does NOT run tests/build/lint (correctness is a separate concern — see the boundary notes below).

gitt510 51d70ef 3.7 KB Updated Sep 17, 2026

File contents

Publish PR

Take whatever is in the working tree right now and turn it into an open pull request: figure out what should go in, commit it, push the branch, and open the PR. Nothing more.

The job is deliberately narrow. "Is the code correct?" and "should this be merged?" are real questions, but they belong to other tools (a verify step, CI, a human reviewer, a future merge-pr). Folding them in here would make the one-shot slow and ambiguous, so this skill leaves them out on purpose.

Workflow

1. See what's actually there

git status -sb
git diff HEAD
git branch --show-current

Read the diff before touching anything. You need to know what's staged, what's unstaged, and whether the current branch is a shared default branch.

2. Decide scope before staging

If everything in the tree clearly belongs to one change, stage it all. But if the tree is mixed — unrelated edits, stray debug prints, an unrelated file — do not reach for git add -A. Silently sweeping unrelated work into someone's PR is the kind of mistake that's annoying to unwind. Ask which files belong, then stage those paths explicitly.

3. Branch if you're on the default branch

If the current branch is main / master / the repo's default, create a new branch first — committing straight onto a shared default branch is what you're trying to avoid by opening a PR at all. Use a short, descriptive branch name derived from the change; if the repo has an obvious branch-naming convention, follow it. If already on a feature branch, stay on it.

4. Commit

Use a terse, scoped message:

<area>: <subject>

<area> is the part of the codebase or component touched; <subject> says what changed, in the imperative. Keep it to one line unless the change genuinely needs a body.

Examples:

auth: reject expired refresh tokens
docs: fix broken link in setup guide
fish: add gh-issue-pull abbr

Add the Co-Authored-By trailer identifying the agent that made the commit — these commits are authored through the agent, not by hand, so attribute them. Use the co-author line your harness convention specifies.

5. Push

git push -u origin $(git branch --show-current)

6. Open the PR (ready, not draft)

gh pr create --title "<title>" --body-file <file>

Writing the body is owned by the build-pr-description skill — invoke it and follow its rules and procedure. This skill carries no skeleton or format knowledge of its own.

Default to a ready PR; only pass --draft if the user asks for a draft.

7. Report

Give the user the branch name, the commit, and the PR URL, plus anything still needing their attention (e.g. an unrelated change you left unstaged).

Boundaries

No merge. Stop at an open PR. Merging is a separate decision (CI, review, merge strategy) and lives in its own flow.
No test/build/lint run. This skill won't guess and run a project's checks — that's unbounded and overlaps with CI. If the user wants pre-push verification, they run it deliberately beforehand.
Never stage unrelated changes silently (see step 2).
Stop and explain if the repo has no accessible GitHub remote, or gh / auth is missing, rather than guessing.

---name: publish-prdescription: Publish the current local changes to GitHub in one shot — confirm scope, commit, push, and open a ready pull request. Use whenever the user wants to ship finished local work to a PR ("open a PR for this", "publish this", "commit, push, and PR", "ship it"), even when the ask is terse, as long as there are local changes meant to go up. This is git + PR mechanics only: it does NOT merge (stop at opening the PR) and does NOT run tests/build/lint (correctness is a separate concern — see the boundary notes below).---# Publish PRTake whatever is in the working tree right now and turn it into an open pullrequest: figure out what should go in, commit it, push the branch, and open thePR. Nothing more.The job is deliberately narrow. "Is the code correct?" and "should this bemerged?" are real questions, but they belong to other tools (a verify step, CI,a human reviewer, a future `merge-pr`). Folding them in here would make theone-shot slow and ambiguous, so this skill leaves them out on purpose.## Workflow### 1. See what's actually there```bashgit status -sbgit diff HEADgit branch --show-current```Read the diff before touching anything. You need to know what's staged, what'sunstaged, and whether the current branch is a shared default branch.### 2. Decide scope before stagingIf everything in the tree clearly belongs to one change, stage it all. But ifthe tree is **mixed** — unrelated edits, stray debug prints, an unrelated file —do not reach for `git add -A`. Silently sweeping unrelated work into someone'sPR is the kind of mistake that's annoying to unwind. Ask which files belong,then stage those paths explicitly.### 3. Branch if you're on the default branchIf the current branch is `main` / `master` / the repo's default, create a newbranch first — committing straight onto a shared default branch is what you'retrying to avoid by opening a PR at all. Use a short, descriptive branch namederived from the change; if the repo has an obvious branch-naming convention,follow it. If already on a feature branch, stay on it.### 4. CommitUse a terse, scoped message:```<area>: <subject>````<area>` is the part of the codebase or component touched; `<subject>` says whatchanged, in the imperative. Keep it to one line unless the change genuinelyneeds a body.**Examples:**- `auth: reject expired refresh tokens`- `docs: fix broken link in setup guide`- `fish: add gh-issue-pull abbr`Add the `Co-Authored-By` trailer identifying the agent that made the commit —these commits are authored through the agent, not by hand, so attribute them.Use the co-author line your harness convention specifies.### 5. Push```bashgit push -u origin $(git branch --show-current)```### 6. Open the PR (ready, not draft)```bashgh pr create --title "<title>" --body-file <file>```Writing the body is owned by the **build-pr-description** skill — invoke it andfollow its rules and procedure. This skill carries no skeleton or formatknowledge of its own.Default to a **ready** PR; only pass `--draft` if the user asks for a draft.### 7. ReportGive the user the branch name, the commit, and the PR URL, plus anything stillneeding their attention (e.g. an unrelated change you left unstaged).## Boundaries- **No merge.** Stop at an open PR. Merging is a separate decision (CI, review, merge strategy) and lives in its own flow.- **No test/build/lint run.** This skill won't guess and run a project's checks — that's unbounded and overlaps with CI. If the user wants pre-push verification, they run it deliberately beforehand.- **Never stage unrelated changes silently** (see step 2).- **Stop and explain** if the repo has no accessible GitHub remote, or `gh` / auth is missing, rather than guessing.

Frequently asked questions