Android 应用提交 Google Play…

对 Android 应用进行 Google Play 政策预提交审计，交叉核对静态代码分析与 Play Store 声明，生成确定性合规报告。

适用场景

解决思路

1. 审计范围为三个政策域：Permissions and APIs Hygiene、User Account and Identity、Data Safety and Privacy；必须检查 data safety、demo login credentials 和 restricted permissions，识别未声明数据收集、架构风险和缺失披露。
2. 解析并确定路径：repo_root 为包含本 SKILL.md 的目录绝对路径；app_dir 为包含应用代码的目录绝对路径；temp_dir 为工作区根目录下的临时目录，位于 .scratch/play_policy_insights_<uuid>。
3. 遵守 Containment Mandate：所有文件系统写入、中间产物和日志必须严格限制在 temp_dir 内；避免依赖系统级临时路径或用户主目录，以保证技能在本地执行器与 CI/CD 等多样环境中可移植且安全。
4. 在进入 Phase 2 前评估执行环境是否提供将任务派生或委托给通用子智能体的工具，例如通常名为 invoke_agent、delegate_task、spawn_worker，使用 generalist 或 coding_agent 等通用 agent profile。
5. 如果环境支持委托，则必须使用 Mode A（Delegation）。
6. 如果环境不支持委托，则使用 Mode B（Sequential Self-Execution）：你必须自行读取原本给子智能体的 prompt 文件，遵循其中指令，并将预期输出文件写入磁盘。
7. Mode A 下进行子智能体编排时，等待子智能体返回 “SUCCESS” 确认，以判断其已完成。
8. 遵守幂等与超时保护：如果子智能体失败或超时，在重试前必须先验证其目标输出文件是否存在且完整，例如 <temp_dir>/worker_<goal_name>.json；如果文件存在且包含有效 JSON，则视为 SUCCESS 并继续；否则最多重试三次。
9. 遵守 fail-fast 强制要求：Phase 1 的自动化审计是事实来源；如果 orchestrator.py 失败，必须立即停止并解释失败原因；不要用人工审计作为兜底。
10. Phase 1 第 1 步：初始化与分诊，运行 python3 <repo_root>/scripts/orchestrator.py init <app_dir>。
11. 该命令会创建临时环境、执行静态分析、映射代码库、识别审计目标，并为每个审计目标生成给子智能体的 prompt，以及为指定的 critic 和 aggregator 子智能体生成 prompt。
12. 必须等待该脚本完成，最长等待 5 分钟。
13. Phase 1 第 2 步：捕获环境，从 JSON 输出中记录 temp_dir 和 activated_goals 的值，Phase 2 会用到。
14. Phase 1 第 3 步：评估目标；如果 activated_goals 为空，跳到 Phase 2 的第 3 步（Aggregation）；否则继续 Phase 2 的第 1 步（Detailed analysis）。
15. Phase 2 开始：根据执行能力选择 Mode A 或 Mode B。
16. Mode A 第 1 步：对 activated_goals 中的每个目标，例如 permissions_and_apis、data_safety_part_1、data_safety_part_2，委托给子智能体。
17. Mode A 并发限制：不得同时启动超过 3 个子智能体；先启动最多 3 个为一批，等待其完成，再启动下一批，重复直到所有目标完成。
18. Mode A 传给子智能体的 prompt 内容：从 <temp_dir>/prompt_worker_<goal_name>.md 读取你的指令并执行。强制要求：必须使用写文件能力将最终 JSON 发现直接保存到文件系统 <temp_dir>/worker_<goal_name>.json。严禁在聊天响应中输出该 JSON。为减少上下文占用，最终响应必须恰好是 “SUCCESS”，不能有其他内容。
19. Mode A 验证：确认每个 <temp_dir>/worker_<goal_name>.json 都存在且包含有效 JSON；如果子智能体失败或超时，但有效 JSON 输出文件已在磁盘上，则不要重试，正常继续；只有文件缺失或无效时，才重试对应 worker，最多三次。
20. Mode A 第 2 步：聚合发现，执行 python3 <repo_root>/scripts/orchestrator.py aggregate <temp_dir>。
21. 这将生成 aggregated_findings.json，并返回包含 critic_chunks 的 JSON 对象，表示要验证的 chunk 数量，例如 temp_dir 与 critic_chunks 为 2。
22. Mode A 第 3 步：并行 critic 审查，对每个 chunk 索引 i，从 1 到 critic_chunks，委托给子智能体。
23. Mode A critic 并发限制：不得同时启动超过 3 个 critic 子智能体；像上面一样按每批 3 个分批执行。
24. Mode A 传给 critic 子智能体的 prompt 内容：从 <temp_dir>/prompt_critic_<i>.md 读取你的指令并执行。强制要求：必须使用写文件能力将最终 JSON 发现直接保存到文件系统 <temp_dir>/critic_output_<i>.json。严禁在聊天响应中输出该 JSON。为减少上下文占用，最终响应必须恰好是 “SUCCESS”，不能有其他内容。
25. Mode A critic 验证：在继续前确认每个 <temp_dir>/critic_output_<i>.json 都存在且包含有效 JSON；如果失败或超时，但有效 JSON 文件存在，则正常继续；否则重试该特定 critic chunk。
26. Mode A 第 4 步：进入 Finalization，即下面的第 4 步。
27. Mode B 第 1 步：对 activated_goals 中的每个目标，按顺序执行：读取 <temp_dir>/prompt_worker_<goal_name>.md 的内容；自己执行其中指令；必须按 prompt 要求精确格式化发现，并保存到 <temp_dir>/worker_<goal_name>.json；不要在思考或聊天中总结发现，直接进入下一任务；验证 <temp_dir>/worker_<goal_name>.json 存在后再移到下一个目标。
28. Mode B 第 2 步：聚合发现，执行 python3 <repo_root>/scripts/orchestrator.py --aggregate <temp_dir>。
29. 这将生成 aggregated_findings.json，并返回包含 critic_chunks 的 JSON 对象，表示要验证的 chunk 数量。
30. Mode B 第 3 步：顺序 critic 审查，对每个 chunk 索引 i，从 1 到 critic_chunks，按顺序执行：读取 <temp_dir>/prompt_critic_<i>.md 的内容；自己执行步骤，并保存发现到 <temp_dir>/critic_output_<i>.json；验证 <temp_dir>/critic_output_<i>.json 存在后再移到下一个 chunk。
31. Mode B 第 4 步：进入 Finalization，即下面的第 4 步。
32. Finalization 第 4 步：呈现发现，运行 python3 <repo_root>/scripts/generate_report.py <temp_dir>；它会生成 <temp_dir>/compliance_report.md；将此输出文件呈现给用户。
33. 第 5 步：STOP，审计完成，等待进一步指令。

适用边界 · 注意事项

• 不适用于非 Android 应用，或无需对照 Google Play 政策与 Play Store 声明进行审计的场景。
• 不适用于无法运行本技能仓库中 scripts/orchestrator.py、generate_report.py 等脚本的环境；并且 orchestrator.py 失败时不能改用手工审计兜底。
• 不适用于无法将中间产物和日志严格限制在 temp_dir 内执行的场景。