@raishin/vanguard-frontier-agentic 2.0.0 → 2.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"
+}

package/skills/marketing/marketing-conversion-flow-dark-pattern-review/references/workflow-and-output.md

@@ -0,0 +1,160 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide a sanitized UX flow specification covering one or more of the following conversion surfaces (replace real copy with representative placeholders; no real payment data, session tokens, or A/B-test PII):
+
+- Step-by-step page descriptions for the subscription sign-up or free-trial enrollment flow, including CTA labels and button visual weight
+- Step-by-step page descriptions for the cancellation path, including step count and any save-offer interstitials
+- Upsell interstitial specifications, including whether a "continue without upgrade" option exists and its visual treatment
+- Pre-checked option inventory (checkboxes, toggles, radio buttons preselected at page load)
+- Countdown timer specifications (trigger condition, timer source — server-side session or client-side arbitrary duration, reset behavior)
+- Visual hierarchy notes: font size, color contrast, and positioning of accept vs. decline CTAs
+
+If the user provides only a partial set, note which surfaces are absent and scope findings accordingly. Do not attempt to infer full flow structure from a single page description.
+
+This skill does not review consent banners or cookie notices — defer those to `marketing-consent-data-collection-review`.
+
+### Step 2 — Pre-checked consent audit
+
+Inspect every option that is pre-checked or preselected at page load and assess what obligation or charge it creates:
+
+```text
+# HIGH — auto-renew pre-checked on free-trial enrollment form
+[✓] Automatically renew at $29.99/month after trial ends
+    (checkbox is below the fold; CTA reads "Start Free Trial")
+
+# COMPLIANT — opt-in explicitly unchecked, above the fold
+[ ] Add annual plan upgrade at $9.99/month
+```
+
+Specifically flag:
+- Any pre-checked option that binds the user to a recurring financial charge without affirmative action — prohibited under the FTC Negative Option Rule and invalidates CPRA consent.
+- Pre-checked add-ons, SMS marketing, or data-sharing agreements — these require affirmative consent under CPRA § 1798.140(l) and FTC Act Section 5.
+- Whether material terms (price, renewal date, cancellation method) appear clearly and conspicuously before billing information is requested — ROSCA pre-billing disclosure requirement.
+
+### Step 3 — Cancellation path symmetry audit
+
+Count and compare steps:
+
+```text
+Enrollment path: Landing → Plan select → Account create → Payment → Confirm  (4 decision steps)
+Cancellation path: Account → Settings → Cancel? → Save offer 1 → Save offer 2 → Confirm cancel  (5 decision steps)
+```
+
+Flag as HIGH when:
+- Cancellation requires more decision steps than enrollment.
+- Save-offer interstitials appear without a direct "Cancel anyway" option at each step, forcing the user through the entire save sequence before reaching a cancel confirmation.
+- The cancellation entrypoint is buried in account settings more than two levels deep while enrollment is available from the top-level navigation or homepage.
+
+Flag as MEDIUM when:
+- Save-offer interstitials appear but each step offers a clear "Cancel anyway" option alongside the save offer.
+- Cancellation requires the same step count as enrollment but save offers add latency without hiding the exit.
+
+Note: The FTC Negative Option Rule (effective May 14, 2025) requires simple cancellation through the same mechanism as enrollment, and cancellation must be at least as easy as enrollment.
+
+### Step 4 — Countdown timer authenticity audit
+
+For every countdown timer in the flow, assess whether the deadline is real:
+
+```text
+# HIGH — client-side timer resets on page reload; offer is always available
+"Offer expires in 09:47" — timer resets to 10:00 on browser refresh
+→ Artificial urgency; no real deadline; deceptive act under FTC Act Section 5.
+
+# LOW — server-side session timer; offer genuinely expires at session end
+"Your reserved cart expires in 14:53" — server validates expiry at checkout
+→ Real deadline; authenticate in server logs; document expiry logic.
+```
+
+Distinguish: a timer whose deadline is backed by server state and enforced at checkout is a legitimate scarcity signal. A timer that resets, never expires, or applies to an always-available offer is a fabricated urgency device — HIGH.
+
+### Step 5 — Visual weight and decline-path audit
+
+Assess the visual treatment of accept vs. decline paths:
+
+```text
+# HIGH — decline option visually suppressed
+[Start Free Trial — large, blue, full-width button]
+[no, I don't want savings — 11px grey text, below fold]
+
+# COMPLIANT — balanced visual weight
+[Start Free Trial]   [No thanks]   (equal size, both above fold)
+```
+
+Flag as HIGH when:
+- The decline or "no thanks" option is absent, below the fold, or uses a contrast ratio below 4.5:1 while the accept CTA uses high-contrast primary styling.
+- The accept CTA is a full-width button while the decline option is a text link, creating materially asymmetric affordance.
+
+Flag as MEDIUM when:
+- Confirm-shaming copy ("No thanks, I prefer to pay more") is used — note it may escalate to HIGH in combination with visual suppression.
+
+### Step 6 — Upsell interstitial consent audit
+
+For each upsell interstitial (a mandatory step between enrollment start and confirmation):
+
+- Confirm a "continue without upgrade" option exists and is reachable without completing the upsell flow.
+- Assess whether the interstitial can be bypassed or only dismissed — a mandatory interstitial with no decline path eliminates meaningful consent.
+- Confirm the interstitial does not pre-check the upgrade or add charges to the user's cart without affirmative action.
+
+An upsell interstitial with no bypass is HIGH — the user cannot consent to the base product without also being offered (and potentially trapped in) the upsell.
+
+### Step 7 — Material-term pre-billing disclosure audit
+
+Before any billing information is collected, confirm the flow discloses clearly and conspicuously:
+- The price and billing frequency after any trial period.
+- The exact trial period length and the date on which recurring charges begin.
+- How to cancel and through what mechanism.
+
+ROSCA requires these disclosures before collecting billing information. Absence or relegation to fine print is HIGH.
+
+### Step 8 — 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
+<flow specification provided | wireframe provided | documentation-based | inference from missing element>
+
+## 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 of a sanitized artifact. Never request real payment credentials, live user-session recordings, or production A/B-test data containing real user identities.
+- Findings indicating violation of the FTC Negative Option Rule carry civil penalty exposure — route enforcement-risk assessment to qualified legal counsel before acting on findings. Do not quantify penalty exposure yourself.
+- This skill is scoped to marketing conversion flows: sign-up, upsell, free-trial, and cancellation. Consent banners and cookie notices are out of scope — refer to `marketing-consent-data-collection-review`.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.
+- A flow that is FTC-compliant under the Negative Option Rule may still violate CPRA or EU AI Act Article 5(1)(b) — assess each regulatory frame independently.

package/skills/marketing/marketing-email-list-retention-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: marketing-email-list-retention-review
+description: Use this skill when reviewing marketing email list segment metadata, consent-record completeness, suppression-list coverage, and documented data-retention schedules for GDPR storage-limitation, CASL record-keeping, and CCPA deletion-right compliance. Trigger when a user provides a CRM or ESP export of list segment metadata fields — consent source, consent timestamp, last-engagement date, subscription status, suppression-list entries — plus the organization's documented email data-retention policy, and asks whether the stored list inventory and retention posture meets regulatory obligations.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Marketing Email List Retention Review
+
+## Purpose
+This skill reviews the stored email list inventory and retention posture of a marketing program against GDPR storage-limitation (Article 5(1)(e)), accountability (Article 5(2)), and erasure (Article 17) obligations; CASL section 6 consent requirements and section 11 three-year record-keeping mandate; and CCPA/CPRA section 1798.105 deletion rights. Marketing email lists accumulate contacts whose consent may have lapsed, whose consent source was never recorded, or who were deleted from the CRM but remain in a detached suppression list — all conditions that expose the controller to regulatory enforcement and litigation. This review assesses the metadata fields of an exported list segment, not the consent banner or collection mechanism (defer that to `marketing-consent-data-collection-review`), and it does not process real subscriber PII.
+
+## Lean operating rules
+- Treat contacts with consent timestamps older than 36 months with no documented re-engagement or re-permission event as HIGH — CASL §11 requires demonstrable consent records covering the entire send period, and a gap breaks the chain of proof.
+- Treat any active-send segment where a material proportion of contacts (assess whether the proportion is notable relative to the list size) have no consent-source field populated as HIGH — the controller cannot demonstrate lawful basis, violating GDPR Article 5(2) accountability.
+- Treat suppression lists stored in a separate system with no documented automated sync cadence as HIGH — contacts deleted or unsubscribed from the primary CRM may re-enter active sends through list imports, segment refreshes, or CRM migrations.
+- Treat contacts for whom a deletion request was received but whose record persists beyond the organization's documented deletion SLA as HIGH — a GDPR Article 17 and CCPA §1798.105 violation in progress.
+- Treat a retention schedule that sets no maximum age for active-send contacts, or that retains suppressed contacts beyond what is necessary to enforce suppression, as MEDIUM — GDPR Article 5(1)(e) requires data be kept no longer than necessary.
+- Treat the absence of a last-engagement date field, or engagement dates older than the stated re-permission interval with no re-permission event recorded, as MEDIUM — these contacts may lack a legitimate-interest or consent basis for continued sends.
+- Treat consent-source values that are free-text or inconsistently coded (preventing automated compliance queries) as MEDIUM — the controller must be able to demonstrate lawful basis programmatically at scale.
+- Treat the absence of a documented re-permission workflow for lapsing or aged consent as MEDIUM — without a scheduled re-permission program, the list will accumulate non-compliant contacts over time.
+- Flag any segment exported for a third-party send partner where the third-party processor agreement or data-sharing basis is absent from the metadata as MEDIUM.
+- Label every finding with evidence basis: export provided, policy document provided, documentation-based, or inference from missing fields.
+- Do not recommend deleting contacts without first confirming whether suppression-list entries are needed for ongoing suppression enforcement.
+
+## 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-record completeness findings (consent-source field population, timestamp age, re-permission events)
+- CASL record-keeping assessment (three-year demonstrability of consent)
+- GDPR storage-limitation and erasure findings (retention schedule, deletion-request SLA)
+- CCPA deletion-right posture
+- Suppression-list sync and integrity assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/marketing-email-list-retention-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "marketing-email-list-retention-review",
+  "name": "Marketing Email List Retention Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review marketing email list segment metadata, consent-record completeness, suppression-list coverage, and data-retention schedules for GDPR, CASL, and CCPA deletion-right compliance.",
+  "source_type": "original",
+  "official_docs": [
+    "https://gdpr-info.eu/art-5-gdpr/",
+    "https://gdpr-info.eu/art-17-gdpr/",
+    "https://laws-lois.justice.gc.ca/eng/acts/C-28.65/page-1.html",
+    "https://oag.ca.gov/privacy/ccpa",
+    "https://www.canada.ca/en/radio-television-telecommunications/news/2014/07/compliance-and-enforcement-information-bulletin-crtc-2014-326.html"
+  ],
+  "security_notes": "Review works from sanitized CRM/ESP exports only — placeholder values for email addresses, subscriber IDs, and timestamps. Never accept real subscriber PII, live CRM credentials, or ESP API keys. Findings of missing consent records or absent suppression-list sync may constitute an ongoing GDPR or CASL violation requiring legal escalation.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/marketing-email-list-retention-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/marketing/marketing-email-list-retention-review/references/workflow-and-output.md

@@ -0,0 +1,144 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized exports (replace real subscriber email addresses and IDs with placeholders; no real PII, no live CRM credentials):
+- CRM or ESP export of list segment metadata fields, including: consent source, consent timestamp, last-engagement date, subscription status, and suppression-list entry flag
+- The organization's documented email data-retention policy (maximum age for active contacts, suppression-list retention period, deletion-request SLA)
+- Any documented re-permission workflow or re-engagement schedule
+- Suppression-list storage and sync architecture (same system, separate file, sync cadence)
+- Third-party send partner list and data-sharing basis documentation
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Consent-record completeness audit
+
+For the exported segment, assess the completeness of consent records:
+- **Consent-source field**: Is it populated for all active-send contacts? What proportion have a blank or null value? A blank consent-source means the controller cannot demonstrate lawful basis for that contact — a GDPR Article 5(2) accountability failure.
+- **Consent-source values**: Are values standardized and machine-queryable (e.g., `website-signup-form-2024`, `trade-show-paper-form-2023`) or free-text and inconsistent? Inconsistent coding prevents automated compliance queries at scale.
+- **Consent timestamp**: Is it present for all contacts? Are any timestamps absent or obviously implausible (e.g., epoch zero, future dates)?
+
+```text
+# HIGH — material proportion of active-send contacts with blank consent_source
+contact_id  | consent_source | consent_timestamp   | status
+------------|----------------|---------------------|-------
+[ID-001]    | website-signup | 2022-03-14 09:00:00 | active
+[ID-002]    | (null)         | (null)              | active   ← no lawful basis
+[ID-003]    | (null)         | (null)              | active   ← no lawful basis
+
+# COMPLIANT — all active contacts have a consent source and timestamp
+[ID-004]    | trade-show-2024 | 2024-06-01 14:00:00 | active
+```
+
+### Step 3 — CASL three-year record-keeping audit
+
+CASL §11 requires that the organization be able to demonstrate consent for every commercial electronic message sent. The consent record must cover the entire period of the relationship:
+- Identify contacts whose earliest consent timestamp predates the review date by more than 36 months with no documented re-engagement or re-permission event in the intervening period.
+- Identify contacts whose consent basis is "implied" under CASL (e.g., existing business relationship) and assess whether the implied consent window (2 years) has expired.
+- A broken record chain — consent recorded, then a gap, then sends resumed without a re-permission event — is a CASL §6 violation for each message sent during the gap.
+
+```text
+# HIGH — consent older than 36 months, no re-permission event
+contact_id  | consent_timestamp   | last_repermission | months_since_consent
+------------|---------------------|-------------------|---------------------
+[ID-010]    | 2021-11-05 00:00:00 | (null)            | 42   ← CASL risk
+
+# COMPLIANT — re-permission event within 36-month window
+[ID-011]    | 2020-08-01 00:00:00 | 2024-01-15        | 69, re-permissioned
+```
+
+### Step 4 — GDPR storage-limitation and erasure audit
+
+GDPR Article 5(1)(e) requires personal data be kept no longer than necessary. Article 17 grants data subjects the right to erasure:
+- Review the documented retention policy: does it set a maximum age for active-send contacts? If no maximum age is defined, the list may accumulate contacts indefinitely — a storage-limitation failure.
+- Review the deletion-request SLA: does the policy commit to erasing (or suppressing) within 30 days? Are there contacts in the export whose deletion-request date plus the SLA has passed and who remain in an active segment?
+- Assess whether suppressed contacts are retained only as long as necessary to enforce ongoing suppression, and no longer.
+
+```text
+# HIGH — deletion request received, contact still active past SLA
+contact_id  | deletion_requested  | status | days_past_sla
+------------|---------------------|--------|---------------
+[ID-020]    | 2026-02-01          | active | 45   ← GDPR Art. 17 violation
+
+# MEDIUM — retention policy sets no maximum age
+retention_policy.max_active_contact_age = (not defined)
+```
+
+### Step 5 — CCPA/CPRA deletion-right posture
+
+California Consumer Privacy Act §1798.105 grants consumers the right to request deletion of their personal information. Assess:
+- Whether deletion requests from California residents result in removal from the active-send list within 45 days (or up to 90 days with notice of extension).
+- Whether the export shows any California-resident contacts (where identifiable by state field or domain inference) who submitted deletion requests and remain active.
+- Whether the suppression list is used to enforce deletion (preventing re-addition on next import) rather than merely removing the contact from one segment.
+
+### Step 6 — Suppression-list integrity audit
+
+The suppression list is the mechanism that enforces both unsubscribes and deletion requests. Weaknesses here cause compliance failures to recur:
+- Is the suppression list stored in the same system as the active-send list, or separately? A separately stored file that requires manual sync is HIGH — a missed sync cycle allows deleted or unsubscribed contacts to re-enter active sends.
+- What is the documented sync cadence? Real-time or near-real-time sync is the target; periodic batch sync introduces a window of non-compliance.
+- Is the suppression list checked against every list import and segment build, or only against scheduled sends? An import that bypasses the suppression check can re-add suppressed contacts silently.
+
+### Step 7 — Third-party send partner assessment
+
+If the segment metadata indicates sends to third-party partners or via third-party ESPs:
+- Confirm a data-processing agreement (DPA) or data-sharing agreement is documented for each partner.
+- Confirm that the consent scope collected covers the specific send type (e.g., consent to marketing emails from the controller does not automatically extend to sends on behalf of a partner brand).
+- Flag absent DPA documentation as MEDIUM.
+
+### Step 8 — Retention schedule and re-permission program assessment
+
+- Review whether the organization's documented policy includes a scheduled re-permission workflow for contacts approaching the consent-age threshold.
+- An absence of a re-permission program means the list will accumulate CASL-non-compliant contacts continuously over a 3-year cycle.
+- Flag the absence of a re-permission workflow as MEDIUM with a recommendation to implement a 30-month re-engagement trigger.
+
+### 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
+<export provided | policy document 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 of list segment metadata and retention policy documents. Never request real subscriber email addresses, real subscriber IDs, live CRM credentials, or live ESP API keys. Work from sanitized exports with placeholder values.
+- This skill reviews the stored list inventory and retention posture only. For consent collection mechanisms (banners, opt-in forms, consent strings), defer to `marketing-consent-data-collection-review`.
+- A finding of contacts persisting beyond a deletion-request SLA may constitute an ongoing Article 17 or CCPA §1798.105 violation. Surface this and route the determination and remediation to qualified legal counsel and the incident-response process.
+- Never recommend deleting suppression-list entries without confirming that the entries are not needed to enforce ongoing suppression — erasing suppression records can cause previously unsubscribed contacts to be re-added.
+- When evidence is partial (e.g., policy document provided but no export), scope each finding to the available evidence and state assumptions explicitly.
+- CASL record-keeping obligations extend to every commercial electronic message sent; a finding of a broken consent chain covers all messages sent during the gap, not just future sends.

package/skills/marketing/marketing-gpc-signal-honoring-review/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: marketing-gpc-signal-honoring-review
+description: Use this skill when reviewing the technical path by which a Global Privacy Control opt-out signal travels through the tag stack and CMP to determine whether ad tags, server-side forwarding, and conversion APIs actually cease firing. Trigger when a user provides a tag-manager container export, a CMP opt-out configuration, a server-side tag configuration, or asks whether their GPC implementation actually stops ad tags from firing, whether CPRA opt-out obligations are met technically, or whether the CMP acknowledges GPC but fails to suppress downstream tag execution.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Marketing GPC Signal Honoring Review
+
+## Purpose
+This skill reviews the technical signal path by which a Global Privacy Control (GPC) opt-out travels from the browser header through the consent management platform (CMP) and tag manager to determine whether ad tags, server-side conversion forwarding, and conversion API calls actually cease firing. GPC is a legally recognized opt-out signal under CPRA (Cal. Civ. Code §1798.135) and the California CPPA enforcement sweeps of September 2025 confirmed that acknowledging GPC in the CMP UI while failing to suppress downstream tag execution constitutes a violation. The review distinguishes between cosmetic compliance (the CMP reads the GPC header and sets a cookie) and substantive compliance (the GPC state variable gates every ad tag firing rule and every server-side forwarding path). It also catches the pre-first-visit gap: users who set GPC before arriving for the first time receive no opt-out cookie and are therefore not suppressed. Artifact inputs: tag-manager container export and CMP opt-out configuration, annotated with which firing rules reference the GPC/opt-out variable.
+
+## Lean operating rules
+- Treat ad conversion tags that remain in active firing rules with no GPC-state condition as HIGH — if the CMP acknowledges the opt-out in the UI but the tag-manager container has no GPC variable guard on those rules, the opt-out is not honored technically and constitutes a CPRA violation per CPPA Sept 2025 enforcement guidance.
+- Treat server-side conversion API events (Meta CAPI, Google Enhanced Conversions, TikTok Events API) forwarded from a first-party endpoint that bypasses the CMP entirely as HIGH — the first-party routing does not exempt the forwarding from opt-out obligations; the GPC state must be checked before forwarding occurs.
+- Treat a CMP that sets an opt-out cookie on opt-out but does not suppress tags for users who set GPC before their first visit (no prior consent record) as HIGH — pre-first-visit GPC must suppress all non-essential tags on the first page load, not only after cookie creation.
+- Treat CMP-acknowledged GPC that is not propagated as a boolean variable to the tag-manager firing rules as HIGH — CMP acknowledgment without tag-layer propagation leaves all existing rules unaffected.
+- Treat Opt Me Out Act (AB 566, Oct 2025) obligations for opt-out link placement as MEDIUM when the GPC signal path is technically broken — surfacing the link is insufficient if the signal is not honored downstream.
+- Flag ad tags that check a consent cookie but not the GPC header directly as MEDIUM — cookie-only checks fail for users who clear cookies but retain GPC, and for fresh sessions where no cookie yet exists.
+- Flag the absence of a documented test procedure confirming GPC suppression across the full tag list as MEDIUM — attestation of compliance requires evidence, not assumption.
+- Flag MEDIUM when server-side tag configurations do not log GPC-state at the time of forwarding — without logging, an enforcement sweep cannot demonstrate suppression.
+- Do not recommend disabling all tags as the remediation — identify the specific firing-rule conditions missing a GPC variable guard and propose the minimal surgical fix.
+- Label every finding with evidence basis: container provided, CMP config 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:
+- GPC variable propagation assessment (CMP to tag-manager variable layer)
+- Firing-rule guard assessment (which ad tags lack a GPC-state condition)
+- Server-side forwarding path assessment (CAPI, Enhanced Conversions, Events API bypass)
+- Pre-first-visit suppression assessment (fresh session with GPC, no prior cookie)
+- Opt Me Out Act link/signal consistency assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions