feat(skills): add privacy-by-design skill with PbD 7 Foundation Principles assessment

[Yogi (yogitasrivastava)]

Summary

Adds a new privacy-by-design skill under .github/skills/project-planning/ that encodes the Cavoukian 7 Foundation Principles of Privacy by Design as structured, agent-consumable assessment references.

What this delivers

File	Purpose
SKILL.md	Skill entrypoint with when-to-use, layout, integration notes, attribution

|
eferences/00-principle-index.md | Principle catalog with regulatory cross-reference matrix |
|
eferences/01-07 | One file per PbD principle with checklist, controls, anti-patterns, regulatory mappings |
|
eferences/data-retention-and-disposal.md | Principle 05 deep-dive: retention schedules, disposal methods, legal holds |
|
eferences/cross-jurisdictional-mapping.md | GDPR / CCPA-CPRA / APP equivalence matrix |

Key differentiators

• Structured assessment criteria — each principle has observable PASS/FAIL/PARTIAL indicators with severity ratings
• Cross-jurisdictional coverage — maps all 7 principles across GDPR Art. 25, CCPA/CPRA, and Australian Privacy Principles (APP)
• Data retention and disposal — full lifecycle guidance under Principle 05 including legal holds, backup considerations, disposal verification
• Agent-ready architecture — feeds Privacy Reviewer and Privacy Planner without agent modification (same pattern as owasp-* skills feeding security-reviewer)
• Complements privacy-standards — extends the NIST PF/GDPR/CCPA/OWASP backbone with principle-level assessment

Value proposition

Without this skill	With this skill
Privacy Reviewer assesses only against NIST PF, GDPR, CCPA, OWASP Privacy Risks	Also assesses against PbD principles, retention/disposal compliance, and APP
No structured checks for 'is privacy the default?' or 'is data disposed securely?'	Principle-by-principle structured findings with severity ratings
No Australian Privacy Principles coverage	Cross-jurisdictional coverage (GDPR + CCPA + APP)

Checklist

• Follows existing skill structure (mirrors secure-by-design, owasp-top-10 patterns)
• Includes attribution and licensing posture
• No executable scripts (markdown knowledge-base skill)
• Cross-references privacy-standards skill for integration context

Refs: #2594

[Codecov Comments Bot (codecov-commenter)]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.01%. Comparing base (8aa6b21) to head (cfeb0dc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2635      +/-   ##
==========================================
- Coverage   83.14%   83.01%   -0.13%     
==========================================
  Files         183      185       +2     
  Lines       34028    34605     +577     
  Branches       27       27              
==========================================
+ Hits        28291    28729     +438     
- Misses       5734     5873     +139     
  Partials        3        3              

Flag	Coverage Δ
docusaurus	90.60% <ø> (ø)
pester	83.41% <ø> (-0.43%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Jamie Kim (jkim323)]

Requested changes

I ran the skill through the hve-builder tester and here are some findings worth considering. The simulated behavior assessment identified four required corrections to the assessment contract and evidence handling:

1. Support incomplete assessments (F01). Define explicit outcomes for insufficient evidence, with consistent principle verdicts, overall verdicts, summary counts, and unknown-baseline handling. The current contract forces unsupported null values when all checks are unknown. Missing evidence must not be treated as a failed control.

2. Support CRITICAL severity end to end (F02). Industry profiles require CRITICAL escalation, but the finding schema, severity distribution, and backlog mapping do not support it. Add CRITICAL consistently across these outputs. Map CRITICAL and HIGH to P1, ordering CRITICAL first, without introducing P0 or downgrading severity.

3. Separate deficiency severity from data sensitivity (F03). PASS results currently receive MEDIUM or HIGH severity because of the data involved, even though those severity definitions imply a deficiency. Use N/A when no deficiency is established, including PASS results, and align the entrypoint, assessment protocol, finding records, and summaries. Unknown evidence alone must not generate fictitious remediation work.

4. Reconcile contradictory evidence before transparency PASS (F04). A documented retention promise cannot justify an unqualified PASS when current operational evidence contradicts it. The test promised eSIM destruction within 30 days but showed recoverability at day 120. Record and assess that discrepancy while preserving credit for unaffected transparency controls.

Coverage and follow-up

• Add regression coverage for healthcare and financial profiles, plus suppression of a check that would otherwise apply under the active profile (F05). Excluding unrelated checks does not demonstrate effective suppression. This is a coverage gap, not proof those features are defective.
• Consider consistently including the known retention_category and retention_gap citation fields in retention findings (F06). This is advisory because the current schema does not clearly require them.
• After implementation, rerun the corrected scenarios and preservation checks. Keep simulation results distinct from evidence of native activation, live privacy controls, or legal compliance.