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/gstack-document-releasenpx skills add GCWing/BitFun --skill gstack-document-releasegit 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.00095 | $0.03524 |
| Opus 5 | $0.00048 | $0.01762 |
| Sonnet 5 | $0.00019 | $0.00705 |
| Haiku 4.5 | $0.00010 | $0.00352 |
Grade A, and why
document-release 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 yesterday.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- document-release — 86% identical, 204 lines differ
How it starts
The opening of the file, as written. The whole thing — 369 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Document Release: Post-Ship Documentation Update
You are running the /document-release workflow. This runs after /ship (code committed, PR
exists or about to exist) but before the PR merges. Your job: ensure every documentation file
in the project is accurate, up to date, and written in a friendly, user-forward voice.
You are mostly automated. Make obvious factual updates directly. Stop and ask only for risky or subjective decisions.
Only stop for:
- Risky/questionable doc changes (narrative, philosophy, security, removals, large rewrites)
- VERSION bump decision (if not already bumped)
- New TODOS items to add
- Cross-doc contradictions that are narrative (not factual)
Never stop for:
- Factual corrections clearly from the diff
- Adding items to tables/lists
- Updating paths, counts, version numbers
- Fixing stale cross-references
- CHANGELOG voice polish (minor wording adjustments)
- Marking TODOS complete
- Cross-doc factual inconsistencies (e.g., version number mismatch)
NEVER do:
- Overwrite, replace, or regenerate CHANGELOG entries — polish wording only, preserve all content
- Bump VERSION without asking — always use AskUserQuestion for version changes
- Use
Writetool on CHANGELOG.md — always useEditwith exactold_stringmatches
BitFun Team Mode Dispatch
When this skill is invoked by BitFun Team Mode, this skill supplies the documentation-release methodology. Use existing Task sub-agents for read-only doc drift discovery, then keep edits in the main Team session.
- Do not assume a Technical Writer sub-agent exists. Choose only from the Task tool's available agents.
- Prefer matching custom docs/writing sub-agents if available; otherwise use
Explorefor diff-to-doc mapping andFileFinderfor locating impacted docs. - Good parallel Task tracks: README/API drift, architecture docs drift, changelog/release-note gaps, and TODO cleanup candidates.
- Do not ask Task sub-agents to edit docs. Require evidence: changed behavior, affected docs, stale statements, and suggested wording.
- The main Team orchestrator owns all doc edits and risky narrative questions.
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.
- yesterday First seen · 369 lines · 95 tokens per session scan A bad0b0a4beb6
document-release is a skill published in the GitHub repository GCWing/BitFun (1,871 stars, last pushed yesterday), licensed MIT. It adds 95 tokens to every session and 3,524 once invoked, about $0.0005 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.