@raishin/vanguard-frontier-agentic 2.0.0 → 2.0.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@raishin/vanguard-frontier-agentic",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Cloud and zero-trust agentic workflow marketplace for skills, agents, rules, MCP references, and compliance-aware architecture.",
   "license": "Apache-2.0",
   "repository": {

package/plugins/vanguard-frontier-agentic/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "vanguard-frontier-agentic",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "Curated marketplace for cloud and zero-trust AI workflows. 331 agents, 286 skills, and rules across AWS, Azure, OCI, GCP, Alibaba Cloud, Huawei Cloud, Kubernetes, and Terraform.",
   "author": {
     "name": "Raishin",

package/skills/marketing/ai-advertising-targeting-fairness-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: ai-advertising-targeting-fairness-review
+description: Use this skill when reviewing ad-platform audience targeting configurations and declared AI feature usage for protected-class discrimination risk. Trigger when a user provides a Meta Ads Manager audience definition, Google Ads targeting layer export, DSP deal config, or any ad platform audience spec annotated with AI features enabled (Advantage+ Audience, broad match, automated bidding, lookalike seeds). Use when a campaign is in housing, credit, employment, or insurance verticals, or when automated bidding or AI audience expansion is active on any campaign reaching the US or EU and the user needs to assess Fair Housing Act, ECOA, or EU AI Act Article 5 exposure.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: ai
+  lifecycle: experimental
+---
+
+# AI Advertising Targeting Fairness Review
+
+## Purpose
+This skill reviews ad-platform audience targeting configurations and declared AI feature usage for protected-class discrimination risk under the Fair Housing Act (42 U.S.C. §3604), the Equal Credit Opportunity Act (ECOA), and EU AI Act Article 5. Ad platforms increasingly offer AI-driven audience expansion features — Meta Advantage+ Audience, Google broad match and Performance Max, DSP algorithmic deal targeting — that optimize delivery based on historical conversion patterns. When historical converters skew along protected-class lines (race, sex, age, national origin, familial status, disability, religion), algorithmic optimization propagates that skew without explicit intent. The review examines declared AI feature usage, audience seed composition, interest-segment proxy risk, and the absence of protected-category exclusion declarations on special-category campaigns before the configuration ships.
+
+## Lean operating rules
+- Treat Meta Advantage+ Audience enabled on a housing, credit, employment, or insurance campaign with no declared protected-category exclusions as HIGH — the system expands targeting beyond the declared audience using engagement signals that may correlate with race, sex, or national origin.
+- Treat interest-based segments that function as proxies for health conditions, religion, national origin, or familial status used on an insurance or financial-services campaign as HIGH — proxy targeting on protected classes is substantively equivalent to explicit targeting under FHA and ECOA case law.
+- Treat automated bidding (Target CPA, Target ROAS, Smart Bidding) optimizing a credit-offer, rental, or employment campaign on lookalike audiences seeded from historical converters as HIGH — disparate impact is propagated algorithmically when the seed population reflects historical discriminatory patterns.
+- Treat any AI-generated audience expansion (broad match, Performance Max audience signals, DSP algorithmic reach extension) active on a special-category campaign (housing, credit, employment, insurance) with no fairness audit trail as HIGH — the optimization objective does not include disparate-impact minimization.
+- Treat geofencing or geographic exclusion zones that closely follow racially or ethnically concentrated neighborhood boundaries on a housing or credit campaign as HIGH — geographic redlining is prohibited under FHA regardless of whether intent is declared.
+- Treat the absence of a Special Ad Category declaration on a Meta campaign reasonably classifiable as housing, employment, or credit as HIGH — the declaration unlocks mandatory fairness restrictions; omitting it circumvents them.
+- Flag automated bidding that optimizes on a conversion event defined as a past purchase or application when the historical converter population is not documented for demographic representativeness as MEDIUM — undocumented seed bias is a disparate-impact risk even when not yet proven.
+- Flag interest segments that include health-condition or medication-related categories on campaigns not in the healthcare vertical as MEDIUM — health proxies reach users based on inferred sensitive characteristics.
+- Flag AI feature disclosures that are absent or vague (e.g., "algorithmic optimization enabled" with no named feature, no version, no opt-out path) as MEDIUM — EU AI Act Article 13 and FTC guidance require meaningful transparency.
+- Do not recommend disabling AI features without naming the performance impact and the manual alternative that preserves reach.
+- Label every finding with evidence basis: audience spec provided, AI feature declaration 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:
+- AI feature inventory (named features enabled per campaign, evidence basis)
+- Special-category campaign detection (housing, credit, employment, insurance)
+- Protected-class proxy segment assessment (interest segments, lookalike seeds)
+- Algorithmic disparate-impact assessment (bidding, audience expansion)
+- Special Ad Category declaration check (Meta) or equivalent platform declaration
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/ai-advertising-targeting-fairness-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "ai-advertising-targeting-fairness-review",
+  "name": "AI Advertising Targeting Fairness Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review ad-platform audience targeting configurations and AI feature usage for protected-class discrimination risk under Fair Housing Act, ECOA, and EU AI Act Article 5 — proxy segments, algorithmic disparate impact, and missing Special Ad Category declarations.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.ftc.gov/business-guidance/blog/2023/02/ftcs-ai-related-enforcement-actions",
+    "https://www.hud.gov/program_offices/fair_housing_equal_opp/fair_housing_act_overview",
+    "https://www.consumerfinance.gov/about-us/blog/cfpb-issues-guidance-on-credit-denials-by-lenders-using-artificial-intelligence/",
+    "https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai",
+    "https://www.federalregister.gov/documents/2023/07/13/2023-14625/civil-rights-principles-for-the-use-of-artificial-intelligence"
+  ],
+  "security_notes": "Ad-platform AI features that optimize on historical converter populations can propagate protected-class disparate impact without explicit discriminatory intent. Review works from sanitized audience spec exports and declared AI feature annotations only; never request live campaign credentials, ad-account access tokens, or real user audience data.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/ai-advertising-targeting-fairness-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/marketing/ai-advertising-targeting-fairness-review/references/workflow-and-output.md

@@ -0,0 +1,150 @@
+# 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 values with placeholders; no real user PII, no ad-account credentials, no live audience membership data):
+- Ad platform audience definition export (Meta Ads Manager audience spec, Google Ads targeting layer export, DSP deal config)
+- Declared AI features enabled per campaign (e.g., Advantage+ Audience, broad match, Performance Max, Target CPA, automated bidding strategy)
+- Campaign vertical and ad category (housing, credit, employment, insurance, or other)
+- Seed-list demographics summary if a lookalike audience is in scope (aggregate only — no individual-level data)
+- Interest segment names or IDs included in the targeting stack
+- Platform Special Ad Category or equivalent fairness-restriction declaration, if any
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Campaign vertical classification
+
+Classify the campaign into a fairness-risk tier before inspecting AI features:
+
+- **Tier 1 — Special category** (highest risk): housing/rental, mortgage/credit, employment/hiring, insurance underwriting or pricing. FHA, ECOA, and analogous EU AI Act provisions impose the strictest obligations.
+- **Tier 2 — Sensitive adjacent**: health products, financial services (non-credit), legal services, political advertising. Protected-class proxies and automated decisions warrant careful scrutiny.
+- **Tier 3 — General commercial**: e-commerce, SaaS, entertainment. Standard fairness hygiene applies but special-category rules do not.
+
+Any Tier 1 campaign with AI-driven audience expansion enabled is HIGH by classification — proceed to Step 4 immediately.
+
+### Step 3 — AI feature inventory
+
+Enumerate every declared AI feature active on the campaign:
+
+```text
+# Example inventory table
+| Feature                  | Platform | Campaign     | Opt-out available? |
+|--------------------------|----------|--------------|-------------------|
+| Advantage+ Audience      | Meta     | Housing_Q2   | Partial           |
+| Target CPA bidding       | Google   | Credit_Lead  | Yes               |
+| Broad match keywords     | Google   | Credit_Lead  | Yes               |
+| Lookalike expansion L1   | Meta     | Housing_Q2   | No                |
+```
+
+For each feature, note: whether it expands beyond declared audience, what optimization signal it uses, and whether a fairness constraint or protected-category exclusion is declared.
+
+### Step 4 — Protected-class proxy segment audit
+
+Inspect interest and behavioral segments for protected-class proxy risk:
+
+```text
+# HIGH — health-condition proxy on insurance campaign
+Interest segment: "Diabetes management apps" → infers health condition → protected under ADA, ECOA
+
+# HIGH — national-origin proxy via language and cultural affinity targeting
+Interest segment: "Spanish-language content" + "Latin music" → national origin proxy on housing campaign
+
+# MEDIUM — general health interest segment on non-healthcare campaign
+Interest segment: "Fitness & wellness" → weaker proxy; flag for review but lower confidence
+```
+
+Flag segments that reliably infer race, sex, age, national origin, familial status, disability, or religion — even when those characteristics are not named explicitly.
+
+### Step 5 — Algorithmic disparate-impact assessment
+
+Assess whether automated bidding or audience expansion propagates historical bias:
+
+```text
+# HIGH — lookalike seeded from historical converters, no demographic audit
+Seed list: "past_mortgage_applicants_2019_2023"
+Lookalike: L1% similarity expansion
+Risk: If historical applicants skew by race or national origin, the lookalike inherits that skew.
+Mitigation: Demographic representativeness audit of seed list required.
+
+# HIGH — Target CPA on credit-offer campaign, conversion event = "application_submitted"
+Risk: CPA optimization deprioritizes delivery to audiences with lower historical application rates,
+      which may correlate with protected-class membership.
+```
+
+### Step 6 — Platform fairness-declaration check
+
+For Meta campaigns: confirm whether a Special Ad Category (Housing, Employment, Credit) is declared. Absence on a Tier 1 campaign is HIGH — it circumvents mandatory targeting restrictions.
+
+For Google: confirm whether Limited Ad Serving policies are acknowledged and whether sensitive-category restrictions are applied.
+
+For DSPs: confirm whether deal-level fairness constraints (e.g., no health-condition targeting, no age exclusions) are documented.
+
+### Step 7 — Geographic redlining check
+
+Inspect geofencing and location exclusions for patterns that trace protected-class neighborhood boundaries:
+
+```text
+# HIGH — exclusion zone matches historic redlining district boundaries
+Excluded ZIP codes: [10031, 10037, 10039] on NYC housing campaign
+These ZIPs are majority-minority neighborhoods; exclusion on a housing campaign = FHA §3604 risk.
+```
+
+Compare exclusion zones against publicly available fair-lending geography if the artifact suggests geographic selectivity.
+
+### 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
+<audience spec provided | AI feature declaration provided | documentation-based | inference>
+
+## Campaign tier
+<Tier 1 special-category | Tier 2 sensitive adjacent | Tier 3 general commercial>
+
+## AI feature inventory
+<table of features, platform, campaign, opt-out status>
+
+## 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 live campaign credentials, ad-account access tokens, real audience membership lists, or individual-level conversion data.
+- A finding here may constitute a fair lending, fair housing, or EU AI Act compliance violation — flag that possibility and route legal determination to qualified counsel and compliance teams. Do not make the legal determination yourself.
+- Algorithmic disparate impact is a legal theory that can apply even when no protected characteristic is named — proxy targeting and optimized delivery on skewed seed populations are within scope.
+- Hashing or pseudonymizing a seed list does not eliminate the disparate-impact risk from a demographically unrepresentative seed population.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.
+- Do not recommend disabling AI features without naming the performance impact and a manual targeting alternative.

package/skills/marketing/analytics-data-minimization-review/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: analytics-data-minimization-review
+description: Use this skill when reviewing analytics platform configuration — GA4 property settings, BigQuery export schema, custom event-parameter definitions, and user-property declarations — for data-minimization violations, excessive collection, and storage-period over-retention. Trigger when a user provides a GA4 property configuration export, a BigQuery raw-event export schema, a custom event or user-property inventory, data-retention settings, or asks whether their analytics setup collects more personal data than necessary, retains data longer than required, or converts an analytics platform into a personal-data processor. Distinct from marketing-pixel-data-leakage-review: this skill reviews what analytics platforms collect and retain internally, not outbound pixel payloads to ad networks.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: data
+  lifecycle: experimental
+---
+
+# Analytics Data-Minimization Review
+
+## Purpose
+This skill reviews analytics platform configuration — GA4 property settings, BigQuery export schema, custom event-parameter definitions, and user-property declarations — for data-minimization violations, excessive collection, and storage-period over-retention. Analytics platforms are a primary regulatory surface for GDPR enforcement: European DPAs (Austrian DSB, French CNIL, Italian Garante) have found that user_pseudo_id, IP address, and precise geo combined with a BigQuery export constitute transfers of personal data requiring a lawful basis, a valid transfer mechanism, and compliance with the storage-limitation principle under GDPR Article 5(1)(e). This skill is distinct from `marketing-pixel-data-leakage-review` — it reviews what analytics platforms collect and retain internally (schema, user properties, retention periods), not outbound pixel payloads transmitted to ad networks. The review works from sanitized configuration exports only; never request live analytics data or real user identifiers.
+
+## Lean operating rules
+- Treat a GA4 user-scoped custom dimension populated with a persistent first-party user ID linked to a CRM contact record as HIGH — it converts GA4 into a personal-data processor for identified individuals, triggering DPA obligations and requiring a separate documented lawful basis beyond the analytics purpose.
+- Treat a BigQuery raw-event export retaining user_pseudo_id and geo.city at full precision with no anonymization transform or partitioned deletion job as HIGH — the combination of fields constitutes personal data under GDPR, and uncontrolled raw export creates an unmanaged data store with no retention ceiling.
+- Treat a data-retention period set to the maximum (14 months in GA4) with no documented justification tied to a specific, time-bound analytical purpose as HIGH — GDPR Article 5(1)(e) requires retention only as long as necessary; the maximum is not a default entitlement.
+- Treat user properties collecting device fingerprint components, precise IP, or persistent advertising identifiers (GCLID, FBCLID passed as user properties) in a property lacking a valid transfer mechanism for non-EEA exports as HIGH — these fields individually or in combination constitute personal data with cross-border transfer obligations.
+- Treat event parameters collecting free-text field values from search queries, form inputs, or support chats as HIGH — free-text fields frequently contain names, emails, or health information that exceed the analytics collection purpose.
+- Treat session-scoped custom dimensions collecting full URL paths that include query parameters with PII (e.g., `/reset?email=user@example.com`) as HIGH — URL-embedded PII is personal data regardless of whether it was intentionally collected.
+- Flag custom event schemas that duplicate standard GA4 automatically collected events with additional parameters adding no documented analytical value as MEDIUM — redundant collection without justification violates data minimization under GDPR Article 5(1)(c).
+- Flag BigQuery export schemas that retain raw event data beyond the property's configured retention period because no partition-expiry or scheduled query enforces deletion as MEDIUM — the property setting does not automatically govern the export.
+- Flag user-property schemas with no documented owner, purpose, or review date as MEDIUM — absence of governance documentation is a proxy indicator of speculative or abandoned collection.
+- Do not recommend disabling an event or parameter without naming the analytical purpose it serves and the impact of its removal on measurement continuity.
+- Label every finding with evidence basis: configuration export provided, schema 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:
+- User-scoped custom dimension assessment (CRM linkage, persistent identifiers)
+- BigQuery export schema assessment (field precision, anonymization, partitioned deletion)
+- Data-retention period assessment (documented justification vs. maximum default)
+- User-property and event-parameter PII assessment (free-text, URL-embedded PII, fingerprint components)
+- Cross-border transfer assessment (user_pseudo_id + geo fields in non-EEA export)
+- Schema governance assessment (owner, purpose, review date)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/analytics-data-minimization-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "analytics-data-minimization-review",
+  "name": "Analytics Data-Minimization Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review analytics platform configuration — GA4 property settings, BigQuery export schema, custom event-parameter definitions, and user-property declarations — for data-minimization violations, excessive collection, and storage-period over-retention under GDPR Article 5(1)(c) and 5(1)(e) and EU DPA enforcement on GA4.",
+  "source_type": "original",
+  "official_docs": [
+    "https://gdpr-info.eu/art-5-gdpr/",
+    "https://www.cnil.fr/en/use-google-analytics-and-data-transfers-united-states-cnil-orders-website-manageroperator-comply/",
+    "https://www.cnil.fr/en/google-analytics-and-data-transfers-how-make-your-analytics-tool-compliant-gdpr",
+    "https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9782874",
+    "https://support.google.com/analytics/answer/9019185"
+  ],
+  "security_notes": "Read-only static review of sanitized analytics configuration exports and schema definitions only. Never request live analytics data, raw event exports containing real user identifiers, GA4 admin credentials, or BigQuery service-account keys. Findings may indicate cross-border data transfer violations requiring DPA notification — route remediation and legal assessment to qualified privacy counsel before acting on findings.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/analytics-data-minimization-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/marketing/analytics-data-minimization-review/references/workflow-and-output.md

@@ -0,0 +1,187 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide a sanitized analytics configuration export covering one or more of the following artifacts (replace real user IDs, property IDs, and API keys with placeholders; do not include live event exports or actual user data):
+
+- GA4 property data-retention setting (event data and user data retention periods)
+- GA4 custom event definitions: event name, parameters, and the data-layer or gtag call that populates them
+- GA4 user-property definitions: property name, scope (user vs. session), and the value being populated
+- GA4 custom dimension and metric registrations and their mapped event parameters
+- BigQuery export schema: table name, field list with data types, partition strategy, and any scheduled queries or deletion jobs
+- IP anonymization setting (GA4 anonymizes by default; confirm the property has not overridden this via Measurement Protocol or server-side tagging)
+- Linked product integrations (Google Ads, Search Console, Firebase) that may receive exported user data
+
+If the user provides only a partial set, note which artifacts are absent and scope findings accordingly. Do not attempt to infer schema from event names alone.
+
+This skill is scoped to what analytics platforms collect and retain internally. Outbound pixel payloads to ad networks are out of scope — defer to `marketing-pixel-data-leakage-review`.
+
+### Step 2 — User-scoped custom dimension and user-property audit
+
+Inspect every user-scoped custom dimension and user property for identifiers that link an analytics profile to a real-world person:
+
+```text
+# HIGH — user-scoped custom dimension maps GA4 user_pseudo_id to CRM contact ID
+user_property: crm_contact_id = "C-00123456"   # value from logged-in session
+
+→ GA4 user_pseudo_id + crm_contact_id = identified natural person.
+  GA4 is now a personal-data processor for that contact.
+  Requires: documented lawful basis, DPA record of processing, and a valid
+  transfer mechanism if the BigQuery project is outside the EEA.
+
+# LOWER RISK — session-scoped experiment variant; no persistent identifier
+event_parameter: experiment_variant = "control"   # session-scoped, no CRM link
+```
+
+Also flag:
+- Persistent advertising identifiers passed as user properties (GCLID, FBCLID stored across sessions).
+- Device fingerprint components (user-agent, screen resolution, timezone combined) stored as user properties.
+- Email addresses or phone numbers collected in user properties, even in hashed form — still personal data.
+
+### Step 3 — BigQuery export schema audit
+
+For each table in the BigQuery export, assess the combination of fields and retention controls:
+
+```text
+# HIGH — raw export retains user_pseudo_id + geo.city + geo.region at full precision
+# with no partition expiry and no anonymization transform
+
+Table: events_YYYYMMDD
+Fields: user_pseudo_id (STRING), geo.city (STRING), geo.region (STRING),
+        event_timestamp (INTEGER), event_name (STRING)
+Partition expiry: NONE   # rows never auto-deleted
+Scheduled deletion job: NONE
+
+→ user_pseudo_id is a persistent pseudonymous identifier.
+  Combined with geo.city + geo.region it can identify a natural person
+  in a small geography. GDPR applies. No ceiling on retention = violation
+  of storage limitation (Article 5(1)(e)).
+
+# LOWER RISK — export anonymized before landing in BigQuery
+Scheduled query: masks user_pseudo_id to k-anonymized cohort bucket
+Partition expiry: 90 days aligned to GA4 retention setting
+```
+
+Check for:
+- user_pseudo_id retention beyond the GA4 property's configured retention period.
+- geo fields at city or finer precision without a coarsening transform.
+- Absence of partition expiry or scheduled deletion query in the BigQuery dataset.
+- Cross-project export to a dataset in a non-EEA GCP region without a valid SCCs or transfer mechanism documented in the DPA record.
+
+### Step 4 — Data-retention period audit
+
+Assess the GA4 property's retention settings against documented justification:
+
+```text
+# HIGH — retention set to 14 months (maximum); no documented justification
+GA4 retention: User data = 14 months, Event data = 14 months
+Justification in DPA record: NONE
+
+→ GDPR Article 5(1)(e) requires retention only as long as necessary for the
+  stated purpose. The 14-month maximum is not an entitlement; it requires a
+  specific analytical purpose (e.g., year-over-year comparison) that justifies
+  the full period.
+
+# COMPLIANT — 2 months; justification documented
+GA4 retention: 2 months
+DPA record entry: "Session and conversion attribution; 60-day window matches
+  last-click attribution window in ad platform; no year-over-year use case."
+```
+
+Also verify:
+- Whether the BigQuery export enforces the same or shorter retention via partition expiry.
+- Whether "Reset user data on new activity" is enabled — if so, the effective retention period may be much longer than the configured window for active users.
+
+### Step 5 — Event-parameter PII audit
+
+Inspect custom event parameters for content that exceeds the analytics collection purpose:
+
+```text
+# HIGH — search query parameter captures free-text; may contain PII
+event: site_search
+parameter: search_term = "{{DL - search_term}}"   # raw dataLayer value
+
+→ Free-text search queries frequently contain full names, email addresses,
+  medical terms, or financial account numbers typed by users.
+  Collecting raw search terms in GA4 is a data-minimization violation
+  unless the value is scrubbed before collection.
+
+# HIGH — URL parameter includes email in query string
+event: page_view
+parameter: page_location = "https://example.com/reset?email=user@example.com"
+
+→ URL-embedded PII is personal data regardless of intent.
+  Strip PII from page_location before it reaches GA4 using a tag-manager
+  URL-redaction variable or server-side tagging.
+
+# COMPLIANT — search term replaced with a sanitized flag
+event: site_search
+parameter: search_performed = true   # no content; confirms intent only
+```
+
+### Step 6 — Schema governance audit
+
+Assess whether each custom event, parameter, and user property has documented ownership and purpose:
+
+- Every custom dimension registered in a GA4 property should have: owner (team or role), collection purpose, retention justification, and a review date.
+- Absence of governance metadata for any field is MEDIUM — it is a proxy indicator of speculative or abandoned collection that cannot be justified in a DPA record of processing.
+- Flag any custom event or user property whose name does not map to a documented analytical use case in the artifact provided.
+
+### Step 7 — Cross-border transfer assessment
+
+If the BigQuery project or linked export destination is outside the EEA, assess the transfer mechanism:
+
+- Standard Contractual Clauses (SCCs) between the controller and Google must be documented.
+- The Austrian DSB (2022), French CNIL (2022), and Italian Garante (2022) have each found that Google Analytics transfers to US-based Google infrastructure violate GDPR Chapter V in the absence of adequacy or valid SCCs with sufficient supplementary measures.
+- If no transfer mechanism is documented in the DPA record of processing, flag as 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
+<configuration export provided | schema 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 sanitized configuration exports and schema definitions. Never request live analytics data, raw event exports containing real user identifiers, GA4 admin credentials, BigQuery service-account keys, or OAuth tokens.
+- Findings indicating cross-border transfer violations may require DPA notification or supervisory authority engagement — route remediation and legal assessment to qualified privacy counsel before acting on findings. Do not assess DPA notification obligations yourself.
+- This skill is scoped to what analytics platforms collect and retain internally. Outbound pixel payloads transmitted to ad networks are out of scope — refer to `marketing-pixel-data-leakage-review`.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.
+- A GA4 configuration that is GDPR-compliant for EU users may still create obligations under CCPA/CPRA, LGPD, or other jurisdiction-specific laws — note the applicable framework but limit detailed analysis to GDPR unless the user specifies otherwise.

package/skills/marketing/email-sender-authentication-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: email-sender-authentication-review
+description: Use this skill when reviewing DNS sender-authentication records for a marketing domain to identify policy gaps exposing campaigns to rejection, spoofing, or inbox displacement. Trigger when a user provides DNS TXT record exports for SPF, DKIM, DMARC, or BIMI, or asks whether their email authentication posture meets Google/Yahoo bulk-sender requirements, DMARC enforcement standards, CISA BOD 18-01 obligations, PCI DSS v4.0 Req 5.3.3, or whether their transactional or marketing emails are at risk of spoofing or bulk-sender quarantine.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Email Sender Authentication Review
+
+## Purpose
+This skill reviews DNS sender-authentication records (SPF, DKIM, DMARC, BIMI) for a marketing domain and its ESP subdomains to identify policy gaps that expose email campaigns to rejection, spoofing, or inbox displacement. Email authentication failures have grown from a deliverability concern to a compliance obligation: Google and Yahoo bulk-sender requirements (enforced 2024) mandate DMARC alignment for senders exceeding 5,000 messages per day; CISA BOD 18-01 requires federal domains to reach DMARC `p=reject`; and PCI DSS v4.0 Requirement 5.3.3 requires anti-phishing controls for outbound email. A `p=none` DMARC policy with no roadmap to enforcement, a missing DKIM selector for a transactional ESP subdomain, or an SPF record exceeding the ten DNS-lookup limit all constitute policy gaps that range from HIGH spoofing exposure to deliverability failure. The review assesses the full authentication stack from a sanitized DNS record export and surfaces the gap, its severity, and the surgical fix.
+
+## Lean operating rules
+- Treat DMARC policy `p=none` with no enforcement on a domain sending bulk marketing email as HIGH — `p=none` provides monitoring only; spoofing is possible, and Google/Yahoo bulk-sender requirements treat senders without at least `p=none` plus DKIM alignment as quarantine candidates; the path to `p=quarantine` or `p=reject` must be explicit.
+- Treat a missing DKIM selector for any active ESP or transactional subdomain as HIGH — emails sent through that path are unauthenticated, cannot pass DMARC alignment, and are treated as unsigned by receiving MTAs; automation and transactional flows are commonly the most impactful to revenue.
+- Treat an SPF record that exceeds ten DNS lookup mechanisms (`include:`, `a:`, `mx:`, `ptr:`) as HIGH — RFC 7208 defines this as a permerror, which receiving MTAs treat as an SPF fail, blocking all mail from that domain that relies on SPF for DMARC alignment.
+- Treat a DMARC record with `rua=` absent (no aggregate reporting URI) as MEDIUM — without aggregate reports, the operator cannot see what is aligning and what is failing; DMARC without visibility is unmanaged.
+- Treat SPF records using `+all` (pass all) as HIGH — this negates SPF entirely by authorizing any sending source; the entire domain is open to spoofing regardless of which sources are explicitly listed.
+- Treat DMARC `pct=` below 100 as MEDIUM when `p=quarantine` or `p=reject` is set — partial enforcement leaves a configured percentage of non-aligning mail unaffected by the policy and creates a false sense of full enforcement.
+- Treat a BIMI record present without a corresponding VMC or CMC certificate as LOW — BIMI without a validated certificate is ignored by major mailbox providers that require certificate-backed BIMI.
+- Flag the absence of DKIM key rotation documentation as MEDIUM — DKIM keys that have never been rotated accumulate risk; PCI DSS v4.0 Req 5.3.3 and general key-hygiene practice require rotation procedures to exist.
+- Do not recommend removing an ESP's SPF include without first confirming a DKIM-only alignment path is available — SPF removal without DKIM coverage breaks DMARC alignment for that sending path.
+- Label every finding with evidence basis: DNS record provided, documentation-based, or inference from absent record.
+
+## 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:
+- SPF mechanism count and permerror risk assessment
+- DKIM selector coverage assessment for all active sending paths
+- DMARC policy and reporting configuration assessment
+- DMARC alignment mode assessment (strict vs relaxed)
+- BIMI and certificate assessment
+- Bulk-sender requirement compliance status (Google/Yahoo)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/email-sender-authentication-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "email-sender-authentication-review",
+  "name": "Email Sender Authentication Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review DNS sender-authentication records (SPF, DKIM, DMARC, BIMI) for a marketing domain to identify policy gaps exposing campaigns to rejection, spoofing, or inbox displacement.",
+  "source_type": "original",
+  "official_docs": [
+    "https://datatracker.ietf.org/doc/html/rfc7489",
+    "https://support.google.com/mail/answer/81126",
+    "https://www.pcisecuritystandards.org/document_library/",
+    "https://www.cisa.gov/sites/default/files/publications/bod-18-01.pdf",
+    "https://datatracker.ietf.org/doc/html/rfc7208"
+  ],
+  "security_notes": "Email authentication reviews work from sanitized DNS TXT record exports only. Never request live DMARC aggregate report XML, ESP account credentials, or sending-platform API keys. SPF, DKIM, and DMARC records are publicly resolvable; the artifact is the domain's own export, not live lookups against production DNS.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/email-sender-authentication-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}