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 skills add TalissonVitorino/kmp-ios-skills --skill play-billing-upgradegit clone --depth 1 https://github.com/TalissonVitorino/kmp-ios-skillsWrote 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/talissonvitorino/kmp-ios-skills/play-billing-upgrade)<a href="https://agentmods.dev/skills/talissonvitorino/kmp-ios-skills/play-billing-upgrade"><img src="https://agentmods.dev/badge/skills/talissonvitorino/kmp-ios-skills/play-billing-upgrade/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/talissonvitorino/kmp-ios-skills/play-billing-upgrade"><img src="https://agentmods.dev/badge/skills/talissonvitorino/kmp-ios-skills/play-billing-upgrade.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00039 | $0.01314 |
| Opus 5 | $0.00019 | $0.00657 |
| Sonnet 5 | $0.00008 | $0.00263 |
| Haiku 4.5 | $0.00004 | $0.00131 |
Grade A, and why
play-billing-library-version-upgrade 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 12d 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.
This is a copy
94% identical to play-billing-library-version-upgrade — 2 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Phase 0: Intent Message
Reporting Action: Before proceeding, immediately tell the user: "I will upgrade Play Billing Library to the latest version."
Phase 1: Discovery & Situational Awareness
- Primary Check (Build Version) : Locate the project's billing dependency (e.g.,
com.android.billingclient:billing) inbuild.gradle,build.gradle.kts, orlibs.versions.toml. - Initial Compilation Test: Attempt to sync and build the project immediately.
- Fallback Discovery (Effective Version) :
- Trigger: Only if the build fails immediately, scan the source code for deprecated artifacts.
- Logic : The presence of deprecated APIs indicates the "Effective Version" ---defined as the version where those specific APIs were last available, not when they were introduced.
- Example : If
SkuDetailsis present, treat the baseline as PBL v7 or earlier (regardless of the version string inbuild.gradle).
- Identify Target & Path : Access the version tool or release notes to find the latest stable version and calculate a [Direct/Stepped] migration path based on the Effective Version baseline.
- Calculate Migration Path :
- If the Effective Version is within 2 major versions of the target: Plan a Direct Migration.
- If it is more than 2 major versions behind: Plan a Stepped Migration. Migrate by two major versions at a time (e.g., v4 -> v6 -> v8) until you are within two versions of the target.
- Reporting Action: Before proceeding, tell the user: "I've detected you are effectively on PBL [Current] and the latest is [Target]. I am planning a [direct/stepped] migration path."
Phase 2: Contextual Document Mapping & Planning
For every major version jump identified in your path, you MUST synthesize instructions from:
- Migration Guide (where
[X]is the target major version). - Release Highlights : The "Deprecations" and "Breaking Changes" sections of the relevant Release Notes.
- Developer Documentation: Consult your knowledge of the Google Play Billing documentation regarding the relevant features used in this app (e.g., Subscriptions, One-Time Products).
- Develop the Plan: Identify every specific code change required (API removals, class replacements, logic shifts) and print this out as a checklist.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 12d ago First seen · 94 lines · 39 tokens per session scan A 25ef263f4203
play-billing-library-version-upgrade is a skill published in the GitHub repository TalissonVitorino/kmp-ios-skills (12 stars, last pushed 18d ago), licensed MIT. It adds 39 tokens to every session and 1,314 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 94% identical to play-billing-library-version-upgrade, differing in 2 lines, and is treated as a copy.
Other skills, from other repositories
compose-multiplatform
Use when building one shared Compose UI in Kotlin across Android, iOS, and desktop — commonMain @Composables, expect/actual, source-set placement, native interop, multiplatform ViewModel/navigation/Koin. NOT a single-platform native build (that is kotlin-android / swift-ios), and NOT Dart/Flutter cross-platform UI…
cmp-new
Scaffold a new MOBILE app — Android + iOS from one Kotlin/Compose Multiplatform codebase — from a bare "create a mobile app" to a green, verified build. Guardrails first: if the user already chose a different framework (React Native, Expo, Flutter, SwiftUI, native), do NOT redirect them here; if they only asked a…
cmp-firebase-connect
Wire a freshly scaffolded CMP/KMP app to its OWN real Firebase project — the #1 post-scaffold manual step. Use this when the user wants to connect their app to Firebase, or asks "connect my app to firebase", "set up google-services.json", "wire firebase", "create a firebase project for this app", "replace the…
add-feature
Add a new conforming vertical-slice feature (Screen + ViewModel + UseCase + Repository + spec + tests + golden tree + nav route + DI wiring) to this Compose Multiplatform app, cloned deterministically from the project's configured exemplar feature (qa/approvals.json's exemplarFeature — home by default). Use this when…
cmp-audit
Adversarial audit of one subsystem of a Kotlin/Compose Multiplatform app against its spec AND against platform semantics — the class of defect desktop-tier tests cannot see (alarms, notifications, PendingIntents, reboot, process death, DST). Use this when the user says "audit the notifications", "double check X for…
add-screen
Add a presentation-only slice — Screen + ViewModel + tests + golden tree + spec + nav route — for an EXISTING entity/repository in this Compose Multiplatform app, cloned deterministically from the project's configured exemplar feature's presentation layer (qa/approvals.json's exemplarFeature — home by default).…