@raishin/vanguard-frontier-agentic 2.0.0 → 2.0.1

package/skills/marketing/lookalike-audience-upload-compliance-review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: lookalike-audience-upload-compliance-review
+description: Use this skill when reviewing custom-audience and lookalike-audience upload specifications for hashing adequacy, PII field scope, consent-basis validity, and platform data-sharing restrictions before the upload is submitted to Meta, Google, LinkedIn, or TikTok. Trigger when a user provides an audience upload field-mapping specification (CSV schema or platform upload template), declared hashing method, consent-basis documentation, or originating list segment metadata — or when they ask whether their customer list upload or lookalike seed list is compliant with GDPR, CCPA/CPRA, or platform terms before uploading.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: data
+  lifecycle: experimental
+---
+
+# Lookalike Audience Upload Compliance Review
+
+## Purpose
+This skill reviews custom-audience and lookalike-audience upload specifications for hashing adequacy, PII field scope, consent-basis validity, and platform data-sharing restrictions before the upload is submitted to Meta, Google, LinkedIn, or TikTok. Customer list uploads are one of the most common data-sharing vectors in marketing operations: a brand transmits personal data — email, phone, name, address — to an ad platform under the guise of audience matching. The legal basis, the scope of consent granted, the minimality of the field set, and the reversibility of the hashing method all determine whether the upload is a lawful data-sharing arrangement or an unauthorized third-party disclosure that violates GDPR Article 5 and 6, CCPA/CPRA §1798.100, and platform terms. The review catches underhashed identifiers, oversized field sets, consent-scope mismatches, and re-identification surfaces before the upload fires.
+
+## Lean operating rules
+- Treat email addresses, phone numbers, or other direct identifiers hashed with MD5 rather than SHA-256 (or better) as HIGH — MD5 is trivially reversible via rainbow table for common email formats and does not constitute adequate pseudonymization under GDPR Article 5(1)(f).
+- Treat a seed list for a financial-services, insurance, or healthcare lookalike that includes customers who consented only to service communications (transactional consent) as HIGH — sharing that list with an ad platform for advertising targeting exceeds the consent scope, constituting unauthorized "sharing" of personal information under CPRA §1798.100 and a purpose-limitation violation under GDPR Article 5(1)(b).
+- Treat a field mapping that includes home postal code combined with email and phone as HIGH — the combination creates a high-confidence re-identification surface beyond what the matching algorithm requires, violating the data-minimization principle under GDPR Article 5(1)(c) and FTC data-minimization guidance.
+- Treat unhashed upload of any direct identifier (plain-text email, phone, name) as HIGH — no platform terms permit plain-text PII upload, and transmission in the clear is an unequivocal data breach of the identifier.
+- Treat the absence of a documented lawful basis (GDPR Article 6) for the data-sharing arrangement — neither the original collection basis nor a separate legitimate-interest or consent basis for sharing with the ad platform — as HIGH.
+- Treat lookalike seed lists that include individuals in jurisdictions where the operator has no data-processing agreement with the ad platform (e.g., EU residents shared with a non-adequate-country platform without SCCs) as HIGH — the transfer itself is unlawful under GDPR Chapter V.
+- Flag field sets that include date of birth, precise geolocation, or transaction-level history where only email and phone are needed for matching as MEDIUM — over-inclusion violates data minimization and increases re-identification risk.
+- Flag platform-specific restrictions violated by the field mapping — e.g., Meta's Customer List Custom Audience terms prohibit health, financial account data, and sensitive categories — as MEDIUM when inclusion is marginal but potentially violating.
+- Flag the absence of a documented retention or deletion schedule for the matched and unmatched records on the platform side as MEDIUM — GDPR Article 5(1)(e) requires storage limitation; the user should confirm platform-side deletion timelines.
+- Do not recommend uploading any field not strictly needed for the matching objective; default to the minimum field set (normalized lowercase email SHA-256 hashed) unless the user explicitly requires phone or name for match-rate reasons.
+- Label every finding with evidence basis: field-mapping spec provided, hashing method declared, consent documentation provided, or inference from missing information.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Hashing adequacy assessment (algorithm, where hashing occurs, platform requirement alignment)
+- PII field-scope and data-minimization assessment (fields included vs. fields needed)
+- Consent-basis validity assessment (original collection basis, scope for ad-platform sharing)
+- Cross-border transfer assessment (GDPR Chapter V if EU data subjects are in the list)
+- Platform-specific restriction check (Meta, Google, LinkedIn, TikTok terms)
+- Re-identification surface assessment (field combination risk)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/lookalike-audience-upload-compliance-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "lookalike-audience-upload-compliance-review",
+  "name": "Lookalike Audience Upload Compliance Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review custom-audience and lookalike-audience upload specifications for hashing adequacy, PII field scope, consent-basis validity, and platform data-sharing restrictions before upload to Meta, Google, LinkedIn, or TikTok — catching underhashed identifiers, consent-scope mismatches, and re-identification surfaces.",
+  "source_type": "original",
+  "official_docs": [
+    "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679",
+    "https://oag.ca.gov/privacy/ccpa",
+    "https://www.ftc.gov/reports/data-brokers-call-transparency-accountability",
+    "https://developers.facebook.com/docs/marketing-api/audiences/guides/custom-audiences/",
+    "https://support.google.com/google-ads/answer/6334160"
+  ],
+  "security_notes": "Custom-audience uploads transmit hashed personal data to ad platforms under data-sharing arrangements that must have a lawful basis, appropriate consent scope, and adequate pseudonymization. Review works from sanitized field-mapping specifications, declared hashing methods, and consent-basis documentation only; never request actual audience files, real customer records, or platform API credentials.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/lookalike-audience-upload-compliance-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/marketing/lookalike-audience-upload-compliance-review/references/workflow-and-output.md

@@ -0,0 +1,203 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized documents (replace real records with schema descriptions; no actual customer PII, no platform API credentials):
+- Audience upload field-mapping specification (CSV column headers, platform upload template, or field list with data types)
+- Declared hashing method (algorithm, whether hashing occurs client-side or server-side, and normalization steps applied before hashing)
+- Consent-basis documentation (privacy notice excerpt, consent-collection mechanism, opt-in/opt-out flow, original collection purpose)
+- Originating list segment metadata (how the list was segmented, which customer population it covers, what action or consent triggered inclusion)
+- Target platform(s) (Meta, Google, LinkedIn, TikTok, or DSP)
+- Whether EU or California resident data subjects are included
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Platform identification and terms baseline
+
+Identify the target platform and retrieve the relevant customer-list terms:
+
+```text
+Meta Custom Audiences: Prohibit sensitive categories (health, financial account data, sexual orientation,
+  religious beliefs, political views, union membership, biometric data, criminal records, or data from
+  users under 13). Require SHA-256 hashing of email, phone, name. Normalize before hashing
+  (lowercase, no spaces).
+
+Google Customer Match: Prohibit sensitive-category data. Require SHA-256 hashing. Normalization
+  required per Google's specification (lowercase email, E.164 phone format before hashing).
+
+LinkedIn Matched Audiences: Prohibit sensitive categories. Require SHA-256. Minimum list size
+  enforced for privacy (300 matched members).
+
+TikTok Custom Audiences: Require SHA-256. Prohibit sensitive categories. GDPR and CCPA
+  compliance certifications required for respective geographies.
+```
+
+Note any field in the specification that appears to violate platform-specific prohibitions.
+
+### Step 3 — Hashing adequacy audit
+
+Inspect the declared hashing method against minimum requirements:
+
+```text
+# HIGH — MD5 hashing declared
+MD5 produces a 128-bit digest. For common email formats (first.last@domain.com),
+precomputed rainbow tables resolve ~80-90% of hashes. This is not adequate pseudonymization
+under GDPR Article 5(1)(f) and violates platform terms for Meta, Google, LinkedIn, and TikTok.
+Remediation: Replace MD5 with SHA-256. Apply normalization (lowercase, trim whitespace) before hashing.
+
+# HIGH — plain-text upload (no hashing declared)
+Direct transmission of email or phone in the clear constitutes unambiguous PII disclosure
+to the ad platform. No platform terms permit this.
+
+# MEDIUM — SHA-256 declared but normalization step not documented
+Without documented normalization (lowercase, strip punctuation), match rates degrade and
+partial hash collisions become possible. Confirm normalization spec.
+
+# CORRECT — SHA-256 with documented normalization
+Email: lowercase → strip whitespace → SHA-256
+Phone: E.164 format → strip non-numeric → SHA-256
+```
+
+Hashing reduces re-identification risk but does not eliminate it — flag this explicitly. Hashed identifiers are still personal data under GDPR.
+
+### Step 4 — PII field-scope and data-minimization audit
+
+Inspect the field mapping for over-inclusion relative to the matching objective:
+
+```text
+# Minimum field set for match-rate adequacy (any platform)
+- SHA-256 hashed email  ← sufficient for >85% match rates on most platforms
+
+# Extended field set (justified only when match rate is demonstrably inadequate)
+- SHA-256 hashed phone number
+- SHA-256 hashed first name + last name (separate fields per platform spec)
+
+# Over-included fields (data-minimization violation)
+- Date of birth → not needed for matching; increases re-identification
+- Home postal code → combined with email + phone = high-confidence re-identification surface
+- Transaction history columns → no matching function; pure data exposure
+- IP address → not a valid matching identifier; exposes behavioral fingerprint
+```
+
+Flag any field beyond the minimum set needed for the stated matching objective as MEDIUM. Flag postal code combined with email and phone as HIGH (re-identification surface).
+
+### Step 5 — Consent-basis validity audit
+
+Map the originating consent basis against the intended use:
+
+```text
+Scenario A — Transactional consent only
+Original consent: "I agree to receive order confirmations and shipping updates."
+Intended use: Seed list for Facebook lookalike audience targeting financial product ads.
+Assessment: HIGH — sharing for advertising targeting exceeds the transactional consent scope.
+GDPR: Purpose-limitation violation (Article 5(1)(b)). Separate consent for advertising use required.
+CPRA: Unauthorized "sharing" of personal information for cross-context behavioral advertising
+      (§1798.100) — constitutes a sale/share requiring opt-out mechanism.
+
+Scenario B — Marketing consent with opt-in
+Original consent: "I agree to receive marketing communications from [Brand]."
+Intended use: Custom audience upload for retargeting on Meta.
+Assessment: MEDIUM — first-party retargeting may fall within scope, but sharing PII with Meta
+            as a data controller may require separate disclosure in the privacy notice.
+            Confirm whether privacy notice discloses ad-platform data sharing.
+
+Scenario C — No documented consent, legitimate interest asserted
+Assessment: HIGH — legitimate interest is a narrow basis that rarely survives for ad-platform
+            data sharing. LIA (Legitimate Interest Assessment) must be documented; data-subject
+            rights (opt-out, erasure) must be honored.
+```
+
+### Step 6 — Cross-border transfer assessment
+
+If EU resident data subjects are in the list and the ad platform is a non-adequate-country processor:
+
+```text
+# Required safeguards for EU → US transfer (post-Schrems II)
+- Standard Contractual Clauses (SCCs) — Module 2 (controller to processor) or
+  Module 1 (controller to controller depending on platform's legal role)
+- UK Addendum if UK residents included
+- Transfer Impact Assessment (TIA) documented
+
+# HIGH — EU residents in list, no SCC or EU-US DPF certification documented for the platform
+GDPR Chapter V prohibits transfer without adequate safeguard. Confirm platform's DPF
+certification status or execute SCCs before upload.
+```
+
+### Step 7 — Platform-specific sensitive-category restriction check
+
+Cross-check each field against platform-specific prohibited categories:
+
+| Field | Meta | Google | LinkedIn | TikTok |
+|---|---|---|---|---|
+| Health condition inferred from segment | PROHIBITED | PROHIBITED | PROHIBITED | PROHIBITED |
+| Financial hardship segment label | PROHIBITED | PROHIBITED | Review | Review |
+| Religious affiliation in segment metadata | PROHIBITED | PROHIBITED | PROHIBITED | PROHIBITED |
+| Age (exact DOB) | Allowed (hashed) | Allowed (hashed) | Caution | Caution |
+| Postal code (unhashed) | Not a match field | Not a match field | Not a match field | Not a match field |
+
+Flag any field or segment label that maps to a platform-prohibited category.
+
+### Step 8 — Retention and deletion assessment
+
+Flag the absence of documented platform-side retention limits as MEDIUM:
+
+- Confirm the platform's stated retention period for unmatched records (typically 48-72 hours for most platforms).
+- Confirm whether the operator has a deletion schedule for the source list post-upload.
+- Confirm whether the list can be deleted from the platform after campaign completion.
+
+### Step 9 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<field-mapping spec provided | hashing method declared | consent documentation provided | inference>
+
+## Platform(s) in scope
+<Meta | Google | LinkedIn | TikTok | DSP>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Recommended minimum field set
+<field list with hashing spec>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security and scope notes
+
+- This is a static review. Never request actual audience files, real customer records, or platform API credentials. Work from sanitized field-mapping specifications, declared hashing methods, and consent-basis documentation.
+- SHA-256 hashing of a common email address is pseudonymization, not anonymization — the hashed identifier is still personal data under GDPR and still requires a lawful basis for sharing with the ad platform.
+- A consent-scope mismatch discovered here may constitute a reportable breach or an unauthorized "sale/share" of personal information under CPRA — flag that possibility and route the legal determination to qualified counsel and the privacy compliance team.
+- Never recommend uploading a field that is not strictly needed for the matching objective. Default to the minimum field set.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.

package/skills/marketing/marketing-consent-data-collection-review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: marketing-consent-data-collection-review
+description: Use this skill when reviewing a marketing site's consent and data-collection posture — cookie/consent banner (CMP) configuration, tag-manager container exports, Google Consent Mode wiring, or a cookie policy. Trigger when a user provides a CMP configuration, a tag manager container JSON, a consent-banner screenshot description, or asks whether their marketing tracking is GDPR/CCPA/ePrivacy compliant, whether tags fire before consent, or whether their opt-out path is valid.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Marketing Consent and Data-Collection Review
+
+## Purpose
+This skill reviews the consent and data-collection layer of a marketing site for regulatory correctness, coverage gaps, and dark-pattern risk. Marketing analytics and advertising tags are a primary enforcement target under GDPR, the ePrivacy Directive, and US state privacy laws (CCPA/CPRA and successors). A tag that fires before a consent signal, a banner with no symmetric reject control, or a missing "Do Not Sell or Share" path converts routine marketing instrumentation into a regulatory liability and a class-action surface. The review catches consent-gating failures, banner dark patterns, Consent Mode misconfiguration, undeclared trackers, and cross-border transfer gaps before they reach production.
+
+## Lean operating rules
+- Treat any analytics or advertising tag that fires before an explicit opt-in consent signal (in a GDPR/ePrivacy-scoped jurisdiction) as HIGH — prior consent is required before non-essential storage or access.
+- Treat a consent banner with no reject control, or a reject control that takes more clicks or less visual weight than accept, as HIGH — non-symmetric choice is a recognized dark pattern and invalidates consent.
+- Treat pre-ticked consent checkboxes or "consent by continued browsing / scrolling" as HIGH — neither is freely given, specific, informed, and unambiguous consent.
+- Treat the absence of a "Do Not Sell or Share My Personal Information" link or an equivalent opt-out preference signal path (Global Privacy Control honoring) as HIGH for sites serving California or other opt-out-regime traffic.
+- Treat Google Consent Mode left in its default-granted state, or implemented without `wait_for_update`, as HIGH — tags transmit before the consent decision is captured.
+- Treat trackers observed in the tag container that are not disclosed in the cookie policy or consent vendor list as HIGH — undisclosed processing has no lawful basis.
+- Flag a single global consent toggle with no per-purpose granularity (analytics vs advertising vs personalization) as MEDIUM — purpose-bundled consent is not specific.
+- Flag consent records with no retention of timestamp, scope, and consent-string version as MEDIUM — without a consent record the controller cannot demonstrate compliance.
+- Flag advertising tags that send data to ad networks in non-EEA jurisdictions with no referenced transfer mechanism as MEDIUM.
+- Do not recommend disabling a tag without naming the marketing measurement it supports and the residual attribution loss.
+- Label every finding with evidence basis: configuration provided, policy text provided, documentation-based, or inference from missing config.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Consent-gating findings (tags firing before the consent signal)
+- Banner design assessment (symmetry, granularity, dark-pattern checks)
+- Opt-out / Global Privacy Control path assessment
+- Consent Mode / tag-manager wiring findings
+- Tracker-to-policy disclosure gap list
+- Cross-border transfer assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/marketing-consent-data-collection-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "marketing-consent-data-collection-review",
+  "name": "Marketing Consent and Data-Collection Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review marketing consent and data-collection posture — CMP banner config, tag-manager containers, Consent Mode wiring, and cookie policy — for GDPR/ePrivacy/CCPA correctness, dark patterns, and undisclosed trackers.",
+  "source_type": "original",
+  "official_docs": [
+    "https://eur-lex.europa.eu/eli/reg/2016/679/oj",
+    "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058",
+    "https://oag.ca.gov/privacy/ccpa",
+    "https://developers.google.com/tag-platform/security/guides/consent",
+    "https://iabeurope.eu/transparency-consent-framework/"
+  ],
+  "security_notes": "Marketing tags that fire before a consent signal collect personal data with no lawful basis and expose the controller to GDPR/ePrivacy enforcement and CCPA class actions. Consent banners with non-symmetric choice or pre-ticked boxes invalidate consent. Review works from sanitized configuration only; never request real visitor data, consent-string archives, or analytics account credentials.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/marketing-consent-data-collection-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/marketing/marketing-consent-data-collection-review/references/workflow-and-output.md

@@ -0,0 +1,139 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized exports or descriptions (no real visitor identifiers, no analytics account credentials, no consent-string archives):
+- Consent Management Platform (CMP) configuration — vendor, banner layout, button set, default consent state, per-purpose toggles
+- Tag manager container export (e.g. GTM container JSON) showing tags, triggers, and consent settings
+- Google Consent Mode / consent initialization snippet
+- Cookie / privacy policy text, or the disclosed cookie and vendor table
+- Target jurisdictions and the regimes that apply (EEA/UK, California, other US states, Brazil, etc.)
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Jurisdiction and regime scoping
+
+Establish which legal model applies before assessing tags:
+- **Opt-in regimes** (GDPR + ePrivacy, UK GDPR/PECR): non-essential storage and access require prior consent. Default state must be denied.
+- **Opt-out regimes** (CCPA/CPRA and most US state laws): collection may proceed, but a "Do Not Sell or Share" path and Global Privacy Control honoring are required.
+- A global site usually serves both; the CMP must geo-resolve the correct model per visitor.
+
+Flag a single consent model applied globally when traffic spans both regimes as MEDIUM.
+
+### Step 3 — Consent-gating audit
+
+For every analytics and advertising tag, determine whether it fires before or after the consent signal.
+
+Check for:
+- Tags with a firing trigger of "page view" / "DOM ready" and no consent condition (HIGH in opt-in regimes)
+- Tag manager "additional consent checks" left unconfigured
+- A hardcoded analytics or pixel snippet in page source, bypassing the tag manager and the CMP entirely (HIGH)
+- Server-side tagging that forwards events with no consent state propagated
+
+```text
+# RISKY — tag fires on every page view, no consent gate
+Tag: GA4 Configuration
+Trigger: All Pages
+Consent settings: No additional consent required
+
+# CORRECT — tag waits for the analytics_storage grant
+Tag: GA4 Configuration
+Trigger: All Pages
+Consent settings: Require additional consent for: analytics_storage
+```
+
+### Step 4 — Banner design audit
+
+Assess the banner against recognized dark-pattern guidance:
+- **Symmetry**: accept and reject must be equally prominent and equally reachable. A prominent "Accept All" with reject buried in a secondary "Manage" screen is HIGH.
+- **Pre-selection**: any consent toggle pre-set to ON, or pre-ticked checkbox, is HIGH.
+- **Implied consent**: "by continuing to browse you agree" or scroll-to-consent is HIGH.
+- **Granularity**: distinct purposes (analytics, advertising, personalization) must be independently refusable. A single on/off is MEDIUM.
+- **Nagging / re-prompting**: re-showing the banner to pressure a reluctant visitor is MEDIUM.
+- **Withdrawal**: withdrawing consent must be as easy as giving it — a persistent preferences link must exist.
+
+### Step 5 — Consent Mode and signal-propagation audit
+
+If Google Consent Mode (or an equivalent) is used:
+- Default consent state must be `denied` for `ad_storage`, `analytics_storage`, `ad_user_data`, `ad_personalization` in opt-in regimes.
+- `wait_for_update` must be set so tags hold until the CMP resolves the choice.
+- Verify the CMP actually calls `gtag('consent', 'update', ...)` on the visitor's decision.
+
+```text
+# RISKY — default granted, no wait
+gtag('consent', 'default', { ad_storage: 'granted', analytics_storage: 'granted' });
+
+# CORRECT — default denied, wait for the CMP update
+gtag('consent', 'default', {
+  ad_storage: 'denied', analytics_storage: 'denied',
+  ad_user_data: 'denied', ad_personalization: 'denied',
+  wait_for_update: 500
+});
+```
+
+### Step 6 — Tracker-to-policy disclosure audit
+
+Cross-check every tracker observed in the container against the cookie policy and CMP vendor list:
+- Each cookie and pixel must be named, categorized by purpose, and given a stated retention.
+- Vendors receiving data must appear in the disclosed vendor list.
+- A tracker present in the container but absent from disclosure is HIGH — undisclosed processing has no lawful basis and breaches the transparency obligation.
+
+### Step 7 — Opt-out and cross-border audit
+
+- Confirm a "Do Not Sell or Share My Personal Information" link (or a Limit-Use link for sensitive data) where opt-out regimes apply.
+- Confirm the CMP honors the Global Privacy Control browser signal.
+- For advertising tags transmitting to ad networks outside the visitor's region, confirm a referenced transfer mechanism exists in the policy (Standard Contractual Clauses, an adequacy decision, or the relevant framework).
+
+### Step 8 — Consent-record audit
+
+Confirm the CMP retains, per consent event: a timestamp, the scope/purposes accepted, the consent-string version, and a withdrawal record. Without this the controller cannot demonstrate compliance on request. Missing records is MEDIUM.
+
+### Step 9 — Produce the output
+
+Format findings using the Output section below.
+
+---
+
+## Output
+
+Return findings in this structure:
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<configuration provided | policy text provided | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security and scope notes
+
+- This is a static review. Never request real visitor data, raw consent-string archives, analytics account credentials, or tag-manager publish access.
+- Do not provide definitive legal conclusions; surface regulatory risk and route binding determinations to qualified privacy counsel.
+- Never recommend removing a consent gate to recover attribution data.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.

package/skills/marketing/marketing-conversion-flow-dark-pattern-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: marketing-conversion-flow-dark-pattern-review
+description: Use this skill when reviewing marketing conversion flow specifications — subscription sign-up, upsell interstitial, free-trial enrollment, and cancellation path — for dark-pattern practices that invalidate consent or constitute unfair or deceptive acts under FTC Section 5 and state privacy laws. Trigger when a user provides a UX flow specification including step-by-step page descriptions, annotated wireframes, CTA labels, pre-checked options, visual weight of accept vs decline paths, countdown timer specs, or cancellation flow step counts. Scope is limited to marketing conversion flows; consent banner review is handled by a separate skill.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Marketing Conversion Flow Dark-Pattern Review
+
+## Purpose
+This skill reviews marketing conversion flow specifications — subscription sign-up, upsell interstitials, free-trial enrollment, and cancellation paths — for dark-pattern practices that invalidate consent or constitute unfair or deceptive acts under FTC Section 5, the FTC Negative Option Rule (ROSCA), the CPRA statutory dark-pattern definition (§ 1798.140(l)), and EU AI Act Article 5(1)(b). Dark patterns in conversion flows are a distinct and high-priority regulatory surface: pre-checked auto-renew boxes, asymmetric cancel vs. subscribe step counts, artificial countdown timers, and visually suppressed decline paths have drawn FTC enforcement, FTC rules with click-to-cancel mandates, and CPRA enforcement advisories. This skill works from a sanitized UX flow specification or annotated wireframe only. It does not review consent banners — that is the domain of `marketing-consent-data-collection-review`.
+
+## Lean operating rules
+- Treat a free-trial or subscription enrollment flow that pre-checks "auto-renew at full price" (or any material recurring-charge term) as HIGH — pre-checked consent for a recurring financial commitment is prohibited under the FTC Negative Option Rule and invalidates consent under CPRA § 1798.140(l).
+- Treat any cancellation path that requires more steps than the enrollment path, or that interposes save-offers between the cancel intent and the cancel confirmation without a direct-cancel alternative, as HIGH — the FTC Negative Option Rule and ROSCA require cancellation to be at least as easy as enrollment.
+- Treat an artificial countdown timer applied to an offer with no real deadline as HIGH — it creates false urgency, a deceptive act under FTC Act Section 5.
+- Treat visual suppression of the decline path (smaller font, lower contrast, grey-out, positioning below the fold, or absence of a visible "no thanks" option) as HIGH when paired with a visually dominant accept CTA — asymmetric visual weight subverts user autonomy under CPRA § 1798.140(l) and constitutes a deceptive format under FTC Section 5.
+- Treat upsell interstitials that make the "continue without upgrade" option absent, invisible, or materially harder to reach than the upgrade CTA as HIGH — the absence of a clear decline path on a mandatory interstitial eliminates meaningful consent.
+- Treat a subscription sign-up flow in which material price, renewal date, and cancellation method are not disclosed clearly and conspicuously before billing information is collected as HIGH — ROSCA requires pre-billing disclosure of all material terms.
+- Flag "confirm-shaming" CTA copy (e.g. "No thanks, I don't want to save money") as MEDIUM — it applies social pressure but may not alone constitute an unfair act; combined with visual suppression it escalates.
+- Flag any save-offer sequence on a cancellation path that does not offer a direct cancel option at each step as MEDIUM — save offers are permissible but must not be the only route.
+- Flag countdown timers whose real deadline is authenticated by server state (session-scoped) as LOW — distinguish from artificial timers which are HIGH.
+- Do not recommend removing a conversion step without naming the revenue or data-collection impact and an FTC-compliant alternative.
+- Label every finding with evidence basis: flow specification provided, wireframe provided, documentation-based, or inference from missing element.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- Pre-checked consent assessment (recurring-charge terms, auto-renew)
+- Cancellation path symmetry assessment (step count vs. enrollment path)
+- Countdown timer authenticity assessment
+- Visual weight and decline-path accessibility assessment
+- Upsell interstitial consent assessment
+- Material-term pre-billing disclosure assessment
+- Confirm-shaming CTA assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/marketing-conversion-flow-dark-pattern-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "marketing-conversion-flow-dark-pattern-review",
+  "name": "Marketing Conversion Flow Dark-Pattern Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review marketing conversion flow specifications — subscription sign-up, upsell interstitial, free-trial enrollment, and cancellation path — for dark-pattern practices that invalidate consent or constitute unfair or deceptive acts under FTC Section 5, the FTC Negative Option Rule, CPRA, and EU AI Act Article 5(1)(b).",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.ftc.gov/legal-library/browse/rules/negative-option-rule",
+    "https://www.ftc.gov/system/files/ftc_gov/pdf/P214800+Dark+Patterns+Report+9.14.2022+-+FINAL.pdf",
+    "https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.140.",
+    "https://oag.ca.gov/privacy/ccpa",
+    "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng"
+  ],
+  "security_notes": "Read-only static review of sanitized UX flow specifications and annotated wireframes only. Never request real payment credentials, live user-session data, or production A/B-test results. Findings may indicate violations of FTC rules carrying civil penalties — route remediation and enforcement-risk assessment to qualified legal counsel before acting on findings.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/marketing-conversion-flow-dark-pattern-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}