@raishin/vanguard-frontier-agentic 1.9.0 → 2.0.1

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"
+}

package/skills/marketing/email-sender-authentication-review/references/workflow-and-output.md

@@ -0,0 +1,152 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide the following as a sanitized DNS record export (replace real selector names with generic placeholders only if the user prefers; SPF/DKIM/DMARC records are public data but never request ESP credentials or DMARC aggregate XML):
+- SPF TXT record for the root sending domain and all active ESP subdomains
+- DKIM TXT record(s) identified by selector name (e.g., `selector1._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=..."`)
+- DMARC TXT record at `_dmarc.example.com`
+- BIMI TXT record at `default._bimi.example.com` and VMC/CMC certificate URL if present
+- The list of all active ESP and transactional sending paths (e.g., Mailchimp, Salesforce Marketing Cloud, SendGrid transactional, Postmark) and whether each uses a subdomain or the root domain
+
+If the user provides only partial records, note which paths are unassessed.
+
+### Step 2 — SPF audit
+
+Parse the SPF record from `v=spf1` through the terminating `all` mechanism:
+
+1. Count every mechanism that requires a DNS lookup: `include:`, `a`, `mx`, `ptr`, `exists`. RFC 7208 mandates a hard limit of ten such lookups; exceeding it produces a permerror treated as an SPF fail by receiving MTAs.
+2. Identify the `all` qualifier: `~all` (softfail), `-all` (hardfail), `+all` (pass all — HIGH), `?all` (neutral).
+3. Identify any mechanisms that are redundant, deprecated (`ptr:`), or that enumerate IP ranges far wider than the actual sending infrastructure.
+
+```text
+# HIGH — SPF with +all negates all restrictions
+v=spf1 include:esp1.com include:esp2.com +all
+
+# HIGH — SPF with 13 DNS lookups; permerror on receipt
+v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com
+        include:servers.mcsv.net include:spf.mailjet.com include:_spf.salesforce.com
+        include:postmarkapp.com include:emailsig.com include:mktomail.com
+        include:smtp.hubspot.net include:spf1.mailchimp.com include:esp12.com
+        include:sp.example.com ~all
+# (13 include: mechanisms, each resolves to at least one more lookup → permerror)
+
+# CORRECT — SPF with eight lookups and -all
+v=spf1 include:_spf.google.com include:sendgrid.net include:postmarkapp.com -all
+```
+
+### Step 3 — DKIM audit
+
+For each active sending path identified in Step 1:
+- Confirm a DKIM selector exists and the TXT record is present and well-formed (`v=DKIM1`, key type, public key).
+- Confirm the key length is at least 1024 bits; 2048 bits is recommended.
+- Confirm the signing domain (`d=` tag in the DKIM signature) aligns with the `From:` domain at the level required by the DMARC alignment mode (relaxed: organizational domain match; strict: exact domain match).
+- Flag any sending path with no DKIM selector as HIGH.
+- Flag keys shorter than 1024 bits as HIGH (deprecated, breakable).
+- Note whether key rotation documentation was provided; absence is MEDIUM.
+
+```text
+# HIGH — transactional ESP subdomain has no DKIM selector
+tx.example.com: no DKIM TXT record found for any known selector
+DMARC alignment for mail sent via tx.example.com: fails (no signature to align)
+
+# CORRECT — selector and key present, 2048-bit key
+selector2._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
+```
+
+### Step 4 — DMARC audit
+
+Parse the DMARC record at `_dmarc.<domain>`:
+- `p=` (policy): `none`, `quarantine`, or `reject`. `none` provides monitoring only; it does not prevent spoofing or satisfy Google/Yahoo bulk-sender enforcement requirements when operating at scale.
+- `pct=` (percentage): defaults to 100; values below 100 mean the policy applies to only that fraction of non-aligning mail.
+- `rua=` (aggregate report URI): absence means no visibility into alignment failures.
+- `ruf=` (forensic report URI): optional but useful for debugging.
+- `aspf=` and `adkim=` (alignment modes): `r` (relaxed, default) or `s` (strict); strict requires an exact domain match between the `From:` header and the SPF/DKIM signing domain.
+- `sp=` (subdomain policy): defaults to the `p=` value if absent; explicit `sp=reject` is recommended when subdomains are not used for sending.
+
+```text
+# HIGH — p=none with no enforcement path
+_dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
+→ spoofing is possible; Google/Yahoo bulk-sender requirements not satisfied for enforcement
+
+# MEDIUM — p=quarantine with pct=10 and no ruf
+_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com"
+→ only 10% of failing mail is quarantined; 90% is unaffected
+
+# CORRECT — p=reject, full enforcement, reporting configured
+_dmarc.example.com IN TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com"
+```
+
+### Step 5 — DMARC alignment verification
+
+DMARC requires at least one of SPF or DKIM to align with the `From:` header domain:
+- For SPF alignment: the envelope `MAIL FROM` domain must match the `From:` header domain at the configured alignment level.
+- For DKIM alignment: the `d=` tag in the DKIM signature must match the `From:` header domain at the configured level.
+- If neither SPF nor DKIM aligns, DMARC fails regardless of `p=` value — flag as HIGH if structural misalignment is evident from the record set.
+
+### Step 6 — BIMI and certificate audit
+
+If a BIMI record is present at `default._bimi.<domain>`:
+- Confirm `v=BIMI1; l=<logo-url>; a=<certificate-url>` syntax.
+- Confirm the certificate URL resolves to a VMC (Verified Mark Certificate) or CMC (Common Mark Certificate).
+- Without a VMC/CMC, BIMI display is ignored by Gmail, Yahoo, and Apple Mail — flag as LOW.
+- If no BIMI record is present, note it as informational (not a deficiency unless the user has a BIMI adoption goal).
+
+### Step 7 — Bulk-sender compliance assessment
+
+Assess compliance with Google and Yahoo bulk-sender requirements (enforced Feb 2024 for Google, June 2024 for Yahoo):
+- DMARC record present at organizational domain level: required.
+- SPF or DKIM alignment passing: required.
+- Spam complaint rate below 0.10% (0.08% recommended): not assessable from DNS records alone — note as out-of-scope.
+- One-click unsubscribe (RFC 8058 `List-Unsubscribe-Post` header): not assessable from DNS records — note as out-of-scope.
+
+Summarize the DNS-assessable compliance gap clearly.
+
+### Step 8 — Produce the output
+
+Format findings using the Output format section below.
+
+---
+
+## Output format
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<DNS record provided | documentation-based | inference from absent record>
+
+## 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. DNS records are public, but never request ESP account credentials, DMARC aggregate report XML containing real email metadata, or sending-platform API keys.
+- A domain at `p=none` is exploitable for spoofing attacks and phishing campaigns impersonating the brand. Surface this risk explicitly; do not understate it as a deliverability issue only.
+- When evidence is partial (e.g., SPF record provided but no DKIM selectors listed), scope each finding to what was provided and state the inference basis explicitly.
+- Do not recommend removing an active ESP's SPF `include:` to solve the lookup-count problem without first confirming DKIM-only alignment is available for that path — removing SPF coverage without DKIM will break DMARC alignment.
+- Key rotation guidance is advisory hygiene; the urgency depends on key age and organizational risk tolerance; surface it as MEDIUM, not blocking.