SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillspia-generation

pia-generation

Security & auditing

View repository

Updated 10-15 15:15

About this skill

/pia-generation
  1. Load ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → PIA internal specification (trigger criteria, structure, depth, approval).
  2. Execute the following workflow.
  3. Check: Is a PIA actually required? (Internal trigger criteria + retrieve the statutory assessment trigger conditions of each applicable regime—cite primary sources, verify currency.)
  4. Intake: Ask the product team questions. Information already provided in the PRD may be extracted.
  5. Draft the PIA according to the internal format. Include a consistency check with the personal information processing rules.
  6. Output a conditions list with designated owners. Route for approval.
/privacy-legal:pia-generation "位置共享功能"

/privacy-legal:pia-generation
PRD: [网盘链接]
Personal Information Protection Impact Assessment Generation

Matter Context

Matter context. Check the practice-level CLAUDE.md for ## 事项工作区. If 已启用 is ✗(the default for legal users), skip this section—the skill uses practice-level context and the matter mechanism is not visible. If enabled and there is no active matter, ask: "Which matter is this? Run /privacy-legal:matter-workspace switch <slug> or say 实践级." Load the active matter's matter.md to get matter-specific context and overrides. Write output to the matter folder ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/matters/<matter-slug>/. Never read files from other matters unless 跨事项上下文 is 开启.

Destination Check

Before generating output, check the output destination. If the user specifies a destination (channel, distribution list, opposing party, "everyone"), ask whether it is within the confidentiality circle. Public channels, company-wide lists, opposing parties/opposing counsel, vendors, and clients (with respect to work product) waive protection. When the destination appears to be outside the circle, flag it and offer (a) a legal-only confidential version, (b) a sanitized version for broader channels, or (c) both—do not silently add a confidentiality legend and then help paste it somewhere that legend cannot protect. See ## 共享护栏 → 目的地检查。

in this plugin's CLAUDE.md.

Purpose

A PIA is a conversation with the product team, written down. It asks: what data, why, for how long, who sees it, what could go wrong. This skill structures that conversation and writes the output in this team's format—consistent with the format learned from seed PIAs in the cold-start interview.

Jurisdictional Assumptions

Load Prior Context About This Feature/Activity

Before drafting a new PIA, check the output folder for prior work on the same feature, processing activity, or counterparty. Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## 输出 to get the path. Scan:

  • Prior use-case-triage resultscovering this activity—the triage risk rating, mandatory conditions, and flagged concerns are the entry point for the PIA.
  • Prior pia-generation outputCover the same or overlapping activities—the new PIA should connect with it (what changed, what continues). A PIA that silently reaches different conclusions about the same activity is a contradiction the reviewing lawyer cannot detect.
  • Prior dpa-review outputCovered vendors—findings from DPA review inform the PIA's analysis of downstream processors/cross-border/retention risk.

If prior output is found, cite it in the PIA:

"Prior triage ([date]) rated this activity as [risk level] and required [conditions]. This PIA builds on that finding—[which conditions have been met, which remain outstanding, which have been recharacterized]."

If a prior PIA exists:

"This PIA supersedes the PIA dated [date] because [reason—scope change, new data category, vendor change, regulatory change]. Conclusions that continue: [X]. Conclusions revised: [Y, because Z]."

Inherit severity from upstream as a floor, following the cross-skill severity floor rule in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## 共享护栏 . An activity rated high risk in triage cannot silently become low risk in the PIA unless the reasoning and what changed are stated.

If no prior output is found, state it explicitly—"No prior triage or PIA concerning this activity exists in the output folder; this is a cold start"—so the reviewing lawyer knows the check was performed and nothing requiring connection was found.

Load internal norms

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## PIA 内部规范. It contains:

  • What triggers a PIA for this team (may differ from statutory assessment triggers—some teams do PIAs for all processing activities, some only for high-risk activities)
  • The structural template extracted from the seed PIA
  • Typical depth
  • Approvers

If the CLAUDE.md config contains a seed PIA structure,use it. The point is for this PIA to look like the other PIAs this team produces, not like a generic template.

Step 0: Is a PIA required?

Check the trigger criteria in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md . This is the team's internal answer.

In addition,retrieve the currently effective statutory assessment triggers for each applicable regime in the regulatory coverage(the four categories of circumstances under Article 55 of the Personal Information Protection Law, the data outbound security assessment, the algorithm security assessment, etc.). Cite currently effective laws, administrative regulations, departmental rules, or guidelines, with precise citations. Verify currency—assessment thresholds and definitions change with new legislation and enforcement guidance. Flag when uncertain rather than guessing.

No silent supplementation. If a retrieval query against the configured legal retrieval tool returns few or zero results on a regime's assessment triggers or legality basis rules, report what was found and stop. Do not fill gaps from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage of [regime/issue] appears thin. Options: (1) broaden the search query, (2) try a different retrieval tool, (3) search the web—results will be flagged as [联网检索 — 需复核]and should be checked against primary sources before relying on them, (4) flag as unverified and stop. Which do you want to choose?" It is for the lawyer to decide whether to accept lower-credibility sources.

Source provenance tags. Tag each citation in the PIA with a source tag:[法条原文] indicates direct quotation of a statutory provision,[yuandian检索] indicates obtained via yuandian MCP,[联网检索 — 需复核] indicates obtained via web search,[模型知识 — 需验证] indicates it comes from training data,[用户提供] indicates it is provided by the user. Citations marked "needs verification" have the highest risk of fabrication and should be checked first. Never strip or collapse tags.

Beyond legal requirements, treat the following asstrong indicators—even if not strictly legally mandated, a PIA is worth doing (research whether it independently triggers a legal assessment under the applicable regime):

  • New technology applications or innovative uses of existing technology
  • Minors' data
  • Combining datasets that were originally collected separately
  • Data that may lead to discrimination
  • Processing activities that personal information subjects would not expect

If there is no legal trigger and internal triggers are also not met → "A PIA does not appear to be required. This is a short memo explaining the reasoning, in case anyone asks."

Input

Before writing anything, get answers to the following questions from the product team. Conversational is fine—this is not a form to send them.

What and why

  • What is the feature/product/change?
  • What problem does it solve for users?
  • Which personal information is involved? Be specific—"user data" is not an answer. Which fields?
  • Is there any new collection, or is it all existing data?
  • What is the processing—storage, analysis, sharing, automated decision-making?

Lawful basis / regime-specific checks

For each applicable regime,retrieve the currently effective framework under that issueand cite primary sources:

  • PIPL Article 13 lawful bases [法条原文]: identify the lawful basis for each processing purpose (notice and consent / necessary for entering into or performing a contract / necessary for performing legal obligations / necessary for responding to public health emergencies or protecting the life, health, and property safety of natural persons / processing within a reasonable scope for public interest news reporting, public opinion supervision, and similar activities / processing publicly disclosed personal information within a reasonable scope / other circumstances provided by laws and administrative regulations). Research notice and consent should satisfy the specific requirements of "voluntary, explicit, and informed" (PIPL Article 14 [法条原文]).
  • Sensitive personal information: If involved, check whether the requirements of PIPL Articles 28-30 are met (separate consent + specific purpose + sufficient necessity + notice of impact)[法条原文]。
  • Data cross-border transfer: If involved, check whether a security assessment is required (Measures for Security Assessment of Data Cross-border Transfer), signing standard contracts (Measures for Standard Contracts for Cross-border Transfer of Personal Information), or certification (PIPL Article 38 [法条原文]）。
  • Industry regulation: whether there are special requirements in areas such as finance (Technical Specifications for Personal Financial Information Protection), healthcare (Measures for the Administration of Population Health Information), and children (Provisions on the Cyber Protection of Children's Personal Information).

Verify timeliness; legal definitions and bases are frequently revised through administrative regulations and departmental rules. When uncertain, flag it for lawyer verification.

Who and where

  • Who within the company can access this data? Engineers? Customer service? Analysts?
  • Are there third parties? Vendors, partners, data analytics providers?
  • Where is the data stored? Which region? New infrastructure or existing infrastructure?
  • How long is it retained? Is there a deletion schedule, or is it retained permanently?

What could go wrong

  • If this data leaks, what is the harm to individuals?
  • Could this data be used for discrimination, even unintentionally?
  • Would users be surprised this is happening? ("Creepy test" — not a legal standard, but useful.)
  • Is there an opt-out? Should there be?

Write the PIA

Use the seed PIA structure in the CLAUDE.md configuration. If not captured, use the default structure below. Prefix with the work-product header from ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md ## 输出 (varies by user role — see ## 谁在使用）。

[工作成果抬头 — 按插件配置 ## 输出]

# 个人信息保护影响评估：[功能/产品名称]

**编制人：** [姓名] | **日期：** [日期] | **状态：** 草案 / 已批准
**产品负责人：** [姓名] | **隐私审核人：** [姓名]

---

## 摘要

[两句话：这是什么，是否合规。例如："功能X收集位置数据以提供Y服务。处理活动与现行个人信息处理规则承诺一致，以告知同意为合法性基础。以下建议两项缓解措施；未识别到阻碍事项。"]

**整体风险：** [审核人设定：🟢 低 / 🟡 中 / 🟠 高 / 🔴 极高]

---

## 1. 处理活动描述

**是什么：** [功能，通俗描述]
**数据类别：** [具体字段——不是"用户数据"]
**个人信息主体：** [客户 / 最终用户 / 员工 / 等]
**目的：** [为什么——与用户利益关联]
**新收集？** [是——以下字段为新增 / 否——复用已有数据]

---

## 2. 合法性基础（个保法第13条）

| 目的 | 合法性基础 | 备注 |
|---|---|---|
| [目的1] | [告知同意 / 合同必需 / 法定义务 / 等] | [如为同意：如何获取；如涉及敏感个人信息：是否已获单独同意（个保法第29条）] |

---

## 3. 数据流转

**收集：** [数据如何/从哪里进入]
**存储：** [系统、区域、加密]
**访问：** [谁，通过何种控制措施]
**共享：** [第三方，目的，受哪份数据处理协议约束]
**保留：** [保留多久，删除机制——个保法第19条：最短必要期限 `[法条原文]`]

---

## 4. 个人信息处理规则一致性

| 处理规则承诺 | 一致？ | 备注 |
|---|---|---|
| [来自配置 CLAUDE.md 处理规则部分的承诺] | 🟢 / 🟡 | |

[如有任何 🟡：上线前需更新处理规则，或需变更处理活动]

---

## 5. 风险与缓解措施

| # | 风险 | 可能性 | 影响 | 缓解措施 | 状态 | 负责人 |
|---|---|---|---|---|---|---|
| 1 | [与设计关联的具体风险——并非泛泛的"数据泄露"] | 低/中/高 | 低/中/高 | [具体控制措施] | 已完成 / 计划中 / 缺口 | [姓名] |

**缓解后剩余风险：** [评估]

---

## 6. 个人信息主体权利（个保法第44-50条）

| 权利 | 可行使？ | 如何行使 |
|---|---|---|
| 知情权（第44条） | | |
| 查阅权（第45条） | | |
| 复制权（第45条） | | |
| 更正权（第46条） | | |
| 删除权（第47条） | | |
| 可携带权（第45条） | | |
| 解释说明权（第48条） | | |

---

## 7. 建议

[批准 / 附条件批准 / 需变更 / 不批准]

**条件（如有）：**
- [ ] [上线前必须完成的具体事项]

**审批：** [姓名，日期]

Risk quality standards

Risks in a PIA should bespecific and tied to the design, not generic. Poor risk statements pad the document and train readers to skim.

Poor risk Why it's poor Better
"Data breach" Applies to everything; says nothing "Support staff can access location history through the admin panel, with no audit log — a malicious insider could track users without detection"
"Non-compliance with PIPL" Circular reasoning — the PIA is precisely forassessingcompliance Point to specific provisions and gaps
"Users might not like it" Vague "Users who have opted out may still receive this push, because the opt-out flag is not checked in that flow"

Aim for 2-5 real risks, not 15 filler risks.

Personal information processing rules discrepancy comparison

Every PIA should cross-check the personal information processing rules commitments in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md . Common drift:

  • The processing rules say "we collect X, Y, Z" — the new feature collects W. The processing rules need to be updated, or collection of W stopped.
  • The processing rules say "we do not provide data to third parties" — the new feature shares with an advertising partner. This may constitute external provision under Article 23 of the PIPL.
  • The processing rules say the retention period is "for the duration of the account" — the new feature retains data after account deletion.

Flag every mismatch. One of the two must change before launch.

Handoff

  • To the product team: a conditions list with owners and deadlines. Not "improve security" — but "add an audit log for location queries on the admin panel, owner: [engineering lead], deadline: before launch."
  • To the reg-gap-analysis skill: if the PIA found processing rule inconsistencies, that skill tracks processing rule updates.
  • To the approval process: per ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → who approves the PIA.

Gate: Submitting the assessment to regulators

Producing an internal PIA is research and documentation.Submitting the PIA to a regulatory authority— or voluntarily disclosing it in response to an administrative investigation — is an act with legal consequences.

Before submitting any impact assessment to the CAC or another department performing personal information protection duties: read the ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md in ## 谁在使用. If the role is non-lawyer:

Submitting documents to regulatory authorities has legal consequences—the documents become part of the administrative regulatory record, and any material omission or error constitutes enforcement risk exposure. Have you had a lawyer review this? If so, proceed. If not, here is the brief you bring to the lawyer:

[Generate a 1-page summary: applicable regimes and regulatory authorities, why submitting (legally triggered or voluntary), identified risks, residual risk after mitigation, any flagged uncertainties, and the three things to ask a lawyer before submitting.]

If you need to find a practicing lawyer or another authorized legal professional: the fastest starting point is through your local bar association or the judicial bureau's lawyer lookup system. Many local bar associations offer free or low-cost initial consultations.

Do not cross this gate without explicit consent.

End with the following next-step decision tree

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

What this skill does not do

  • Does not approve processing activities. A human signs the PIA.
  • Does not write a DPIA for submission to a regulatory authority—that is a more formal document with specific regulatory requirements. This is an internal assessment.
  • Does not design mitigations. It describes what needs mitigation; the engineering team designs the fix.