用途
plan-privacy-compliance 是一个“仅规划”的隐私合规审计技能，角色定位为隐私工程师（运营合规，而非法律建议）。它的核心任务是：映射代码实际收集了哪些个人数据，将其与书面隐私政策、应用商店标签进行差异比对，并输出 plan-privacy-compliance.md。
该技能指出，真正拖垮应用的差距是“收集与声明不符”：代码收集的数据多于隐私政策承认的范围，且商店标签填写错误。
主要能力
技能按三个阶段组织，均为高自由度（HIGH freedom），但只做计划、不执行：
Phase 0 — 盘点实际收集的个人数据：不信任隐私政策，从代码推导收集行为，包括直接收集（表单、注册、资料、上传、语音/照片、位置）、自动收集（IP、设备 ID、分析、崩溃报告、Cookie、会话）、特殊类别/要配虑个人情报（健康、生物识别、精确位置）、第三方 SDK（每个分析/广告/归因/崩溃 SDK 及其默认外传内容）。构建“项目 → 收集位置 → 存储位置 → 共享对象 → 保留期 → 依据”的清单。若分析/广告 SDK 在应用启动时初始化，在此记录发现并指向 audit-analytics 做事件级矩阵。
Phase 1 — 对照要求审计：收集与声明比对（清单 vs 隐私政策 vs App Store Nutrition Label / Play Data Safety，收集但未披露为 P0）；同意（非必要收集前是否获得、GDPR 是否要求细粒度、撤回路径、APPI 利用目的是否指定并通知）；数据主体权利（可用的删除与导出，须覆盖数据库、存储桶、日志、分析、备份、第三方 SDK）；保留期（是否有定义窗口与执行器如 cron/TTL）；跨境（处理者区域，EU→US 需传输依据，APPI 限制无同意/充分性认定下向日本境外传输）；未成年人（年龄门控与更严格默认值）；日志与 LLM 追踪（原始 PII 在应用日志/Langfuse 中）。
Phase 2 — 分阶段计划（执行前批准）：P0（未披露收集、缺失删除、先触发后同意、日志中 PII）、P1（删除不完整、缺导出、无保留任务、商店表单错误）、P2（同意细粒度、政策措辞、处理者文档）。每项包含：问题、要求（GDPR 条款/APPI/商店）、修复形态、执行方式（audit-analytics、plan-rls-audit、plan-error-handling 或政策/文本修改）。
使用方式
技能以“提议—风险—保持合规—阶段”的方式推理每个计划项：提议（必须改变什么：政策、SDK 门控、删除路径、标签）、风险（跳过会导致什么不合规或泄露）、保持合规（已披露且已门控的收集）、阶段（P0/P1/P2，不执行）。
在呈现 burndown 前必须进行自我批判（低自由度，不可跳过）：从代码而非政策出发；非法律建议，歧义标记给律师；收集但未披露为 P0，不得埋入 P2 措辞；正确归属（分析先触发后同意也指向 audit-analytics）；不重写任何内容，批准前不动政策/SDK/删除任务。
输出格式包括：数据清单（项目 | 位置 | 存储 | 共享 | 保留 | 依据）、发现（问题 | GDPR/APPI/商店 | 严重度 | 证据）、商店标签差异（声明 vs 实际）、分阶段计划（P0/P1/P2 → 执行技能），最后以独立回顾结束回合，列出两到三个最高影响发现（收集但未披露优先）和首个待批准阶段。plan-privacy-compliance.md 是交付物，须在回顾前写好。
适用场景
适用于需要审计个人数据流与隐私政策、GDPR、日本 APPI 及商店标签一致性的场景，例如应用提交商店前、隐私合规检查、数据流与法律表面规划。
限制
该技能仅做审计与计划，不重写政策、不设置 SDK 门控、不执行删除任务，直到每个阶段获批。它明确声明不构成法律建议，仅将常见 GDPR 与 APPI 要求工程化为发现，真正的歧义会标记给律师。若用户仅处于商店提交中的“隐私清单/数据安全表单文书”环节，仍应运行本技能处理数据流部分，再用 plan-mobile-readiness 处理其余部分。
相关技能
audit-analytics（事件覆盖 + 同意门控触发，建议同时运行）、plan-mobile-readiness（商店提交机制）、plan-rls-audit（访问控制）、plan-error-handling / audit-langfuse-llm（日志/追踪中的 PII）、enhance-email-deliverability（营销邮件同意）、plan-aso（标签诚实后的列表文案）。