When should I use privacy-email-review?

privacy-email-review is useful in the following scenarios: • Conducting a pre-implementation review for new features that require storing user email addresses to ensure data minimization and security. • Validating architectural designs to prevent PII exposure in system logs, URL query parameters, or unencrypted database fields. • Defining clear data retention policies and deletion requirements for user contact information to meet compliance standards. • Generating a standardized privacy checklist and developer guidelines for secure PII handling and consent management.

privacy-email-review – AI Agent Skills

When & Why to Use This Skill

This Claude skill automates the privacy design review process for features involving email and PII (Personally Identifiable Information) acquisition. It helps developers and architects identify privacy risks, ensure regulatory compliance, and implement 'Privacy by Design' best practices before the implementation phase to prevent data leaks and legal issues.

Use Cases

Conducting a pre-implementation review for new features that require storing user email addresses to ensure data minimization and security.
Validating architectural designs to prevent PII exposure in system logs, URL query parameters, or unencrypted database fields.
Defining clear data retention policies and deletion requirements for user contact information to meet compliance standards.
Generating a standardized privacy checklist and developer guidelines for secure PII handling and consent management.

name	privacy-email-review
description	メール取得を伴う機能のプライバシー設計レビューを行う。メールアドレスを保存する機能を実装する前、PII取得の設計確認時に使う。

name

privacy-email-review

description

メール取得を伴う機能のプライバシー設計レビューを行う。メールアドレスを保存する機能を実装する前、PII取得の設計確認時に使う。

目的

メール（PII）取得で起きがちな事故を事前に防ぐ設計レビュー。開発着手前に、プライバシーリスクを洗い出し対策を明確にする。

トリガー語

「メール取得のレビュー」
「プライバシーチェック」
「PII設計確認」
「メールアドレスを保存する設計を確認」

入力で最初に聞くこと

#	質問	目的
1	メール取得の目的は？（結果送付/ログイン/連絡等）	必要性の判断
2	保存先は？（DB/外部サービス/ローカル）	保護方法の決定
3	保持期間は？	削除計画の策定
4	削除要件は？	ユーザー権利への対応

手順（7項目チェックリスト）

1. 目的の正当化

メール取得が本当に必要か？
代替手段（匿名ID等）で代替できないか？

2. 同意（オプトイン）

同意文言はわかりやすいか？
プライバシーポリシーへのリンクがあるか？

3. 取得最小化

フォーム項目は最小限か？

4. 露出経路遮断

URLにメールを載せていないか？
ログにマスクなしで出力していないか？

5. 保存と保護

分離保管・暗号化されているか？
アクセス制御が明確か？

6. 保持と削除

保持期間・削除手順が整備されているか？

7. インシデント対応

漏えい時の対応手順があるか？

→ 詳細チェックリストは REFERENCE.md 参照

実装上の注意点

項目	推奨
HTTPメソッド	POST使用（GETでメールを送らない）
ログ出力	メールはマスク（`*@*`）
DBスキーマ	PIIテーブルを分離、暗号化
URL設計	クエリにメールを含めない

成果物

成果物	内容
メール取得設計メモ	7項目を埋めたドキュメント
実装注意点リスト	開発者向けガイドライン

検証（完了条件）

全チェック項目がレビュー済み
懸念事項に対策が記載されている
設計メモが保存されている
法務レビューの要否が判断されている

免責事項

このレビューは一般的なベストプラクティスに基づくものであり、法令適合性を保証するものではありません。

参照

Workflow: .agent/workflows/05_meta_privacy_review_email.md