h3y6eh3y6e/agent-skills/skills/git-shipping/SKILL.md

git-shipping

Skill0 starsChanged 28 days agoMITView on GitHub

Guides the git workflow for shipping code changes — branch, commit, push, PR. Use whenever asked to `commit`, `push`, `pr`/`ship`/`open a PR`/`merge this`, or manage branches, and whenever about to make code changes in a git repo, to confirm the branch is right before implementation starts — even if the user only described the change and never said the word "git".

Commits and pushes

In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- writing-skillsSkill
- building-wikiSkill
- compressing-knowledgeSkill
- creating-issuesSkill
- designing-cliSkill
- fuckSkill
- functional-domain-modelingSkill
- no-commentsSkill
- orchestratingSkill
- receiving-code-reviewSkill
- tracking-tasksSkill
- writing-japaneseSkill

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Treat short git requests as workflow shorthand.
line 17
Distinctive:
Ask only when the intended change scope is unclear enough that you might include unrelated work.
line 25
Very specific:
Use the cxg-commit skill for the commit message format, and pipe the message through cxg lint before committing.
line 34
Distinctive:
Prefer a repository PR template when one applies.
line 41
Very specific:
Create the PR with gh pr create --draft --body-file <file>, adding --attach <image> for each image the body references by that same path.
line 42
Distinctive:
Leave an existing PR's draft/ready state alone unless asked.
line 43
Very specific:
After each push to a branch with an open PR, reread the title and body against the diff and gh pr edit what no longer matches.
line 44
Distinctive:
After opening a PR, read the review loop and run it before reporting back.
line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Git Shipping

Code changes flow through: branch → commit → push → PR.

Intent Expansion

Treat short git requests as workflow shorthand.

User says	What it means
`commit`	Inspect, stage coherent chunks, commit
`push`	Inspect, create commits if needed, push
`pr`	Inspect, move off default branch if needed, commit, push, open PR

Ask only when the intended change scope is unclear enough that you might include unrelated work.

Branch

In a bare repository, follow the orchestrating skill instead. In a worktree, keep working there. Do not move already-started work into a new worktree; create or switch to the appropriate branch in place when safe.

Commit

Use the cxg-commit skill for the commit message format, and pipe the message through cxg lint before committing.

On a PR branch, keep history as meaningful units, not a log of attempts. Rewrite it with git history (see git history -h; reword opens GIT_EDITOR), and push with --force-with-lease.

Pull Request

PR titles use Conventional Commit subject format: type(scope): subject.
Prefer a repository PR template when one applies; otherwise read the PR body format before writing the body.
Create the PR with gh pr create --draft --body-file <file>, adding --attach <image> for each image the body references by that same path.
Leave an existing PR's draft/ready state alone unless asked.
After each push to a branch with an open PR, reread the title and body against the diff and gh pr edit what no longer matches.

Review Loop

After opening a PR, read the review loop and run it before reporting back.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free