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/johnkueh/bq-analytics/releasenpx skills add johnkueh/bq-analytics --skill releasegit clone --depth 1 https://github.com/johnkueh/bq-analyticsWhat 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.00101 | $0.03613 |
| Opus 5 | $0.00051 | $0.01806 |
| Sonnet 5 | $0.00020 | $0.00723 |
| Haiku 4.5 | $0.00010 | $0.00361 |
Grade A, and why
bq-analytics-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 3d 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 — 329 lines — stays where its author put it; the contents beside it link to each section on GitHub.
bq-analytics release management
Server-driven release UX in one Edge Config blob. Powers four user-facing surfaces:
| State | What user sees | Trigger |
|---|---|---|
| Hard block | Full-screen, no dismiss, "Update now" | verdict === 'hard' |
| Soft nudge | Sheet with "Update in App Store" + "Later" | verdict === 'soft' |
| Just updated | Sheet with "Got it" + entries | whatsNew.version > lastSeen, verdict ok |
| OTA available | Existing prompt + whatsNew titles as bullets |
Updates.useUpdates() |
The blob lives at Edge Config key release:
{
"gate": {
"minIosBuild": 0,
"minAndroidBuild": 0,
"hardBlock": false,
"message": "optional override copy"
},
"whatsNew": null,
"updateUrls": {
"production": { "ios": "itms-apps://...", "android": "market://..." },
"preview": { "ios": "itms-beta://..." }
}
}
Mutate via the bq-release CLI shipped in the package. Sub-second propagation through Vercel Edge Config (60s CDN cache on the consumer-facing route).
Detect current state
| Signal | What it means | Where to start |
|---|---|---|
bq-analytics in deps, EDGE_CONFIG= in env, release key seeded |
fully wired | jump to Operate |
bq-analytics + Edge Config store from flags, no release key |
flags wired, release not yet | Step 2 (skip provisioning) |
bq-analytics in deps, no EDGE_CONFIG= |
greenfield for Edge Config | Step 1 |
no bq-analytics |
run /bq-analytics-install first |
grep -E '"bq-analytics"' package.json && echo "sdk present"
grep -E '^EDGE_CONFIG=' .env.local 2>/dev/null && echo "edge config provisioned"
pnpm exec bq-release show 2>/dev/null && echo "release key live" || echo "release key missing"
Step 1 — Provision Edge Config
If the project already ran /bq-analytics-flags, the store exists — skip ahead. Otherwise:
./node_modules/bq-analytics/scripts/setup-edge-config.sh
Idempotent. Creates a bq-analytics-flags Edge Config store, mints a read token, pushes EDGE_CONFIG to Vercel Production env. Same store hosts both flags and release keys — keeping them together avoids a second read 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.
- 3d ago First seen · 329 lines · 101 tokens per session scan A e225ed2f84da
bq-analytics-release is a skill published in the GitHub repository johnkueh/bq-analytics (5 stars, last pushed 2mo ago), licensed MIT. It adds 101 tokens to every session and 3,613 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-31.
Other skills, from other repositories
sampo-changeset
Create or update Sampo changesets for Mitsuro version bumps and changelogs.
rn-devtools-release
Ship a React Native or Expo app to TestFlight, the App Store and Google Play from the hub, and read where a release actually stands. Use when the app is being released, promoted, halted or investigated after shipping. Triggers on "ship it", "send it to TestFlight", "submit for review", "is the build ready", "promote…
template-release
Cut a new template version — bump TEMPLATEVERSION, write upgrade notes, tag and publish a GitHub release. Use when releasing a new version of the agentic-mobile-blueprint template.
eas-release
Reference for building and releasing React Native apps with EAS and the app stores. Use when configuring eas.json build profiles, publishing OTA updates, submitting to the App Store or Play Store, handling store rejections, or planning versioning and rollback strategy.
prep-release
Pre-release audit for a React Native app. Use when the user is about to submit to the App Store or Play Store, cut a release, or asks for a release checklist run.
managing-app-versions
Manages semantic versioning for mobile apps across iOS and Android platforms. Use when the user says "bump version", "increment build number", "set version to", "release patch/minor/major", or "sync build numbers". Single source of truth is .msd/versions/{app-id}/version.json. Syncs to app.json (Expo), Info.plist…