policy-monitor

/policy-monitor

Scan mode(no parameters or --sweep）：

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → output folder path, processing rule file, last scan date.
Execute the following workflow. Scan the files in the output folder since the last scan.
For each output: extract approved practices → diff against current processing rule commitments.
Classify gaps: Must (the processing rule makes a misrepresentation about current practice) vs. Recommended (the processing rule does not mention it).
For each gap: cite the current processing rule, describe the gap, draft suggested language.
Update ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md the last processing rule scan date in.

Direct query mode(with description parameter):

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → current processing rule commitments + actual processing rule file.
Parse the proposed practice. Diff against the processing rule: data categories, purposes, third parties, retention periods, user rights, external disclosures.
Output: covered / missing / conflicting + suggested language for each gap + timing recommendation.

Timing: Set up a recurring reminder in your own scheduling tool (calendar, task manager, or CI) to run weekly /privacy-legal:policy-monitor. Scheduled execution requires scheduled task integration and is not included in this plugin.

/privacy-legal:policy-monitor
/privacy-legal:policy-monitor "我们想开始用行为数据个性化引导邮件"

Personal information processing rule monitoring

Purpose

Personal information processing rule deviation from practice only goes in one direction: practice moves forward, the processing rule stands still. Some PIA approved a new data category. Some DPA was signed with a downstream processor that is not listed anywhere. Some triage result flagged a new use case as conditionally approved, with a disclosure requirement the processing rule has not yet made. A few months later, someone reads the processing rule and it no longer reflects what actually happened.

This skill catches drift before it becomes a problem—by scanning the output folder weekly, or by answering the direct question: "We are about to start doing X, what does this mean for the processing rule?"

The output is always the same: here is the gap, here is the suggested language.

Load current state

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md：

## 我们是谁 → ## 监管覆盖范围 — the regimes in scope (PIPL, Data Security Law, Cybersecurity Law, industry regulation, etc.)
## 个人信息处理规则承诺 — commitments extracted from the published processing rule
## 输出 — output folder path, processing rule file location, last scan date

If ## 输出 contains [占位符]：

"Output is not yet configured. I can still run a direct query check—describe what you plan to do, and I will diff it against your current processing rule. To enable automatic scanning, run /privacy-legal:cold-start-interview and provide the output folder path."

From ## 输出 → Personal information processing rule file the path in to read the actual processing rule file. The commitments in the configuration CLAUDE.md are a summary; the actual file is the authoritative source when suggesting edits.

The personal information processing rules commitment exists across multiple surfaces — scan all surfaces

The website personal information processing rules are one surface. Modern personal information protection programs make binding commitments in at least four other places that are also actively reviewed by regulators for consistency:

Cookie consent banner / CMP (Consent Management Platform). The CMP commits to specific cookie categories and purposes. If the processing rules say "we use analytics cookies" while the CMP offers "necessary only," there is a conflict. The Cyberspace Administration of China and market regulation authorities have taken enforcement action against CMP misconfigurations.
App store privacy labels. Apple App Privacy ("nutrition labels") and Google Data Safety are self-declared and enforceable. If a company updates its processing rules but does not update its app store labels, there is a substantive, regulator-visible inconsistency. Check: When were the labels last updated? Are they consistent with the data categories, purposes, and sharing declared in the current processing rules?
In-product consent flows. The actual interface through which users make data use choices (onboarding consent, settings toggles, "we have updated our processing rules" pop-ups). The processing rules say what you will do; the consent flow says what the user agreed to. They should match.
Industry-specific notices. Domains such as finance, healthcare, and minors have their own notification obligations and consistency requirements with the general processing rules.

Add location and last updated date fields for each surface in the practice profile. The scan checks each surface for consistency with the current processing rules and flags deviations: "Processing rules updated on [date]. App store labels last updated on [earlier date] — may not reflect new data categories. CMP last configured on [date] — verify that cookie purposes match the processing rules."

A company with clean processing rules and outdated app store labels is a company with a complaint waiting to happen. Scan all surfaces, not just one document.

Industry-specific notices are also within the scope of this scan

Website processing rules are one notice. Industry-regulated practices require separate, industry-specific notices, and website processing rules cannot replace them. If ## 监管覆盖范围 contains any of the following, the scan diffs the practice against that notice — in addition to the website processing rules — or flags its absence if it is not configured:

Coverage item	Industry notice to be diffed	What needs to be flagged
Finance(Personal Financial Information Protection Technical Specification + Regulations on the Administration of the Credit Reporting Industry)	Special notice on personal information processing in the financial sector	New financial information categories, sharing with non-affiliated third parties, or changes to opt-out mechanisms implied in the output that the industry notice does not reflect.
Healthcare(Measures for the Administration of Population Health Information + Personal Information Protection Law)	Special notice on health and medical data processing	New uses or disclosures, new routine categories, or changes to patient rights mechanisms implied in the output.
Minors(Provisions on the Cyber Protection of Children's Personal Information + Article 31 of the Personal Information Protection Law)	Direct notice to guardians + online notice	New data categories collected from minors, new third-party disclosures, or changes to guardian consent mechanisms implied in the output.
Automotive data(Several Provisions on the Management of Automobile Data Security)	Special Notice on Automobile Data Processing	Processing activities implied in the output that are subject to the Provisions, while the configured notice does not reflect them.

If a system in the coverage scope has no industry notice configured, present it in each scan as an ongoing gap, rather than a one-time finding. The scan output should include:

Industry notice coverage:

[System]: [Configured notice path + last update, or "Not configured — flagged in each scan until resolved"]

If the scan cannot locate the industry notice, state this explicitly — do not silently default to comparing differences only against the website processing rules. Personnel who rely on processing-rule monitoring scans while missing industry notices may issue outdated regulatory-facing notices without warning. Present this gap loudly.

If the coverage scope is ambiguous, ask the user. If ## 监管覆盖范围 says "PIPL / Data Security Law" but the output scan touches data in the healthcare, financial, or minor categories, present the mismatch between coverage scope and actual scope before continuing: "Your coverage scope does not list [financial/healthcare/minor protection]-related systems, but this scan is looking at output involving [category]. Should that system be added to the coverage scope, and is there a corresponding industry notice that needs difference comparison?"

Mode Detection

Scan mode: no parameters,--sweep or triggered by a schedule. → Scan the output folder. Compare all output since the last scan against the current processing rules.

Direct query mode: the user provides a description of a proposed new practice. → Compare that practice against the current processing rules. Suggest updates.

Mode 1: Scan

Determine scope

Read ## 输出 → Last Processing Rule Scan date. Scan output files in the output folder after that date. If no date is recorded, scan all files and note: "First scan — scanning all output."

If the output folder is empty or there are no new files since the last scan:

"No new output since [last scan date]. Processing rules and recent practices appear consistent. Next scheduled scan: [date]."

After completing the scan, update Last Processing Rule Scan to today's date in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md。

What to read for each output type

PIA (Personal Information Protection Impact Assessment):

Extract: data categories processed, purposes, third parties/entrusted processors involved, retention periods, impact on user rights, proposed processing conditions
Flag: anything in this list that is not present in the current processing rule commitments

DPA review (signed or approved):

Extract: new downstream processors, agreed data locations, covered processing purposes, any obligations created by DPA clauses toward personal information subjects
Flag: downstream processors not listed in the processing rules (if listed in the processing rules), new processing categories, new data locations, obligations inconsistent with the processing rules

Triage results (impact assessment required / can proceed results):

Extract: what was approved, any conditions imposed that imply public commitments (e.g., "must disclose to affected parties before launch")
Flag: approved practices not covered by the processing rules, conditions that require processing rule language

Response to Data Subject Rights Request:

Extraction: any newly appearing data category not present in prior requests, any system added to the system inventory
Flagging: data categories that are collected but not declared in the processing rules

Gap Identification

For each flagged item, assess:

Must update — the processing rules made a commitment that conflicts with this output, or the processing activity is ongoing but the processing rules do not cover it at all. Not updating constitutes a material misrepresentation.

Example: The processing rules say "we collect name, email, and payment information." A PIA approved the collection of location data. The processing rules say nothing about location. This must be updated — you are collecting data you have not disclosed.

Recommend update — not mentioned in the processing rules but no conflict. The processing activity is defensible without updating, but updating makes it more complete.

Example: The processing rules say "we may share data with service providers." A DPA was signed with a new data analytics vendor. The processing rules do not list that vendor by name but do not exclude them either. Recommend adding to the maintained downstream processor list.

Scan Output Format

[工作成果抬头 — 按插件配置 ## 输出 — 因角色不同而异；见 `## 谁在使用`]

# 个人信息处理规则监控 — 扫描报告

**日期：** [日期]
**输出已扫描：** [N个文件] | **自上次扫描以来新增：** [N个文件]
**发现的差距：** [N] 必须 | [N] 建议

---

## 必须更新

### [差距1 简短名称]

**来源：** [触发此的文件名 / 输出类型]
**正在发生什么：** [新实践的通俗描述]
**当前处理规则：** [引用相关章节 — 或"无覆盖"]
**差距：** [什么缺失或不一致]

**建议语言：**
> *添加至[章节名称]：*
> "[起草的处理规则文本 — 具体，与实际处理规则的语言风格一致]"

---

[对每个必须差距重复]

---

## 建议更新

### [差距名称]

**来源：** [文件名]
**正在发生什么：** [描述]
**当前处理规则：** [引用或"未提及"]
**建议语言：**
> *添加至 / 更新 [章节]：*
> "[起草文本]"

---

## 无需行动

[列出已扫描且未发现差距的输出——确认它们已被审阅]

---

## 后续步骤

- [ ] 审阅必须更新——每个都需要在相关功能/处理活动上线前（或如已上线则立即）做出决定
- [ ] 审阅建议更新——紧迫度较低但值得在下一次处理规则更新时处理
- [ ] 下次计划扫描：[日期]

Mode 2: Direct Query

Parse Proposed Practice

Extract from the user description:

What data is collected or processed?
What is the purpose?
Who else is involved (vendors, partners, third parties)?
Who are the data subjects?
Is there any automated decision-making?
Is new disclosure to data subjects required?

If the description is vague, ask one clarifying question before continuing. Do not do lengthy intake — this mode should be fast.

Processing Rules Gap Comparison

Compare the proposed practice against each relevant part of the current processing rules:

Checkpoint	Current processing rules say	Proposed practice	Determination
Data categories	[listed in processing rules]	[new categories if any]	🟢 Covered / 🟡 Gap / 🔴 Conflict
Purpose	[declared purpose]	[new purpose]
Third parties / downstream processors	[declared parties]	[new parties if any]
Retention period	[retention commitment]	[implied retention period]
User rights	[rights provided]	[any new rights impact]
Disclosure / notice	[what the processing rules say about informing users]	[what this practice requires]

Direct Query Output Format

[工作成果抬头 — 按插件配置 ## 输出 — 因角色不同而异；见 `## 谁在使用`]

# 个人信息处理规则检查：[一行概括拟议实践]

**结论：** [需更新处理规则 / 建议更新 / 无需更新]

---

## 已覆盖

[列出拟议实践中已被当前处理规则覆盖的方面——简洁，确认它们不需要改变]

## 缺失

### [差距1]

**当前处理规则：** [引用或"未提及"]
**为什么需要：** [为什么该差距重要——法律、声誉或一致性原因]

**建议语言：**
> *添加至[章节]：*
> "[起草文本]"

### [差距2]
[相同格式]

## 冲突

### [冲突1 — 如有]

**当前处理规则说：** [引用]
**拟议实践做的是：** [什么冲突]
**解决：** [哪一方需要改变及为什么——通常是实践调整以匹配处理规则，或处理规则更新至可辩护的新立场]

---

## 时机

[如果任何差距为必须："处理规则更新应在此上线前完成。"
如果建议："可推进；在下一次处理规则更新时调整。"]

Suggested Language Quality Standards

Processing rules language should:

Match the tone and style of the existing processing rules (read the actual document before drafting, not just the summary configured in CLAUDE.md)
Be specific enough to be meaningful, but not so specific that routine changes break it ("service providers that assist us in operating our business" is more durable than listing every vendor name)
Do not make commitments the team cannot keep (e.g., do not draft "we never share location data" if that data flows to an analytics vendor in the architecture)
Flag where a broader processing rules position change may be needed, rather than just adding one sentence

When drafting, always state which section it is added to. If the correct section does not exist, state that and suggest creating it.

Scheduled integration

Set up a recurring reminder in your own scheduling tool (calendar, task manager, or CI) to run weekly /privacy-legal:policy-monitor. Scheduled execution requires cron integration, which this plugin does not include.

On each scan run, it updates ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md in ## 输出 → last processing rules scan, so the next scan only looks at new files.

End with a next-step decision tree

End with a next-step decision tree consistent with CLAUDE.md ## 输出 . Customize the options based on what this skill has just produced—the five default branches (draft X, escalate, get more facts, watch and wait, other) are a starting point, not locked in. The decision tree is the output; the lawyer chooses.

If the scan found more than about 10 drift findings, or the user asks at any time: provide the dashboard (see CLAUDE.md ## 输出 → 数据密集型输出的仪表板提议). To that end output a customized proposal—counts by surface (processing rules clauses / PIA / DPA / triage), counts by severity, and a sortable findings matrix with source artifacts and suggested remediation.

What this skill does not do

Does not update the processing rules themselves—it drafts suggested language and flags decisions, but a human reviews and approves each change.
Does not capture regulatory changes—that is reg-gap-analysis. This skill monitors internal practice drift, not external legal changes.
Does not enforce that outputs are saved—if the team does not save PIAs to the configured folder, the scan will not find them. Direct query mode works without saved outputs.
Does not read informal decisions in email or instant messaging—it only scans structured outputs saved to the configured folder.