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/tnt-likely/honeycomb/releasenpx skills add TNT-Likely/honeycomb --skill releasegit clone --depth 1 https://github.com/TNT-Likely/honeycombWrote 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/tnt-likely/honeycomb/release)<a href="https://agentmods.dev/skills/tnt-likely/honeycomb/release"><img src="https://agentmods.dev/badge/skills/tnt-likely/honeycomb/release.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.00176 | $0.02537 |
| Opus 5 | $0.00088 | $0.01269 |
| Sonnet 5 | $0.00035 | $0.00507 |
| Haiku 4.5 | $0.00018 | $0.00254 |
Grade A, and why
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 today.
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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
beecount-release — 双仓发版流水线
核心信念:发版动作(打 tag)不可逆且公开,但流程的其余部分都可重复。所以确认在前、tag 在后,tag 之后的一切交给 CI 和收尾清单。
红线(先读)
- 版本号与发布范围必须用户拍板。用 AskUserQuestion 一次问清:这次发 App、Cloud,还是两个都发?各用什么版本号?可以用
git tag --sort=-v:refname | head -1推算建议值(默认 minor +1)作为推荐选项,但用户没确认前绝不打 tag。 - 打 tag 前的最后一步,把即将执行的 tag 命令(仓库+版本号)展示给用户过目。两个仓的 tag 序列差很远(App 3.x vs Cloud 1.x),打串了就是公开事故——历史上真的发生过在 BeeCount 仓里打 Cloud 版本号的事。
- 商店文案红线:Google Play
<lang>段不得出现任何 iOS 内容(纯 iOS 条目整条剔除,不是改写);商店文案不写自部署/服务端运维条目(那些只进 Cloud 的 GitHub Release 和官网)。
流程
0 预检 → 1 确认门(范围+版本号) → 2 Cloud 打 tag → 3 App 打 tag
→ 4 changelog 双格式 → 5 官网文档同步(纯 bug 修复可跳) → 6 视频+文案(可选) → 7 收尾核验
只发一端时跳过另一端的步骤;双端都发时 Cloud 永远在 App 之前(版本偏斜规则:老 App 忽略新字段没事,新 App 对老服务端可能表现为"设置不生效",所以让用户的生产环境先有新镜像可升)。
0. 预检(两仓各自)
git -C ~/code/mine/BeeCount status --short && git -C ~/code/mine/BeeCount log origin/main..main --oneline
git -C ~/code/mine/BeeCount-Cloud status --short && git -C ~/code/mine/BeeCount-Cloud log origin/main..main --oneline
- 工作区必须干净、main 与 origin 同步;有未合 PR 先问用户是否要进这个版本。
- 顺手列出上个 tag 以来的提交(
git log <last-tag>..main --oneline),这既是确认门里"这版包含什么"的依据,也是 changelog 的素材。
1. 确认门
AskUserQuestion 问两件事(可一次问完):范围(仅 App / 仅 Cloud / 都发)与版本号(给出建议值供选,允许用户改)。得到明确答案后,把将要执行的命令原样列给用户看一眼再动手。
2. Cloud 发版(若在范围内)
cd ~/code/mine/BeeCount-Cloud && git tag <X.Y.Z> && git push origin <X.Y.Z>
- tag 必须三段式
*.*.*(两段式不触发 release workflow)。 - CI 自动:测试 → 构建前端 → 推 Docker 镜像
sunxiao0721/beecount-cloud:<X.Y.Z>+:latest→ 生成 GitHub Release。 - 数据库迁移随镜像启动自动执行,无需手工步骤;但若本版含迁移,收尾时要在升级提示里写明。
3. App 发版(若在范围内)
cd ~/code/mine/BeeCount && git tag <X.Y.Z> && git push origin <X.Y.Z>
- 不要改 pubspec.yaml 的 version(本地永远是 0.0.1):CI 从 tag 名注入版本号,本地改了也会被覆盖,纯属白改。
- 任意 tag 名都会触发 Release workflow,所以 tag 名打错=错误版本直接开始构建,这就是红线 2 存在的原因。
- CI 产出:多 ABI APK(arm64 主包/armv7/x86_64/universal)+ iOS 构建 + GitHub Release。
4. changelog 双格式(App 发版时)
写 BeeCount/.docs/changelogs/<X.Y.Z>.txt,单文件两段,没有 CI 消费方——用户在 App Store Connect / Google Play Console 后台手动粘贴,所以格式必须可直接复制。模板(取自 3.4.0 真实例):
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.
- today Changed · -1 lines 201eabceb1d3
- 4d ago First seen · 132 lines · 176 tokens per session scan A 11b1fa188787
release is a skill published in the GitHub repository TNT-Likely/honeycomb (2 stars, last pushed 4d ago), licensed MIT. It adds 176 tokens to every session and 2,537 once invoked, about $0.0009 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
git-for-research-code
When the user wants to version-control optimization research code - small commits per experiment change, tags for paper result snapshots, .gitignore for solver logs, linking result tables to commit hashes, and branch strategy for risky refactors. Also use when the user mentions "git workflow," "version control…
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.
version-bump
This skill automates version bumping during the release process for the Claude Code Handbook monorepo. It should be used when the user requests to bump versions, prepare a release, or increment version numbers across the repository.
craft-plugin-release
Releasing Craft CMS plugins — tagging, Packagist propagation, GitHub releases, branch promotion, shared-library ordering, history rewrites. ALWAYS load when cutting, preparing, verifying, or debugging a plugin release: bumping a version, dating a changelog, creating or moving a git tag, or checking what Packagist…
seam-probe
This skill should be used when testing or debugging an embedded-runtime boundary exposed through a dynamically loaded C-ABI library or Unix-domain socket, including requests to inspect exports, exercise FFI callbacks, send framed messages, reproduce seam crashes or hangs, fuzz a boundary, or correlate probe output…
electron-playwright-validator
This skill should be used when a user asks to launch, inspect, automate, test, validate, or debug an Electron desktop UI through Playwright/CDP, including blank renderers, runtime import failures, accessibility snapshots, layout defects, click-through flows, or post-change checks. Not for native macOS or mobile apps…