pr-ship
Skill0 starsChanged 4 months agoMITView on GitHub
Commit the current changes, push the branch, and open a pull request — the full ship flow end to end. Invoke explicitly with /pr-ship; not triggered automatically because it pushes and opens a PR (side effects).
- Reads credentials
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- FerroxLabs/waylandtheir own version, first seen Jun 7, 2026
- AI-Answer/Agent-Clubtheir own version, first seen Mar 29, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- FerroxLabs/wayland★ 606same name
- AI-Answer/Agent-Club★ 9same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- tddSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
Run this flow in order. Stop and ask before any step marked [confirm] — those are the irreversible or judgment-call points.
- Distinctive: line 17
Run git status and git diff (staged and unstaged) to see everything that would ship.
- Distinctive: line 19
[confirm]: If there are unrelated changes mixed in (e.g.
- Distinctive: line 33
Use a heredoc for the commit message so formatting survives correctly:
- Very specific: line 44
Never use --no-verify, --no-gpg-sign, or any flag that skips hooks/signing unless the user explicitly asked for it in this session.
≈ “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.
Files
Current state
!git status --short
Instructions
Run this flow in order. Stop and ask before any step marked [confirm] — those are the irreversible or judgment-call points.
1. Survey the change
Run git status and git diff (staged and unstaged) to see everything that would ship. Run git log --oneline -10 to see this repo's commit message style.
[confirm] If there are unrelated changes mixed in (e.g. a drive-by formatting pass alongside a feature), point them out and ask whether they should be split into a separate commit/PR before continuing.
2. Stage deliberately
Stage specific files by name. Never git add -A / git add . — that's how .env, credential files, or accidental large binaries end up in a commit. If something suspicious shows up in git status (a .env, a .pem, a node_modules/ that shouldn't be tracked), stop and flag it instead of staging it.
3. Write the commit message
- Imperative mood, focused on why the change was made, not a mechanical diff recap.
- Match this repo's existing message style (from step 1's
git log). - One logical change per commit where practical — if the staged diff is really two unrelated changes, say so before committing.
4. Commit
Use a heredoc for the commit message so formatting survives correctly:
git commit -m "$(cat <<'EOF'
<summary line>
<body if needed>
EOF
)"Never use --no-verify, --no-gpg-sign, or any flag that skips hooks/signing unless the user explicitly asked for it in this session.
5. Push
[confirm] if this is the first push of a new branch, or if pushing would overwrite remote history in any way. A plain git push on an existing tracked branch (fast-forward) does not need confirmation; anything requiring --force or --force-with-lease always does, and should not be attempted without explicit, current-turn approval.
git push -u origin <branch>6. Open the PR
Check whether a PR already exists for this branch (gh pr view may error harmlessly if not) before creating a new one. Draft title (under 70 chars) and body from the full commit history on this branch since it diverged from the base branch, not just the latest commit — review every commit that will be included.
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
- <bullet 1>
- <bullet 2>
## Test plan
- [ ] <how to verify this>
EOF
)"7. Report
Return the PR URL. Do not push again or amend after opening the PR unless explicitly asked — a second silent push after the human has seen "done" is a common source of confusion about what's actually in the PR.
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
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.