play-billing-library-version-upgrade

Name: play-billing-library-version-upgrade
Author: hanamizuki

104stars8forks

How to install play-billing-library-version-upgrade?

hanamizuki/solopreneur/play-billing-library-version-upgrade

$npx -y skills add hanamizuki/solopreneur --skill play-billing-library-version-upgrade

Installs into the current project.

Summary

Use this skill when upgrading or migrating an Android project from any

Files · 1

View on GitHub

SKILL.md

1	## Phase 0: Intent Message
2
3	Reporting Action: Before proceeding, immediately tell the user: "I will
4	upgrade Play Billing Library to the latest version."
5
6	## Phase 1: Discovery \& Situational Awareness
7
8	1. Primary Check (Build Version) : Locate the project's billing dependency (e.g., `com.android.billingclient:billing`) in `build.gradle`, `build.gradle.kts`, or `libs.versions.toml`.
9	2. Initial Compilation Test: Attempt to sync and build the project immediately.
10	3. Fallback Discovery (Effective Version) :
11	- Trigger: Only if the build fails immediately, scan the source code for deprecated artifacts.
12	- Logic : The presence of deprecated APIs indicates the **"Effective
13	Version" ---defined as the version where those specific APIs were last
14	available**, not when they were introduced.
15	- Example : If `SkuDetails` is present, treat the baseline as PBL v7 or earlier (regardless of the version string in `build.gradle`).
16	4. 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.
17
18	- Calculate Migration Path :
19	- If the Effective Version is within 2 major versions of the target: Plan a Direct Migration.
20	- If it is more than 2 major versions behind: Plan a **Stepped
21	Migration**. Migrate by two major versions at a time (e.g., v4 -\> v6 -\> v8) until you are within two versions of the target.
22	- 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."
23
24	## Phase 2: Contextual Document Mapping \& Planning
25
26	For every major version jump identified in your path, you MUST synthesize
27	instructions from:
28
29	- [Migration Guide](https://developer.android.com/google/play/billing/migrate-gpblv%5BX%5D) (where `[X]` is the target major version).
30	- Release Highlights : The "Deprecations" and "Breaking Changes" sections of the relevant [Release Notes](references/android/google/play/billing/release-notes.md).
31	- 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).
32	- Develop the Plan: Identify every specific code change required (API removals, class replacements, logic shifts) and print this out as a checklist.
33
34	## Phase 3: Instructions for Execution
35
36	*Reporting Action: For each of the following steps, give a brief explanation of
37	what you will be doing prior to execution, and a brief summary of what you
38	accomplished afterwards.*
39
40	### Step 1: SDK \& Environment Alignment
41
42	- Action : Update `build.gradle` to meet SDK requirements (e.g., "PBL 9 requires `compileSdk` 35").
43	- Gradle Version: Verify if the new library requires a newer Android Gradle Plugin (AGP) or Kotlin version.
44
45	### Step 2: Intent-based Refactoring
46
47	Analyze the intent of the existing code rather than performing purely textual
48	string replacement.
49
50	- Action : You MUST follow all deprecation instructions and refactor patterns from both the [references/migration-logic.md](references/migration-logic.md) section, the official migration guides, and the general documentation pages identified in Phase 2.
51	- Verification : Verify you are doing all steps from all documentation and then making sure you follow the specific directions from the checklist in the references.
52
53	### Step 3: Sequential Verification (Only applicable for Stepped Migrations)
54
55	1. Upgrade to the first major intermediate version in your path.
56	2. Run `./gradlew assembleDebug` to verify no intermediate breaking changes were missed.
57	3. Repeat until you reach the final target version.
58
59	### Step 4: Final Validation Checklist
60
61	1. Smart Checklist Verification:
62	2. Open [references/version-checklist.md](references/version-checklist.md) and locate the Smart Version-Specific Checklist.
63	3. Action: For every version between your \[Detected Effective Version\] and \[Detected New Version\], verify that every item has been addressed in the code using "Find in Files" or structural analysis.
64	4. Tests : Run all unit and implementation tests (`./gradlew test`).
65	5. Clean Build : Verify the project completes a full clean build: `./gradlew clean assembleDebug`. Then, run `./gradlew sync` and `./gradlew build` so that the user can immediately test the ne

People who liked this also viewed

6 picks

Type

find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 20262.6M27k
grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026633k182k
vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026573k29k
improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026522k182k
setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026454k182k
triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026424k182k

play-billing-library-version-upgrade

104stars8forks

View on GitHub

How to install play-billing-library-version-upgrade?

hanamizuki/solopreneur/play-billing-library-version-upgrade

$npx -y skills add hanamizuki/solopreneur --skill play-billing-library-version-upgrade

Installs into the current project.

Summary

Use this skill when upgrading or migrating an Android project from any

Files · 1

View on GitHub

SKILL.md

1	## Phase 0: Intent Message
2
3	Reporting Action: Before proceeding, immediately tell the user: "I will
4	upgrade Play Billing Library to the latest version."
5
6	## Phase 1: Discovery \& Situational Awareness
7
8	1. Primary Check (Build Version) : Locate the project's billing dependency (e.g., `com.android.billingclient:billing`) in `build.gradle`, `build.gradle.kts`, or `libs.versions.toml`.
9	2. Initial Compilation Test: Attempt to sync and build the project immediately.
10	3. Fallback Discovery (Effective Version) :
11	- Trigger: Only if the build fails immediately, scan the source code for deprecated artifacts.
12	- Logic : The presence of deprecated APIs indicates the **"Effective
13	Version" ---defined as the version where those specific APIs were last
14	available**, not when they were introduced.
15	- Example : If `SkuDetails` is present, treat the baseline as PBL v7 or earlier (regardless of the version string in `build.gradle`).
16	4. 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.
17
18	- Calculate Migration Path :
19	- If the Effective Version is within 2 major versions of the target: Plan a Direct Migration.
20	- If it is more than 2 major versions behind: Plan a **Stepped
21	Migration**. Migrate by two major versions at a time (e.g., v4 -\> v6 -\> v8) until you are within two versions of the target.
22	- 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."
23
24	## Phase 2: Contextual Document Mapping \& Planning
25
26	For every major version jump identified in your path, you MUST synthesize
27	instructions from:
28
29	- [Migration Guide](https://developer.android.com/google/play/billing/migrate-gpblv%5BX%5D) (where `[X]` is the target major version).
30	- Release Highlights : The "Deprecations" and "Breaking Changes" sections of the relevant [Release Notes](references/android/google/play/billing/release-notes.md).
31	- 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).
32	- Develop the Plan: Identify every specific code change required (API removals, class replacements, logic shifts) and print this out as a checklist.
33
34	## Phase 3: Instructions for Execution
35
36	*Reporting Action: For each of the following steps, give a brief explanation of
37	what you will be doing prior to execution, and a brief summary of what you
38	accomplished afterwards.*
39
40	### Step 1: SDK \& Environment Alignment
41
42	- Action : Update `build.gradle` to meet SDK requirements (e.g., "PBL 9 requires `compileSdk` 35").
43	- Gradle Version: Verify if the new library requires a newer Android Gradle Plugin (AGP) or Kotlin version.
44
45	### Step 2: Intent-based Refactoring
46
47	Analyze the intent of the existing code rather than performing purely textual
48	string replacement.
49
50	- Action : You MUST follow all deprecation instructions and refactor patterns from both the [references/migration-logic.md](references/migration-logic.md) section, the official migration guides, and the general documentation pages identified in Phase 2.
51	- Verification : Verify you are doing all steps from all documentation and then making sure you follow the specific directions from the checklist in the references.
52
53	### Step 3: Sequential Verification (Only applicable for Stepped Migrations)
54
55	1. Upgrade to the first major intermediate version in your path.
56	2. Run `./gradlew assembleDebug` to verify no intermediate breaking changes were missed.
57	3. Repeat until you reach the final target version.
58
59	### Step 4: Final Validation Checklist
60
61	1. Smart Checklist Verification:
62	2. Open [references/version-checklist.md](references/version-checklist.md) and locate the Smart Version-Specific Checklist.
63	3. Action: For every version between your \[Detected Effective Version\] and \[Detected New Version\], verify that every item has been addressed in the code using "Find in Files" or structural analysis.
64	4. Tests : Run all unit and implementation tests (`./gradlew test`).
65	5. Clean Build : Verify the project completes a full clean build: `./gradlew clean assembleDebug`. Then, run `./gradlew sync` and `./gradlew build` so that the user can immediately test the ne

People who liked this also viewed

6 picks

Type