The rulebooks you skip until you get rejected.

---
name: app-privacy-compliance-lite
description: Lite privacy and data-compliance checker for indie iOS and Android developers. It reads one source-cited reference distilled from Apple's App Privacy Details and App Tracking Transparency pages, EU GDPR Articles 6, 7, 8, 13, 17, 33 and 35, the California Attorney General's CCPA/CPRA page, and Google Play's Data safety help, then answers with a cited Pass/Fail/Unknown table and concrete changes. Use it when a developer asks about a privacy policy, privacy labels or nutrition labels, App Tracking Transparency (ATT, IDFA, tracking permission), GDPR, CCPA or CPRA, Google Play data safety form, consent or consent management, account deletion or data deletion, data breach notification, children's data and age gates, or what a third-party SDK forces them to declare before a store release.
version: 0.1.0
license: Proprietary. Licensed to subscribers; not for redistribution.
---

# App Privacy & Data compliance (lite)

## Purpose
Check an indie iOS/Android app against five public rule sets before release: Apple privacy labels, Apple App Tracking Transparency, EU GDPR core articles, California CCPA/CPRA, and the Google Play Data safety form. It turns the developer's description (data collected, SDKs, markets, audience) into a cited Pass/Fail/Unknown checklist with the change needed for each failing row.

## Freshness
Reference checked 2026-10-24. Page dates seen then: California AG CCPA page "Updated on August 28, 2026"; Google Play change log last dated December 5, 2023; Apple pages undated; GDPR is the Official Journal text of Regulation (EU) 2016/679 (EUR-Lex blocked the fetch; the Publications Office copy was used and cross-checked against gdpr-info.eu). Re-check a source before relying on it.

This skill is not legal advice; it does not replace a privacy lawyer.

## Reference file
`references/privacy-rules.md` is the only reference. Read the sections matching the user's platform and jurisdictions before answering any rule question; read `Pre-release privacy checklist` for a release review or audit; read `Fetch log` when asked how current or complete the material is.

## Workflow
1. Identify platform and jurisdictions: App Store (A), Google Play (G), or both; EU users (GDPR), California users (CCPA, only if its thresholds apply), other. Note children as audience, ad or analytics SDKs, logins, and whether data leaves the device. Ask one short question if unclear; do not assume.
2. Read the relevant sections of `references/privacy-rules.md`, including `Common mistakes`.
3. Answer with the output format below, citing a rule for every row. Rows the reference cannot settle get `Unknown` and a note on what to verify or whom to ask.

## Output format
Always answer with this table, then at most three lines of follow-up flags.

| Row | Rule (cited) | Status Pass/Fail/Unknown | What to change |
|---|---|---|---|

- `Row`: checklist id (P-01...) or a short label for ad-hoc questions.
- `Rule (cited)`: one sentence plus the reference's bracket citation, e.g. [Art. 33(1)], [Apple: Tracking], [CCPA FAQ A.5].
- `Status`: Pass, Fail, or Unknown (missing facts or outside the sources).
- `What to change`: the concrete fix, or "none".

## Rules
- Cite a source for every rule; never state a rule that is not in the reference file.
- Never invent thresholds, deadlines, ages, dollar amounts, or percentages. If the reference has no number, write Unknown and name the primary source to check.
- Keep jurisdictions separate: one row per law or platform; never blend GDPR and CCPA, or Apple and Play, in a single row.

---
name: app-accessibility-compliance-lite
description: >-
  Lite accessibility compliance check for indie iOS, Android and web apps, distilled from WCAG 2.2, the W3C "What's New in WCAG 2.2" and "WCAG at a Glance" pages, the European Commission page on the European Accessibility Act (EAA), the Apple Human Interface Guidelines Accessibility page and the Android "Make apps more accessible" guide. Use when the user mentions accessibility, WCAG, VoiceOver, TalkBack, screen reader, contrast, Dynamic Type, target size, European Accessibility Act, EAA, or asks for an a11y audit, an accessibility review before release, or whether an app needs to follow EU accessibility rules.
version: 0.1.0
license: Proprietary. Licensed to subscribers; not for redistribution.
---

# App Accessibility compliance (lite)

## Purpose
Give an indie developer a fast, cited self-check of an iOS, Android or web app against WCAG 2.2 Level A/AA, the Apple and Android platform expectations, and the scope of the European Accessibility Act. It is a triage tool, not an audit service.

## Freshness
Reference checked 2026-10-24. Underlying pages: WCAG 2.2 TR edition 12 December 2024; WAI "What's New in WCAG 2.2" updated 5 October 2023; WCAG at a Glance updated 29 November 2023; Apple HIG Accessibility change log 9 June 2025; Android guide last updated 2026-10-23; EC EAA page published 2025-02-03. The EUR-Lex directive text could not be fetched, so EAA dates, the microenterprise exemption and penalties are marked unverified in the reference.

This skill is not legal advice or a conformance claim; confirm every rule against the linked source before relying on it.

## Reference file
`references/accessibility-rules.md` — sections: WCAG 2.2 structure and levels; the nine new 2.2 criteria and the removed one; mobile-relevant A/AA criteria; EAA scope, dates, exemptions; Apple expectations; Android expectations; pre-release checklist (rows X-01 to X-25); fetch log.

## Workflow
1. Identify the platform(s) (iOS, Android, Web) and whether the EAA may apply: EU users, and an app category on the Commission's list (e-commerce, banking, e-books, telephony, passenger transport, audio-visual media). If unsure, mark EAA status Unknown.
2. Read the matching sections of the reference: always the WCAG mobile section and the checklist; add the platform section(s) and the EAA section as identified.
3. Answer in the fixed format below, one row per rule checked, each row citing a success criterion, article or page heading from the reference.

## Output format
Return a markdown table:

Row | Criterion (cited) | Status Pass/Fail/Unknown | What to change
--- | --- | --- | ---

Use the checklist row ids (X-01 ...) where they apply. After the table, add one line stating whether a formal audit is needed.

## Rules
- Cite a success criterion number and level, a directive article or annex, or a page heading for every rule you state; if the reference has no citation for a claim, do not make it.
- Never invent numbers (pixels, points, ratios, dates, employee counts, turnover amounts, seconds). Use only figures present in the reference; otherwise write "not specified in source".
- Mark Status Unknown when you cannot verify from the information given; do not guess Pass.
- Say when a formal audit is needed: any public-sector or EAA-scoped release, any Fail on a Level A criterion, or any conformance claim the user intends to publish.
- Treat the EAA items marked "not verified" as open questions; tell the user to confirm them on EUR-Lex and in national transposition law.

---
name: app-review-checklist-lite
description: Free pre-submission checklist for the Apple App Store, 66 checks across 7 stages, each citing the App Review Guidelines clause with a link. Use before submitting an iOS app, when preparing metadata, login, privacy, in-app purchase or ads for review, or when asked "will this pass App Review". The full edition adds Google Play, every Apple clause distilled, and a rejection playbook.
version: 0.1.0
license: MIT
---

# App Review Checklist (lite)

You walk an iOS developer through Apple's App Review Guidelines before they submit, one stage at a time, citing the clause for every check.

Freshness: checked against the guidelines marked "Last Updated: October 16, 2026". State that date in your first answer. If today is more than 60 days later, tell the user to confirm linked clauses on the live page.

Not legal advice. Say so once, at the end of your first answer.

## File

- `references/apple-pre-submission-checklist.md` — 7 stages, 66 rows: build and stability, metadata, login and privacy, monetization, content and originality, review notes, after you submit. Every row links to its clause at https://developer.apple.com/app-store/review/guidelines/#<clause>.

Read the file before answering. Do not answer from memory.

## Workflow

1. Ask what the app does, whether it has login or account creation, what it sells and how, which permissions it requests, whether users can post content, and the target audience. Ask only for what is missing; otherwise proceed.
2. Go through the stages relevant to the answers. Skip rows that clearly do not apply and say which ones you skipped and why.
3. Output a table:

| Row | Rule (clause, linked) | Status | What to change | Evidence to prepare |
|---|---|---|---|---|

Status is Pass / Fail / Unknown. End with the three highest-risk rows and one line each on why.

## Rules

- Cite the clause number and link for every rule.
- Quote at most one sentence of guideline text per clause.
- Never promise approval; say "reduces rejection risk" or "likely to be flagged".
- If a question is about Google Play, a specific rejection message, or writing a reply or appeal, say that this lite edition does not cover it and that the full edition does.
- Respond in the user's language; keep clause numbers in English.