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/gcwing/bitfun/commit-push-prnpx skills add GCWing/BitFun --skill commit-push-prgit clone --depth 1 https://github.com/GCWing/BitFunWhat 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.02280 |
| Opus 5 | $0.00034 | $0.01140 |
| Sonnet 5 | $0.00014 | $0.00456 |
| Haiku 4.5 | $0.00007 | $0.00228 |
Grade A, and why
commit-push-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 2d 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 — 210 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit, Push, and Open a BitFun PR
Purpose
Publish an intentional change set from the current checkout: confirm scope, create a branch if needed, validate, commit, push, and create or update a GitHub pull request.
Invoking this skill is authorization for the requested commit/push/PR flow. It is not authorization to include ambiguous files, expose secrets, rewrite history, force-push, merge, or overwrite user work.
BitFun attribution contract
Unless the user explicitly opts out, always use the PR footer below exactly once. When this flow creates one or more real commits, also use the commit trailer exactly once in each new commit:
-
Commit trailer for each new commit, which GitHub uses for contributor/co-author attribution:
Co-authored-by: BitFun <[email protected]> -
Final line of the PR body, which provides the visible clickable link:
Generated with [BitFun](https://github.com/bitfun-ai)
These are different mechanisms. A Markdown link in the PR body does not make an account a Git contributor. Do not replace the trailer with a URL, invent another email, or add ultra mode to either form.
Do not duplicate either attribution. Preserve an equivalent existing trailer/footer. Do not rewrite or amend existing commits solely to add the trailer; when all requested changes are already committed, keep history intact and use the PR footer. If the user specifically requires retroactive commit attribution, explain that it requires history rewriting and ask before amending or rebasing.
Quick reference
- Inspect repository rules, status, remotes, base, and the complete branch diff.
- Confirm scope; stage only intended paths.
- Create
bitfun/<description>only when currently on the base branch. - Run the repository's focused verification.
- Commit real changes with the exact BitFun trailer once.
- Push normally; never force-push automatically.
- Update the exact matching PR or create a draft PR.
- End the PR body with the exact BitFun link footer once.
- Report the commit, head/base, validation, status, and PR URL.
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.
- 2d ago First seen · 210 lines · 68 tokens per session scan A 9e900e9aa3ec
commit-push-pr is a skill published in the GitHub repository GCWing/BitFun (1,871 stars, last pushed 2d ago), licensed MIT. It adds 68 tokens to every session and 2,280 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
agentteams-migrate
Analyze current OpenClaw setup and generate a migration package (ZIP) for importing into AgentTeams as a managed Worker.
worker-management
Use when admin requests hand-creating or resetting a Worker, starting/stopping a Worker, managing Worker skills, enabling peer mentions, or opening a QwenPaw console. Use agentteams-find-worker only as a helper for Nacos-backed market import or when task assignment needs you to discover a suitable Worker.
team-coordination
Use before deciding how you should organize team work: DAG vs Loop, dependency shape, task waves, quality gates, acceptance criteria, interruption, replanning, or what to do after Worker results arrive. Always use this skill for team organization strategy before you call project-management or task-management.
git-delegation
将所有 git 操作委托给 Manager 执行。Worker 无法直接访问 git credentials，因此任何需要认证的 git 操作（clone、push、fetch 等）都需要通过此机制委托给 Manager。.
github-operations
管理 GitHub Pull Request 和 Issue。包括创建/更新/合并 PR、添加评论、管理 Issue 等。注意：文件读写、分支操作、代码提交等请使用 git-delegation 技能。.
teamharness-task-delegation
Use when a Leader turns ready Quick Task or Project Work state into Worker task instructions, sends assignment messages, checks submitted results, and defines completion/blocker report contracts. Do not use to create projects, create rooms, or execute Worker tasks.