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/movahedan/monobun/git-pr-workflownpx skills add movahedan/monobun --skill git-pr-workflowgit clone --depth 1 https://github.com/movahedan/monobunWrote 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/movahedan/monobun/git-pr-workflow)<a href="https://agentmods.dev/skills/movahedan/monobun/git-pr-workflow"><img src="https://agentmods.dev/badge/skills/movahedan/monobun/git-pr-workflow.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 | $0.00068 | $0.02299 |
| Opus 5 | $0.00034 | $0.01149 |
| Sonnet 5 | $0.00014 | $0.00460 |
| Haiku 4.5 | $0.00007 | $0.00230 |
Grade A, and why
git-pr-workflow 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 — 170 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git + PR (monobun)
Prerequisite (phased initiatives): builder-workflow checkup PASS for this phase, then documentation-sync for the plan’s Documentation before PR list. Pipeline: initiative-workflow.
1. Verify
bun overall
2. Working tree
git status
Use this before branching to see what is modified, untracked, renamed, or deleted—enough to pick a branch prefix/slug and to spot unrelated changes that should stay out of the first commit.
3. Branch
Run after working tree observation and before staging so the first commit does not land on main and the branch name matches the actual change.
git branch --show-current
Before naming or validating the branch, read the full patch of what you are about to land (not --stat alone)—so the prefix/slug matches renames, deletes, and config churn, not a vague guess:
git diff HEAD
If the diff is huge, still scan paths, renames, deletes, and config keys (workflows, package.json, turbo.json, tools/scripts/, etc.). Fold untracked paths from git status (§2) into the same picture; they are not in git diff HEAD.
main— do not build a feature/fix commit stack here. Create and switch:git checkout -b <prefix>/<short-slug>(prefix + slug from the change; ask the user if the intent is ambiguous).- Any other branch — validate:
bun run precommit -- --branch(add--quietif you want no Ink UI). If it fails, move to a valid name: prefergit branch -m <prefix>/<short-slug>when the branch is not pushed yet; otherwisegit checkout -b <prefix>/<short-slug>from the current tip so uncommitted work follows.
Shape: prefix/rest-of-name — first /-segment must be an allowed prefix (commit feat ≠ branch feature).
Name rules: length 1–100; only [a-zA-Z0-9\-_/.]; no doubled -, _, or /; no leading or trailing separator; main skips prefix rules.
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 · 170 lines · 68 tokens per session scan A 9875f5014996
git-pr-workflow is a skill published in the GitHub repository movahedan/monobun (18 stars, last pushed yesterday), licensed MIT. It adds 68 tokens to every session and 2,299 once invoked, about $0.0003 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-30.
Other skills, from other repositories
github-automation
GitHub workflow automation, PR management, issue tracking, and code review coordination. Integrates with GitHub Actions and repository management. Use when: PR creation, code review, issue management, release automation, workflow setup. Skip when: local-only changes, non-GitHub repositories.
crew-commit
Canonical commit workflow for Gas Town crew members: pre-flight checks, branch creation, gt commit with agent identity, push, and PR creation. Use when ready to commit and submit work for review.
cherry-pick
Cherry-pick a commit from main to a Sui release branch, create the release PR, and report the PR URL.
task-snapshot
Create a commit or tag snapshot only when explicitly requested for a milestone, reproducibility checkpoint, handoff, or pinned artifact.
mflux-pr
Make a clean PR in mflux (inspect diff, quick verification, commit, push, open PR) using repo conventions.
comet-safe-delivery
在保护无关脏改动、关联 worktree、子模块和用户明确边界的前提下，提交、推送、合并或完成范围明确的 Comet 变更。用户要求提交、推送、合并回目标分支、清理 worktree 或交付已准备好的改动时使用。.