Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/khrichtchatyi/ship-it/open-prnpx skills add khrichtchatyi/ship-it --skill open-prgit clone --depth 1 https://github.com/khrichtchatyi/ship-itWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/khrichtchatyi/ship-it/open-pr)<a href="https://agentmods.dev/skills/khrichtchatyi/ship-it/open-pr"><img src="https://agentmods.dev/badge/skills/khrichtchatyi/ship-it/open-pr.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00079 | $0.01882 |
| Opus 5 | $0.00039 | $0.00941 |
| Sonnet 5 | $0.00016 | $0.00376 |
| Haiku 4.5 | $0.00008 | $0.00188 |
Grade A, and why
open-pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 245 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Resolve the target GitHub repository from the user's
prompt, or from the upstream of the current branch
(git config branch.<branch>.remote, falling back
to origin) when the user names none.
Refuse to run when neither resolves.
Verify the GitHub CLI is authenticated with
gh auth status before any other gh call.
Refuse to run when it is not — otherwise the skill cascades authentication errors.
Refuse to run when the current branch is the
repository's default branch (main or master).
Refuse to run when the branch has no commits ahead of the default — this skill ships work that already exists, and never invents commits.
Refuse to run when the working tree has uncommitted changes — staged, unstaged, or untracked.
Point the user to the sibling skill commit to record
the pending edits first; a pull request must reflect
a clean, committed state.
Do not modify source files, amend existing commits, rebase, or squash the branch.
This skill writes only the git push, the new pull
request, and (when ping criteria are met) one
follow-up comment on GitHub.
Do not run the build, the test suite, the linter, or any static analysis tool — this skill ships the branch as it stands and trusts the author to have verified it.
Identify the default branch with
gh repo view <owner>/<repo> --json defaultBranchRef --jq .defaultBranchRef.name,
and use that name as the base of the pull request.
Do not hard-code main or master.
Confirm the current branch is up to date with the
remote default branch using the resolved remote name
(git fetch <remote> && git log --oneline <remote>/<default>..HEAD).
That keeps the diff in the pull request to the author's intended change, not an accidental merge backlog.
Detect a fork workflow by comparing the resolved
remote's URL (git remote get-url <remote>) with
the target slug.
When they differ — for example, the user pushes from a
personal fork to the upstream organization — pass
--head <fork-owner>:<branch> to every gh call
that takes a head ref.
GitHub will not match a cross-repository branch on its short name alone.
List any open pull request that already targets the
same head with
gh pr list --repo <owner>/<repo> --state open --head <head> --json number,title,author.
Discard the run when the list is non-empty — a second pull request from the same branch is a duplicate.
Push the current branch to the resolved remote with
git push -u <remote> <branch> before opening the
pull request.
gh pr create refuses to open a pull request from a
branch the remote does not yet know about.
Open the pull request with
gh pr create --repo <owner>/<repo> --base <default> --head <head> --title ... --body ....
Use a short, declarative title in the imperative mood
— for example Drop trailing newline guard in parser — not a vague phrase like Fixes or
Update.
Derive the title and the body from the commit messages
on the branch (for example
git log --reverse --pretty=format:%s%n%n%b <remote>/<default>..HEAD)
and from the diff.
Do not derive from the branch name alone — the branch name rarely tells the reviewer what the change does.
Check for a pull request template at
.github/PULL_REQUEST_TEMPLATE.md,
.github/pull_request_template.md, or
docs/PULL_REQUEST_TEMPLATE.md.
When one exists, fill its sections with the derived
content and pass the result via --body-file so the
template structure survives intact.
Fall back to a free-form body only when no template is present.
Size the body to the change — one short paragraph for a trivial fix, up to three paragraphs naming what changed, why it is needed, and any follow-up the reviewer should know.
Do not expand a one-line fix into a three-paragraph essay.
Talk like a human in the pull request body and in any follow-up comment.
Use your own words, write in plain conversational phrasing, and drop the stock AI cadence, boilerplate openings, and buzzword strings.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 245 lines · 79 tokens per session scan A fdb6b75685a5
open-pr is a skill published in the GitHub repository khrichtchatyi/ship-it (2 stars, last pushed 23d ago), licensed MIT. It adds 79 tokens to every session and 1,882 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
publish-github-release
Use this whenever the user asks to ship, publish, release, tag, or cut a new version of the project — OR when CHANGELOG.md has an "Unreleased" / in-progress section ready to be shipped. The skill bumps the version across all version-bearing files, regenerates the CHANGELOG entry from git log since the last tag…
hotfix
Set up the branch topology for a patch release against a previously tagged version: ensures release/ . exists from the source tag, then creates hotfix/ off it. TRIGGER when the user says "hotfix v1.0.0", "patch the release", "I need to fix something in the v2 line", "create a hotfix branch", "/nyann:hotfix". Match…
project-standard-release
Prepare and ship an Agent Atelier release. Bumps the semver version in the lockstep manifests (package.json, every plugins//.claude-plugin/plugin.json, every .claude-plugin/marketplace.json plugins[] entry), updates CHANGELOG.md (Keep a Changelog format, creates it if missing), creates an annotated git tag on main…
release
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and create the GitHub release. Use when shipping a new plugin version. NOT distributed.
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
push-ci
Push to remote and monitor CI. Validates branch safety, executes git push WITH explicit user approval, then monitors CI run status via gh CLI. Use when: user says 'push', 'push and watch CI', 'ship it', 'push-ci'. Not for: committing (use /smart-commit), creating PRs (use /create-pr), merging (use /merge-prep).