android-app-factory

Name: android-app-factory
Author: JasonColapietro

44stars8forks

How to install android-app-factory?

jasoncolapietro/suede-creator-skills/android-app-factory

$npx -y skills add JasonColapietro/suede-creator-skills --skill android-app-factory

Installs into the current project.

Summary

Plan, build, test, and release a production-grade native Android app from a product idea through Google Play. Use for requests to create, ship, submit, monetize, or modernize an Android app. Covers Kotlin and Jetpack Compose architecture, API-level policy verification, accessibil

Files · 1

View on GitHub

SKILL.md

1	# Android App Factory
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	## Principle
25
26	Build the product, policy evidence, and Play listing together. A successful
27	release is an installable and usable app whose claims, disclosures,
28	entitlements, privacy behavior, and store configuration agree.
29
30	## Source Truth and Freshness
31
32	At the start of every release-oriented run:
33
34	1. Identify the exact repo, package/application ID, branch, Play app, target
35	track, and whether the checkout is dirty.
36	2. Read `references/play-policy-baseline.md`.
37	3. Re-open the linked official Google sources for any submission-sensitive
38	requirement. Record the URL, observed requirement, and check time in
39	`assets/android-release-gate.template.md`.
40	4. Treat current repo code and the live Play Console as source truth for the
41	app. Treat the reference date as a baseline, not permanent policy.
42
43	On 2026-07-19, the factory default for a general phone/tablet release is
44	`compileSdk = 36` and `targetSdk = 36`. Google Play's announced enforcement for
45	new apps and updates moves to API 36 on 2026-08-31; API 35 remains the enforced
46	minimum before that date. Do not misstate the announced deadline as already
47	enforced, and recheck because form-factor exceptions and dates differ.
48
49	## Delivery Contract
50
51	Lock these before implementation:
52
53	- user and one core outcome;
54	- supported form factors, devices, locales, minimum SDK, and offline behavior;
55	- application ID, ownership, signing model, Play app/track, and release owner;
56	- data inventory, third-party SDKs, permissions, account model, deletion path,
57	privacy policy owner, and Data Safety owner;
58	- monetization and entitlement source truth, or an explicit free-v1 decision;
59	- architecture and migration constraints;
60	- acceptance devices/API levels, tests, performance/accessibility targets,
61	store artifacts, and release evidence;
62	- external mutations requiring confirmation: product creation, credential use,
63	Play upload, track promotion, staged rollout, or production release.
64
65	Unknowns stay unknown. Never invent a package name, product ID, policy answer,
66	privacy URL, customer claim, or Play Console state.
67
68	## Production Pipeline
69
70	1. Validate the product — define the user outcome and evidence of demand.
71	Treat keyword research as one input, not proof of product-market fit.
72	2. Verify policy — capture current target-SDK and form-factor rules, app
73	access requirements, Data Safety scope, content rating, account deletion,
74	billing policy, and any permission-specific declarations.
75	3. Design architecture and risk — use the smallest maintainable architecture
76	that preserves unidirectional state, lifecycle safety, offline/error/loading
77	states, test seams, and a least-data/least-permission posture.
78	4. Scaffold — native Kotlin + Jetpack Compose by default. Resolve current
79	stable Android/Jetpack versions from official sources, lock them in a version
80	catalog, and prove a debug build before feature work.
81	5. Build the core loop — implement one complete user outcome with real or
82	deterministic demo data. Add history, saved state, sync, or accounts only
83	when the product contract requires them.
84	6. Prove quality — unit, repository, ViewModel, Compose UI/instrumented,
85	accessibility, and end-to-end core-loop tests as applicable; static analysis,
86	release build, device/API matrix, baselin

People who liked this also viewed

6 picks

Type

android-app-factory

44stars8forks

View on GitHub

How to install android-app-factory?

jasoncolapietro/suede-creator-skills/android-app-factory

$npx -y skills add JasonColapietro/suede-creator-skills --skill android-app-factory

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Android App Factory
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	## Principle
25
26	Build the product, policy evidence, and Play listing together. A successful
27	release is an installable and usable app whose claims, disclosures,
28	entitlements, privacy behavior, and store configuration agree.
29
30	## Source Truth and Freshness
31
32	At the start of every release-oriented run:
33
34	1. Identify the exact repo, package/application ID, branch, Play app, target
35	track, and whether the checkout is dirty.
36	2. Read `references/play-policy-baseline.md`.
37	3. Re-open the linked official Google sources for any submission-sensitive
38	requirement. Record the URL, observed requirement, and check time in
39	`assets/android-release-gate.template.md`.
40	4. Treat current repo code and the live Play Console as source truth for the
41	app. Treat the reference date as a baseline, not permanent policy.
42
43	On 2026-07-19, the factory default for a general phone/tablet release is
44	`compileSdk = 36` and `targetSdk = 36`. Google Play's announced enforcement for
45	new apps and updates moves to API 36 on 2026-08-31; API 35 remains the enforced
46	minimum before that date. Do not misstate the announced deadline as already
47	enforced, and recheck because form-factor exceptions and dates differ.
48
49	## Delivery Contract
50
51	Lock these before implementation:
52
53	- user and one core outcome;
54	- supported form factors, devices, locales, minimum SDK, and offline behavior;
55	- application ID, ownership, signing model, Play app/track, and release owner;
56	- data inventory, third-party SDKs, permissions, account model, deletion path,
57	privacy policy owner, and Data Safety owner;
58	- monetization and entitlement source truth, or an explicit free-v1 decision;
59	- architecture and migration constraints;
60	- acceptance devices/API levels, tests, performance/accessibility targets,
61	store artifacts, and release evidence;
62	- external mutations requiring confirmation: product creation, credential use,
63	Play upload, track promotion, staged rollout, or production release.
64
65	Unknowns stay unknown. Never invent a package name, product ID, policy answer,
66	privacy URL, customer claim, or Play Console state.
67
68	## Production Pipeline
69
70	1. Validate the product — define the user outcome and evidence of demand.
71	Treat keyword research as one input, not proof of product-market fit.
72	2. Verify policy — capture current target-SDK and form-factor rules, app
73	access requirements, Data Safety scope, content rating, account deletion,
74	billing policy, and any permission-specific declarations.
75	3. Design architecture and risk — use the smallest maintainable architecture
76	that preserves unidirectional state, lifecycle safety, offline/error/loading
77	states, test seams, and a least-data/least-permission posture.
78	4. Scaffold — native Kotlin + Jetpack Compose by default. Resolve current
79	stable Android/Jetpack versions from official sources, lock them in a version
80	catalog, and prove a debug build before feature work.
81	5. Build the core loop — implement one complete user outcome with real or
82	deterministic demo data. Add history, saved state, sync, or accounts only
83	when the product contract requires them.
84	6. Prove quality — unit, repository, ViewModel, Compose UI/instrumented,
85	accessibility, and end-to-end core-loop tests as applicable; static analysis,
86	release build, device/API matrix, baselin

People who liked this also viewed

6 picks

Type