How to use the Play Policy Insights agent skill

What is an agent skill, and what does this one make the agent do?

An agent skill is a folder with a SKILL.md file and supporting resources that an AI agent reads when a request matches the skill's description. Once it is installed, the agent follows the skill's instructions instead of improvising the procedure.

This skill makes the agent audit an Android app in two phases. First, a bundled Python orchestrator performs static analysis of the app's code and identifies which audit goals apply. Then the agent, or sub-agents if the runtime supports delegation, reviews the findings and writes a structured compliance report. The source describes the output as a deterministic report that cross-references code analysis with the app's Play Store declarations.

• Data safety: looks for undeclared data collection and discrepancies between detected behaviour and the Data Safety label.
• Demo login credentials: checks whether the app's login is covered for review.
• Restricted permissions and APIs: flags permission and API usage that Google Play restricts.

How do you install the Play Policy Insights skill?

There are two ways to install the skill. Download the ZIP for play-policy-insights from the directory page, then choose the option that matches how you run your agent.

For a personal Claude Code setup, unzip the download into ~/.claude/skills/ so that the skill folder sits there. For a single project, unzip it into the project's .claude/skills/ folder instead. In the Claude apps, you can upload the ZIP under Settings → Capabilities → Skills.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project
• Claude apps: Settings → Capabilities → Skills, then upload the ZIP

How do you trigger the skill with a natural request?

You do not need a special command. Describe the task in plain language and name the app's code location so the agent knows what to audit. The skill's description covers Android apps, Google Play policy, data safety, and pre-submission checks, so requests using those ideas should match it.

Be specific about the goal. A request that names the three policy areas, or asks for a check before you submit, is clearer than a general request to review the app.

• "Run a Play policy pre-submission check on this Android app."
• "Check whether my data safety declarations match what the code collects."
• "Audit this app for restricted permissions and missing disclosures before I submit to Google Play."
• "Check the demo login credentials in this app against the Play policy."

What does the skill need before it runs?

The skill needs Python 3 on the machine, network access so it can fetch Play Store listing pages for the named package, and an agent runtime that can run shell commands and write files. It runs scripts and uses the network, so review those points before installing.

The skill is designed to keep its work in a scratch folder at the workspace root, under .scratch/play_policy_insights_<uuid>, rather than in system temporary paths or your home directory. Its output is a compliance report written into that workspace.

• Python 3
• Network access to fetch Play Store listing pages
• An agent runtime that can run shell commands and write files

What are the safety notes for scripts and network use?

The skill runs bundled Python scripts in its scripts folder, including orchestrator.py, scanner.py, play_store_scraper.py, generate_report.py and template_engine.py. It reads the app's source code and requests public Play Store data for the package you name. Only point it at apps you own or are authorised to analyse.

The skill's own rules say that if the orchestrator fails, the agent must stop and explain the failure rather than fall back to manual auditing. The report also states that it is advisory and does not replace legal review or Google's own review.

• Scripts are included in the download: review them if your environment requires it.
• Network calls fetch public Play Store listing pages for the named package.
• Only analyse apps you own or have permission to analyse.

What does a typical run look like?

The first step is an initialisation run of the orchestrator against your app folder. It creates the scratch environment, performs static analysis, maps the codebase and writes prompts for each audit goal. The agent then works through the activated goals, aggregates findings, and has a critic pass check them for false positives.

If no goals are activated, the run skips to aggregation. The final report uses a template with a status line, policy risks and recommendations, and a data safety discrepancy table.

Tips for getting useful results

Point the agent at the app's root directory so the scanner finds the Android manifest and Gradle files. The scanning logic targets those files, so the skill is not suited to non-Android projects.

Treat the report as a checklist, not a verdict. Use it to decide what to fix or confirm before submission, and check any flagged item against your own Data Safety form and your privacy policy.

• Use the same checklist each time to get a repeatable comparison across releases.
• Re-run the audit after adding SDKs or new features, since new code may not yet be reflected in your Data Safety label.
• Keep the scratch folder out of version control if you do not want reports committed.