personal-data-protection-skill
⚠ Engineering reference material — not legal advice. This skill summarises personal-data-protection obligations as they apply to building software. It is not authoritative legal guidance and must not be used as the sole basis for compliance decisions. Always verify against the official statute and consult a qualified DPO or lawyer. See DISCLAIMER.md.
Source-text posture: this skill does not reproduce or republish any of the underlying statutes. It provides engineer-facing interpretation, layered patterns, and short attributed quotations of operative phrases under fair-dealing principles, with links to the official sources. Anyone planning to package or redistribute this content beyond similar engineering-reference use should read DISCLAIMER.md § Copyright in source materials — Malaysia's PNMB-published Act 709 / Act A1727 carry the strictest publisher's notice of the populated jurisdictions and may require prior permission.
A multi-agent personal-data-protection compliance reference for engineers — packaged as both a Claude Code skill and a Codex plugin, with AGENTS.md routing for Cursor and Copilot — organised by where in the stack each obligation lands rather than by statute section number.
Status: Singapore PDPA, Thailand PDPA, Indonesia UU PDP, Malaysia PDPA, and Philippines DPA all populated. Repo ships dual plugin manifests — .claude-plugin/ (Claude Code / Cowork via /plugin install) and .codex-plugin/ (Codex) — plus AGENTS.md routing for Cursor / Copilot. Vietnam PDPD planned for v0.5 (deferred while the full Vietnam PDP Law is in draft).
Audience: anyone building any app or service that handles personal data of users in Singapore, Thailand, Indonesia, Malaysia, or the Philippines. Tech-agnostic — works whether your stack is Supabase, Firebase, AWS, your own backend, native iOS/Android, Flutter, React Native, web, a headless API, or anything else.
Coverage — Southeast Asia focus
This skill is deliberately SEA-focused. Most products built in or for the region are subject to two or more of these regimes concurrently (a Singapore-headquartered app with Thai and Indonesian users, a Malaysian fintech with Singapore corporate customers, a Philippine fintech with Indonesian and Singapore users, etc.), and the "strictest rule wins" approach only works when the regimes are factored against a shared set of implementation layers. Broader global skills (GDPR / CCPA / PIPL) exist elsewhere and are intentionally out of scope here — coverage breadth would dilute the SEA depth.
| Jurisdiction | Regulation | Regulator | Status |
|---|
| Singapore | PDPA 2012 (post-2020 Amendments) | PDPC | ✅ Populated |
| Thailand | PDPA B.E. 2562 (2019) | PDPC Thailand | ✅ Populated |
| Indonesia | UU PDP No. 27/2022 | Komdigi | ✅ Populated |
| Malaysia | PDPA 2010 (with 2024 Amendments — Act A1727) | JPDP | ✅ Populated |
| Philippines | Data Privacy Act 2012 (RA 10173) | NPC | ✅ Populated |
| Vietnam | PDP Decree 13/2023/ND-CP | A05 (MPS) | 🚧 Planned for v0.5 (deferred — full PDP Law in draft) |
Not in scope: GDPR, UK GDPR, CCPA / CPRA and other US state laws, PIPL (China), APPI (Japan), PIPA (Korea), DPDP Act (India), LGPD (Brazil), POPIA (South Africa), Privacy Act 1988 (Australia), PIPEDA (Canada). If your product is also subject to one of these, pair this skill with a jurisdiction-specific reference for that regime.
Why this exists
Personal-data-protection statutes are written by lawyers, for lawyers. Engineers shipping features need answers like "I'm adding a new column that stores user PII — what do I touch?", not section numbers. This skill bridges the two:
- Layered guidance by where in the stack the obligation lives (architecture, data model, controls, feature/UX, disclosure, operational) — universal across jurisdictions.
- Jurisdiction-specific obligations mapped to the relevant statute sections.
- Entry-point checklists for common tasks: new feature, new data field, new vendor, breach response.
- Statute-map for reverse lookup when you need to cite a section in a PR description, audit response, or breach notification.
Use cases
Three scenarios that show what this skill actually helps with — each one is a real engineering trap that a developer would otherwise miss.
1. SG-based fintech expanding to Philippines for OFW remittances
Your KYC flow already collects a TIN, SSS, and PhilSys number. In Singapore those are plain PI; in the Philippines they're Sensitive Personal Information under § 3(l) of RA 10173 — the SPI category in PH explicitly includes all government-issued identifiers, which is broader than every other jurisdiction this skill covers.
