@raishin/vanguard-frontier-agentic 2.0.0 → 2.1.0

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.

package/skills/marketing/eu-ai-act-marketing-system-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: eu-ai-act-marketing-system-review
+description: Use this skill when reviewing a marketing AI system's description card against EU AI Act risk-tier criteria to classify the system (prohibited / high-risk / limited-risk / minimal-risk), flag documentation obligations, and identify deployment-readiness gaps before the August 2, 2026 full-enforcement date. Trigger when a user provides an AI system description card covering system purpose, input data types, output decisions, human-oversight mechanism, deployment geography, and whether it profiles natural persons — or when they ask whether their marketing AI tool, lead-scoring model, content personalization engine, or automated ad-decisioning system requires a conformity assessment or transparency notice under EU AI Act Regulation 2024/1689.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: compliance
+  lifecycle: experimental
+---
+
+# EU AI Act Marketing System Review
+
+## Purpose
+This skill reviews a marketing AI system's description card against EU AI Act Regulation 2024/1689 risk-tier criteria to classify the system, flag documentation obligations, and identify deployment-readiness gaps before the August 2, 2026 full-enforcement date. Marketing AI systems — lead-quality scorers, content personalization engines, urgency-calibration models, lookalike generators, and automated bidding optimizers — operate at the boundary between Article 5 prohibited practices (subliminal manipulation, exploitation of vulnerabilities), Annex III high-risk systems (AI for access to private services, creditworthiness, and employment when profiling natural persons), and limited-risk systems subject to transparency obligations only. Misclassification is itself a compliance gap: a system internally labeled "low risk" that profiles behavioral and demographic signals for credit or employment routing is Annex III high-risk and requires a conformity assessment. The review ingests the description card, maps system characteristics to the risk taxonomy, flags missing documentation (technical documentation Article 11, conformity assessment Article 43, transparency obligations Article 13/52), and identifies the August 2026 enforcement timeline pressure.
+
+## Lean operating rules
+- Treat a system that profiles natural persons using behavioral or demographic signals to produce scores, rankings, or routing decisions used in access to credit, insurance, employment, or essential private services as HIGH — this maps to Annex III categories and requires a conformity assessment, CE marking, and registration in the EU AI database before deployment.
+- Treat urgency or scarcity signals calibrated by real-time engagement data with no human review gate as HIGH — this is a candidate for Article 5(1)(b) prohibited subliminal manipulation or exploitation of psychological vulnerabilities; route to qualified legal counsel without making the prohibition determination yourself.
+- Treat a system classified internally as "low risk" but routing decisions to downstream agents or automated processes with no human override capability as HIGH — the absence of a meaningful human-oversight mechanism invalidates a limited-risk designation under Article 14 requirements.
+- Treat a system that processes biometric, health, racial/ethnic-origin, political-opinion, or religious-belief data as input features or inferred labels for marketing segmentation as HIGH — these are special-category data under GDPR Article 9 and trigger heightened AI Act scrutiny as potential Annex III characteristics.
+- Treat the absence of technical documentation (Article 11) covering system purpose, training data provenance, performance metrics, and limitations for any non-minimal-risk system as HIGH — documentation is a prerequisite for conformity assessment, not a post-deployment obligation.
+- Treat a system with no transparency notice or user-facing disclosure of automated decision-making where the EU AI Act or GDPR Article 22 requires one as HIGH — undisclosed profiling that produces legal or similarly significant effects is both a GDPR and an AI Act violation.
+- Flag a system whose August 2026 enforcement readiness is unknown — no documented conformity-assessment timeline, no assigned responsible person, no EU registration planned — as MEDIUM when the system is potentially high-risk.
+- Flag general-purpose AI models integrated into marketing workflows without a documented system-level risk assessment as MEDIUM — the GPAI provisions under Title VIII require providers to assess downstream systemic risk.
+- Flag systems that collect or process behavioral signals at scale (>1 million natural persons) without a documented fundamental rights impact assessment as MEDIUM.
+- Do not classify a system as prohibited under Article 5 without explicit instruction to qualified counsel; surface the risk and route the determination.
+- Label every finding with evidence basis: description card provided, documentation-based, or inference from missing information.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- System risk-tier classification (prohibited / high-risk Annex III / limited-risk / minimal-risk) with rationale
+- Profiling and natural-person assessment (Article 22 GDPR intersection)
+- Human-oversight mechanism assessment (Article 14)
+- Documentation gap inventory (Article 11 technical docs, Article 43 conformity assessment, Article 13/52 transparency)
+- August 2026 enforcement readiness assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/eu-ai-act-marketing-system-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "eu-ai-act-marketing-system-review",
+  "name": "EU AI Act Marketing System Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review a marketing AI system description card against EU AI Act Regulation 2024/1689 risk-tier criteria — classify the system, flag documentation obligations (Articles 11, 13, 14, 43), and identify deployment-readiness gaps before the August 2, 2026 full-enforcement date.",
+  "source_type": "original",
+  "official_docs": [
+    "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689",
+    "https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai",
+    "https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence",
+    "https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-022023-technical-scope-art-22-gdpr_en",
+    "https://artificialintelligenceact.eu/the-act/"
+  ],
+  "security_notes": "EU AI Act classification determines conformity assessment, CE marking, and EU AI database registration obligations — misclassification is itself a compliance gap. Review works from sanitized AI system description cards only; never request model weights, training datasets, internal performance logs, or vendor system-access credentials. Legal determination of Article 5 prohibited practices is routed to qualified counsel.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/eu-ai-act-marketing-system-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/marketing/eu-ai-act-marketing-system-review/references/workflow-and-output.md

@@ -0,0 +1,176 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide an AI system description card as a sanitized document (no model weights, no training data, no vendor credentials). The description card should cover:
+- System purpose and primary use case (what decision or output does it produce?)
+- Input data types (behavioral signals, demographic data, purchase history, engagement metrics, etc.)
+- Output type (score, ranking, binary decision, content recommendation, audience segment)
+- Human-oversight mechanism (is there a human review gate before the output is acted upon?)
+- Deployment geography (EU deployment or EU-resident data subjects?)
+- Whether the system profiles natural persons (produces an evaluation of personal aspects)
+- Internal risk classification, if any
+- Whether the system is integrated into a downstream automated decision chain
+
+If the user provides only a partial description card, note which elements are absent and scope findings accordingly.
+
+### Step 2 — Determine EU AI Act applicability
+
+Confirm whether the Act applies:
+- The system is placed on the market in the EU, used in the EU, or its outputs affect EU-resident natural persons.
+- The operator or deployer is subject to EU jurisdiction, or the provider targets the EU market.
+
+If applicability is uncertain, flag as MEDIUM and recommend a legal-jurisdiction assessment.
+
+### Step 3 — Article 5 prohibited-practice screening
+
+Screen the system description for candidate prohibited practices before proceeding to risk-tier classification:
+
+```text
+# Article 5(1)(a) — Subliminal manipulation
+System uses techniques that influence behavior below the threshold of conscious awareness,
+causing decisions persons would not have made otherwise — e.g., urgency signals calibrated
+to anxiety response patterns without the user's knowledge.
+
+# Article 5(1)(b) — Exploitation of vulnerabilities
+System exploits specific vulnerabilities of a group (age, disability, social/economic situation)
+to distort behavior in a way that causes harm — e.g., targeting financially distressed segments
+with high-interest offers optimized on engagement signals from that population.
+
+# Article 5(1)(e)/(f) — Social scoring / emotion recognition in workplace or public space
+```
+
+If any candidate applies, flag as HIGH and route the prohibited-practice determination to qualified legal counsel. Do not determine prohibition yourself.
+
+### Step 4 — Annex III high-risk classification
+
+Map system characteristics to Annex III categories relevant to marketing AI:
+
+```text
+Annex III(1) — Biometric categorisation that infers sensitive characteristics
+Annex III(3) — AI in education or vocational training affecting access
+Annex III(4) — Employment, workers management, access to self-employment
+Annex III(5) — Access to and enjoyment of essential private services and public services
+              → creditworthiness scoring, insurance risk, financial product access
+Annex III(6) — Law enforcement (typically out of scope for marketing)
+Annex III(8) — Administration of justice / democratic processes
+```
+
+A marketing AI system that profiles natural persons to determine or influence their access to credit, insurance, employment, or essential services maps to Annex III(5) or Annex III(4). Classify as HIGH-RISK.
+
+```text
+# HIGH — lead-quality scorer using behavioral + demographic signals, output routes to credit team
+System purpose: score leads for mortgage pre-qualification routing
+Input: browsing behavior, inferred income tier, device type, engagement rate
+Output: lead-quality score → routed to underwriting queue or rejected
+Classification: Annex III(5) — access to essential private services (credit/mortgage)
+Obligation: Technical documentation (Art. 11), conformity assessment (Art. 43),
+            EU AI database registration (Art. 71), transparency to affected persons (Art. 13)
+```
+
+### Step 5 — Limited-risk and transparency-only assessment
+
+For systems that do not meet Annex III criteria, assess whether limited-risk transparency obligations apply:
+
+- Article 52(1): Systems interacting with natural persons must disclose they are AI (chatbots, virtual advisors).
+- Article 52(3): Deep fake / synthetic content must be disclosed as artificially generated.
+- Article 52(4): Emotion recognition or biometric categorisation systems must notify the persons exposed.
+
+```text
+# MEDIUM — AI chatbot on marketing site with no AI-disclosure notice
+Obligation: Article 52(1) transparency notice required before interaction begins.
+```
+
+### Step 6 — Human oversight and Article 14 assessment
+
+Assess whether the system's declared human-oversight mechanism satisfies Article 14 for high-risk systems:
+
+```text
+# HIGH — "human in the loop" flag declared but system routes decisions to automated downstream agents
+The human review gate must be meaningful: the human must be able to understand the output,
+detect failures, and override or halt the system. Rubber-stamp review with no override capability
+does not satisfy Article 14.
+```
+
+### Step 7 — Documentation gap inventory
+
+For any non-minimal-risk system, enumerate required documentation and flag gaps:
+
+| Obligation | Article | Status |
+|---|---|---|
+| Technical documentation | Art. 11 | Present / Absent / Partial |
+| Conformity assessment | Art. 43 | Present / Absent / Planned |
+| EU AI database registration | Art. 71 | Present / Absent / Not started |
+| Transparency notice (users) | Art. 13/52 | Present / Absent |
+| Fundamental rights impact assessment | Art. 27 | Present / Absent |
+| Responsible person designation | Art. 26 | Present / Absent |
+
+### Step 8 — August 2026 enforcement readiness check
+
+Regulation 2024/1689 entered into force August 1, 2024. Key milestones:
+- February 2, 2025: Prohibited practices (Article 5) enforceable.
+- August 2, 2025: GPAI and governance provisions enforceable.
+- August 2, 2026: All provisions including high-risk obligations enforceable.
+
+Flag any high-risk system with no documented conformity-assessment timeline, no responsible person, or no EU AI database registration as MEDIUM (if enforcement date is future) or HIGH (if enforcement date has passed at time of review).
+
+### 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
+<description card provided | documentation-based | inference>
+
+## Risk-tier classification
+<Prohibited (Art. 5) candidate | High-risk Annex III | Limited-risk (Art. 52) | Minimal-risk>
+<rationale: which Annex III category or Article 5 provision applies and why>
+
+## Documentation gap inventory
+<table: obligation | article | 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>
+
+## August 2026 enforcement readiness
+<summary of gaps and timeline pressure>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security and scope notes
+
+- This is a static review. Never request model weights, training datasets, internal performance logs, or vendor system-access credentials. Work from sanitized description cards only.
+- The prohibited-practice determination under Article 5 is a legal conclusion — flag the candidate risk and route to qualified legal counsel rather than deciding it.
+- EU AI Act obligations are in addition to, not instead of, GDPR obligations. A system that triggers Annex III also implicates GDPR Article 22, Article 35 DPIA obligations, and special-category data restrictions.
+- August 2026 is a hard enforcement deadline; systems requiring conformity assessments need lead time. Flag timeline pressure explicitly.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.