# Skill: Produce a complete, honest privacy declaration (policy + App Privacy + Data Safety) that clears review

> Enables an AI coding/design agent to audit every data-collection point in an app — including third-party SDKs — then produce a matching privacy policy page, Apple App Privacy questionnaire answers, and Google Data Safety form answers that are internally consistent and will pass store review on the first try.

Source: sodigi·learn — publish/privatnost-i-dannye · https://sodigi.io/learn/publish/privatnost-i-dannye

## When to use
- Any app is being prepared for submission to the App Store or Google Play.
- A submission was rejected for a privacy policy issue, a missing Data Safety form, or an App Privacy mismatch.
- The developer added a new SDK (analytics, ads, crash reporting) and needs to update their privacy declarations.
- The developer believes the app "collects nothing" and wants to confirm whether a declaration is still required (it always is).

## Core rules
- EVERY app needs a privacy policy link — even an offline utility with zero data collection. The policy page must be public, require no login, and be hosted at a stable permanent URL.
- Apple's App Privacy and Google's Data Safety are questionnaires, not optional fields — every developer fills them out; silence is read as "hiding something."
- Declare exactly what the app does — no more, no less. Overstating collection scares users; understating it causes rejection.
- Third-party SDKs (analytics, ads, crash reporters, push notification services) collect data on the developer's behalf — the developer is responsible for declaring that collection in both questionnaires, even if they did not write the SDK.
- All three documents must be consistent: the privacy policy, the App Privacy answers, and the Data Safety answers must describe the same reality. Mismatches are caught and rejected.
- Zero data collection is a valid and strong answer — but it must be declared explicitly, not left blank.
- The policy link must work in incognito mode (no login) — the review automation cannot authenticate.
- Update all three documents whenever the code changes add or remove data collection (e.g., adding an analytics SDK in a future update).

## Procedure
1. Open the project and list every library, SDK, and dependency (package.json, build.gradle, Podfile, pubspec.yaml, etc.).
2. For each SDK, check its official documentation or privacy disclosure to determine what data it collects, what it shares with third parties, and whether that collection can be disabled.
3. Combine your own code's data collection with every SDK's collection. This is your complete, honest data inventory.
4. Write (or regenerate) the privacy policy page. State: what data is collected, the purpose of each collection, whether data is shared with third parties and with whom, how users can request deletion, and a contact address. Host it at a stable public URL (a Notion page, GitHub Pages, or a policy generator page all work).
5. Verify the URL opens in an incognito browser window with no login prompt. If it does not open, the review bot will not see it.
6. In App Store Connect, fill out the App Privacy questionnaire: for each data category, mark whether you collect it, the purpose (analytics, functionality, advertising), whether it is linked to user identity, and whether it is used for tracking.
7. In Google Play Console, fill out the Data Safety form: for each data type, declare collection, sharing, purpose, whether it is required or optional, encryption in transit, and whether users can request deletion.
8. Cross-check all three documents against each other. Every data type declared in the policy must appear in both questionnaires, and vice versa.
9. Paste the privacy policy URL into both App Store Connect and the Play Console Data Safety form.

## Ready-to-use prompt
```
Perform a full privacy audit of my app and produce all required privacy declarations.

Step 1 — Data inventory:
List every library and SDK in this project. For each one, identify what user data it collects or shares with third parties (check its official docs). Combine this with any data my own code collects. Output a complete data inventory table: data type | collected by | purpose | shared with | can user opt out.

Step 2 — Privacy policy:
Write a privacy policy in plain English based on the inventory above. Include: what is collected, why, who it is shared with, how users can request deletion, and a contact address. If nothing is collected, state that clearly.

Step 3 — Apple App Privacy answers:
Using the inventory, produce the answers for Apple's App Privacy questionnaire in App Store Connect. For each data category: collected (yes/no), purpose, linked to identity (yes/no), used for tracking (yes/no).

Step 4 — Google Data Safety answers:
Using the inventory, produce the answers for Google's Data Safety form in Play Console. For each data type: collected (yes/no), shared (yes/no), purpose, required or optional, encrypted in transit (yes/no), user can request deletion (yes/no).

Step 5 — Consistency check:
Confirm all three documents describe the same reality. Flag any mismatch.

Flag any SDK whose privacy documentation I should read manually before finalizing the declaration.
```

## Pitfalls
- Empty policy link field — the single most common privacy rejection; always fill it in before the first submission.
- Policy URL that requires a login — the review bot cannot authenticate; host the page publicly with no login gate.
- Skipping the questionnaires because "nothing gets collected" — zero collection still must be declared; a blank field is read as evasion.
- Forgetting third-party SDKs — an analytics or ad SDK that pulls device identifiers is the developer's data collection, not the SDK vendor's; it must appear in both the policy and the questionnaires.
- Policy says one thing, questionnaire says another — stores detect mismatches; all three documents must be consistent.
- Not updating declarations after adding a new SDK — a new crash reporter or ad network in a future update requires a fresh pass through all three documents.