@raishin/vanguard-frontier-agentic 2.2.0 → 2.5.0

package/skills/salesforce/salesforce-integration-review-skill/references/integration-pattern-reference.md

@@ -0,0 +1,239 @@
+# Integration Pattern Reference
+
+Reference for Salesforce integration patterns covering REST, SOAP, Bulk API,
+Platform Events, Change Data Capture, and OAuth flows.
+
+---
+
+## API Pattern Selection Matrix
+
+| Use Case | Recommended API | Notes |
+|----------|----------------|-------|
+| Retrieve/update single or small record set | REST API | Low latency, JSON |
+| Enterprise system integration, WSDLs | SOAP API | XML, strong typing |
+| Bulk load/export (> 10,000 records) | Bulk API 2.0 | Async, CSV/JSON |
+| Real-time event notification | Platform Events | Pub/Sub, async |
+| Replicate CRM changes to external systems | Change Data Capture | Delta sync |
+| User-facing OAuth flows | OAuth 2.0 Authorization Code | Browser-based |
+| Server-to-server integration | OAuth 2.0 JWT Bearer | No user interaction |
+| Legacy system callout from Apex | Named Credential + HttpRequest | Managed credentials |
+
+---
+
+## REST API
+
+### Endpoint Structure
+```
+https://{instanceUrl}/services/data/v{apiVersion}/{resource}
+
+Common resources:
+  /sobjects/{sObjectType}/          -- CRUD on objects
+  /sobjects/{sObjectType}/{Id}      -- Specific record
+  /query/?q={SOQL}                  -- SOQL query
+  /composite/                       -- Batch multiple requests
+  /composite/tree/                  -- Create related records in one call
+  /composite/batch                  -- Up to 25 subrequests in one HTTP call
+```
+
+### Composite API (minimize round trips)
+```json
+POST /services/data/v59.0/composite/batch
+{
+  "haltOnError": false,
+  "batchRequests": [
+    {
+      "method": "GET",
+      "url": "/services/data/v59.0/sobjects/Account/001XXXXXXXXXXXX"
+    },
+    {
+      "method": "PATCH",
+      "url": "/services/data/v59.0/sobjects/Contact/003XXXXXXXXXXXX",
+      "richInput": { "Phone": "+1-555-0123" }
+    }
+  ]
+}
+```
+
+### REST API Limits
+- API requests per 24 hours: based on edition and user count.
+- Concurrent API limits: 25 long-running requests per org.
+- Composite batch: max 25 subrequests.
+- Composite graph: max 500 nodes.
+- SOQL: max 2,000 characters in query string via REST.
+
+---
+
+## SOAP API
+
+### WSDL Types
+- **Enterprise WSDL:** Org-specific, strongly typed, regenerated when metadata changes.
+- **Partner WSDL:** Generic, works across orgs, uses `sObject` generic type.
+
+Use Partner WSDL for multi-org integrations; Enterprise WSDL for single-org
+tightly coupled systems.
+
+### SOAP Session Management
+```xml
+<!-- Login request to get session ID -->
+<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
+                  xmlns:urn="urn:partner.soap.sforce.com">
+  <soapenv:Body>
+    <urn:login>
+      <urn:username>user@example.com</urn:username>
+      <urn:password>passwordSECURITYTOKEN</urn:password>
+    </urn:login>
+  </soapenv:Body>
+</soapenv:Envelope>
+```
+
+**Security note:** SOAP login with username/password is deprecated in favor of
+OAuth. Avoid using SOAP login in new integrations. If it exists, migrate to
+OAuth JWT Bearer flow.
+
+---
+
+## Bulk API 2.0
+
+### Job Lifecycle
+```
+1. Create Job:       POST /services/data/v59.0/jobs/ingest/
+2. Upload Data:      PUT  /services/data/v59.0/jobs/ingest/{jobId}/batches
+3. Close Job:        PATCH /services/data/v59.0/jobs/ingest/{jobId}  {"state":"UploadComplete"}
+4. Poll Status:      GET  /services/data/v59.0/jobs/ingest/{jobId}
+5. Get Results:      GET  /services/data/v59.0/jobs/ingest/{jobId}/successfulResults
+                     GET  /services/data/v59.0/jobs/ingest/{jobId}/failedResults
+6. Delete Job:       DELETE /services/data/v59.0/jobs/ingest/{jobId}
+```
+
+### Bulk API 2.0 Limits
+- Max records per job: 150 million (via multiple batches)
+- Max file size: 100 MB per upload call
+- Max parallel jobs: varies by edition
+- Use `query` operation type for exports: `POST /services/data/v59.0/jobs/query/`
+
+### Bulk API vs SOQL for Exports
+
+| Volume | Method |
+|--------|--------|
+| < 50,000 rows | REST API + SOQL with LIMIT/OFFSET |
+| 50,000–10M rows | Bulk API 2.0 query job |
+| > 10M rows | Bulk API 2.0 + PK chunking (for certain objects) |
+
+---
+
+## Platform Events
+
+Platform Events provide a publish/subscribe messaging system within Salesforce.
+They are defined as Salesforce objects with `__e` suffix.
+
+### Publishing from Apex
+```apex
+// Publish a Platform Event
+Shipment_Status__e event = new Shipment_Status__e(
+    OrderId__c = '1234',
+    Status__c = 'Delivered',
+    Timestamp__c = DateTime.now
+);
+Database.SaveResult result = EventBus.publish(event);
+if (!result.isSuccess) {
+    System.debug('Event publish failed: ' + result.getErrors[0].getMessage);
+}
+```
+
+### Subscribing (Trigger on Platform Event)
+```apex
+trigger ShipmentStatusTrigger on Shipment_Status__e (after insert) {
+    for (Shipment_Status__e event : Trigger.new) {
+        // Process event
+        System.debug('Order ' + event.OrderId__c + ' status: ' + event.Status__c);
+    }
+}
+```
+
+### Platform Event Limits
+- Event delivery: at least once (idempotent subscribers required).
+- Retention: 72 hours (standard events); 1 day to 90 days (high-volume events).
+- Max event message size: 1 MB.
+- Publishing limits: governed by API request limits.
+
+---
+
+## Change Data Capture (CDC)
+
+CDC publishes change events when Salesforce records are created, updated,
+deleted, or undeleted. External systems subscribe to receive delta changes.
+
+```
+Supported objects: Standard and custom objects enabled for CDC.
+Event type suffix: __ChangeEvent (e.g., AccountChangeEvent)
+```
+
+### Subscribing via CometD (External)
+```python
+# Python example using salesforce-cometd-client
+from salesforce.cometd import SalesforceCometDClient
+
+client = SalesforceCometDClient(
+    login_url="https://login.salesforce.com",
+    client_id=CLIENT_ID,
+    client_secret=CLIENT_SECRET,
+    username=USERNAME,
+    password=PASSWORD + SECURITY_TOKEN
+)
+client.subscribe("/data/AccountChangeEvent", callback=handle_account_change)
+client.start
+
+def handle_account_change(event):
+    header = event['data']['schema']
+    body = event['data']['payload']
+    print(f"Change type: {body['ChangeEventHeader']['changeType']}")
+    print(f"Changed fields: {body['ChangeEventHeader']['changedFields']}")
+```
+
+---
+
+## OAuth Flows Reference
+
+### OAuth 2.0 Authorization Code Flow (User-Facing)
+```
+1. Redirect user to:
+   https://login.salesforce.com/services/oauth2/authorize?
+     response_type=code&
+     client_id={CLIENT_ID}&
+     redirect_uri={CALLBACK_URL}&
+     scope=api+refresh_token
+
+2. User logs in and approves.
+
+3. Salesforce redirects to CALLBACK_URL with ?code={AUTH_CODE}
+
+4. Exchange code for token:
+   POST https://login.salesforce.com/services/oauth2/token
+   Body: grant_type=authorization_code&code={AUTH_CODE}&
+         client_id={CLIENT_ID}&client_secret={CLIENT_SECRET}&
+         redirect_uri={CALLBACK_URL}
+
+5. Store access_token and refresh_token securely.
+```
+
+### OAuth 2.0 JWT Bearer Flow (Server-to-Server)
+```
+1. Generate JWT signed with your Connected App's private key:
+   Header: {"alg":"RS256","typ":"JWT"}
+   Payload: {
+     "iss": "{CLIENT_ID}",
+     "sub": "{SALESFORCE_USERNAME}",
+     "aud": "https://login.salesforce.com",
+     "exp": {current_epoch + 300}
+   }
+
+2. POST to token endpoint:
+   POST https://login.salesforce.com/services/oauth2/token
+   Body: grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
+         assertion={SIGNED_JWT}
+
+3. Receive access_token (no refresh_token in JWT flow).
+```
+
+JWT Bearer is the recommended server-to-server pattern. No user credentials
+are transmitted; access is pre-authorized by admin.

package/skills/salesforce/salesforce-integration-review-skill/references/named-credential-design.md

@@ -0,0 +1,211 @@
+# Named Credential Design Reference
+
+Reference for designing secure Named Credentials and External Credentials
+in Salesforce for API callout authentication management.
+
+---
+
+## Named Credential vs External Credential
+
+Salesforce introduced a split between Named Credential and External Credential
+in recent API versions. Understanding the distinction is
+required for correct configuration.
+
+| Concept | Purpose | Stores |
+|---------|---------|--------|
+| External Credential | Authentication method and credentials | Client ID, client secret, certificate, or OAuth token |
+| Named Credential | URL and HTTP settings | Base URL, protocol, auth scheme reference |
+| Principal | User or permission set mapped to External Credential | Per-user or per-permission-set auth |
+
+In the legacy model (prior to split), a single Named Credential stored both
+the URL and the credentials.
+
+### When to Use Each
+
+- **Legacy Named Credential (URL + auth in one):** Acceptable for simple integrations.
+  Deprecated path; migrate to split model when possible.
+- **External Credential + Named Credential (split):** Use for:
+  - Per-user authentication (each user's own credentials used for callouts).
+  - OAuth flows where token must be refreshed per user.
+  - Environments where multiple endpoints share the same auth scheme.
+
+---
+
+## Configuring OAuth External Credentials
+
+### OAuth 2.0 Client Credentials (Server-to-Server)
+```
+External Credential:
+  Authentication Protocol: OAuth 2.0
+  Authentication Flow Type: Client Credentials
+  Client Id: {CLIENT_ID}
+  Client Secret: {CLIENT_SECRET}  (stored encrypted, not visible after save)
+  Token URL: https://api.vendor.example.com/oauth/token
+  Scope: api:read api:write
+```
+
+### OAuth 2.0 JWT Bearer (Server-to-Server, Certificate-Based)
+```
+External Credential:
+  Authentication Protocol: OAuth 2.0
+  Authentication Flow Type: JWT Bearer Token
+  Client Id: {CLIENT_ID}
+  Certificate: {CERT_UNIQUE_NAME}  (Salesforce Certificate, not a file upload)
+  Token URL: https://login.salesforce.com/services/oauth2/token
+  Audience: https://login.salesforce.com
+  Subject: integration-user@myorg.salesforce.com
+```
+
+---
+
+## Named Credential URL Configuration
+
+```
+Named Credential:
+  Label: Vendor API Production
+  URL: https://api.vendor.example.com/v2
+  External Credential: VendorAPI_ExternalCred
+  Generate Authorization Header: Enabled
+  Allow Formula Fields in HTTP Header: Disabled (unless needed)
+  Allow Merge Fields in HTTP Body: Disabled (unless needed)
+```
+
+**Security note on Merge Fields:**
+- `Allow Merge Fields in HTTP Body` and `Allow Merge Fields in HTTP Header`
+  let Apex inject field values from Salesforce records into callout requests.
+- Enable only when strictly necessary. When enabled, ensure the injected values
+  are validated and bounded — arbitrary field injection can exfiltrate data.
+
+---
+
+## mTLS (Mutual TLS) Setup
+
+For endpoints that require client certificate authentication:
+
+### Step 1: Generate or upload certificate
+```
+Setup > Security > Certificate and Key Management
+  -> Generate Self-Signed Certificate (for testing)
+  -> Upload Signed Certificate (for production)
+  Note the Certificate Unique Name (e.g., VendorMTLSCert)
+```
+
+### Step 2: Configure External Credential with certificate
+```
+External Credential:
+  Authentication Protocol: Custom Header
+  Custom Headers:
+    X-Client-Cert: {!$Credential.Certificate}   (if vendor requires cert in header)
+  Certificate: VendorMTLSCert
+```
+
+For true mTLS (TLS handshake-level):
+```
+Named Credential:
+  Callout Options: Use Client Certificate
+  Certificate: VendorMTLSCert
+```
+
+### Step 3: Verify endpoint accepts Salesforce certificate
+Share the public certificate (exported from Certificate and Key Management)
+with the integration vendor for allowlisting on their server.
+
+---
+
+## Custom Header Injection
+
+Named Credentials support injecting custom headers into every callout:
+
+```
+Named Credential > Custom Headers:
+  Name: X-API-Key
+  Value: {!$Credential.Password}   (references External Credential stored secret)
+
+  Name: X-Tenant-Id
+  Value: MyTenantId123             (static value; acceptable for non-secret metadata)
+
+  Name: X-Request-Id
+  Value: {!CASESAFEID($Api.Organization_Id)}  (dynamic if merge fields enabled)
+```
+
+**Security review checklist for custom headers:**
+- [ ] No secret values stored as static strings (must reference `{!$Credential.X}`).
+- [ ] No internal org IDs or user IDs exposed in headers to external systems
+  unless required by the vendor.
+- [ ] Header names match vendor's documented API specification.
+
+---
+
+## Named Credential Security Review
+
+### Access Control
+
+Named Credentials are accessible to any Apex code that references them.
+Access is not restricted at the Named Credential level. Restrict access at
+the Apex class level using `with sharing` and appropriate caller validation.
+
+```apex
+// WHO can invoke this callout? Restrict at the class level.
+public with sharing class VendorAPIClient {
+    private static final String NC_NAME = 'callout:VendorAPI_Prod';
+
+    @AuraEnabled
+    public static String fetchData(String resourcePath) {
+        // Validate resourcePath to prevent path traversal
+        if (!resourcePath.startsWith('/allowed/path/')) {
+            throw new AuraHandledException('Invalid resource path.');
+        }
+        HttpRequest req = new HttpRequest;
+        req.setEndpoint(NC_NAME + resourcePath);
+        req.setMethod('GET');
+        req.setTimeout(30000);
+        HttpResponse res = new Http.send(req);
+        if (res.getStatusCode != 200) {
+            throw new AuraHandledException('Callout failed: ' + res.getStatusCode);
+        }
+        return res.getBody;
+    }
+}
+```
+
+### Listing All Named Credentials (SOQL)
+```sql
+SELECT Id, DeveloperName, Endpoint, PrincipalType, AuthorizationStatus
+FROM NamedCredential
+ORDER BY DeveloperName
+```
+
+### Audit Questions
+
+1. Does every Named Credential point to an HTTPS endpoint? (`http://` endpoints
+   should not exist in production.)
+2. Does every Named Credential have a corresponding External Credential with
+   stored secrets — or is it using legacy merged fields with secrets?
+3. Are credentials scoped to a specific integration user/service account, not
+   a named human's credentials?
+4. Is there a rotation plan documented for credentials stored in External
+   Credentials?
+
+---
+
+## Credential Rotation Procedure
+
+```
+1. Obtain new credentials from the integration vendor.
+2. Navigate to: Setup > Named Credentials > External Credentials > [Credential]
+3. Update the Client Secret or Password field with the new value.
+4. Save.
+5. Test the Named Credential (Setup > Named Credentials > Test button if available,
+   or run a test Apex script in anonymous Apex window against the NC).
+6. Document rotation date in the integration runbook.
+7. Revoke the old credentials with the vendor within 24 hours of successful rotation.
+```
+
+Rotation schedule guidance:
+
+| Credential Type | Rotation Frequency |
+|----------------|-------------------|
+| API keys (long-lived) | 90 days |
+| OAuth client secrets | 180 days |
+| Certificates | Before expiry date; minimum annual |
+| Username/password (if used) | 30 days |

package/skills/salesforce/salesforce-marketing-consent-review-skill/SKILL.md

@@ -0,0 +1,204 @@
+---
+name: salesforce-marketing-consent-review-skill
+description: Use this skill when marketing data flows must be reviewed for consent capture, lawful basis, purpose limitation, preference center coverage, suppression list integrity, subscriber-key collision risk, deliverability authentication (SPF, DKIM, DMARC), and unsubscribe link integrity. Covers Marketing Cloud, Account Engagement (formerly Pardot), Data Cloud, and related marketing orchestration tools. Trigger phrases: "review our marketing consent model", "check this Marketing Cloud data flow for consent", "is our preference center compliant", "review subscriber key design", "check SPF and DKIM for our sending domain". Do not use when the subject is a general Salesforce integration not involving marketing data (use salesforce-integration-review-skill), when a live Marketing Cloud change is being deployed (use salesforce-live-change-approval-protocol), or when a data exposure event has occurred (use salesforce-data-exposure-escalation-protocol). Works from sanitized design documents and configuration exports only; never requests live credentials or accesses marketing accounts.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-20"
+  category: compliance
+  lifecycle: experimental
+---
+
+# Salesforce Marketing Consent Review Skill
+
+## Purpose
+This skill reviews marketing data flows for consent capture, lawful basis,
+purpose limitation, preference center coverage, suppression list integrity,
+subscriber-key collision risk, deliverability authentication, and unsubscribe
+link integrity. It exists because marketing data flows — particularly in
+Marketing Cloud , Account Engagement
+, and Data Cloud
+ — frequently cross jurisdictions and
+involve regulated personal data subject to GDPR, CCPA, CASL, and other
+consent-based frameworks. It does not access live marketing accounts or
+authorize changes.
+
+## When to use
+- A marketing data flow is being designed or reviewed for compliance.
+- A consent model is being assessed for a new campaign or channel.
+- A deliverability issue may be related to authentication configuration.
+- A preference center redesign needs consent-model review.
+- A subscriber-key migration or Data Cloud integration is planned.
+
+## When not to use
+- General Salesforce integration (no marketing data) — use `salesforce-integration-review-skill`.
+- Live Marketing Cloud change deployment — use `salesforce-live-change-approval-protocol`.
+- Data exposure event response — use `salesforce-data-exposure-escalation-protocol`.
+- Full org assessment — use `salesforce-org-assessment-skill`.
+
+## Minimum payload (required inputs)
+- Description of the marketing data flow: source systems, destination (Marketing
+  Cloud, Account Engagement, Data Cloud), data categories involved.
+- Jurisdiction(s) where subscribers are located (or note that it is unknown).
+- Consent model description: how consent is captured, what lawful basis is claimed.
+- Preference center description (or note that it is absent).
+- Sending domain(s) (sanitized, no live API keys or credentials).
+
+## Workflow
+
+### 1. Consent capture review
+- Identify where consent is captured: web form, API, import, point of sale.
+- Flag: consent captured without a clear affirmative action (pre-ticked boxes,
+  bundled consent).
+- Flag: consent captured without a timestamp and source record (not auditable).
+- Flag: consent captured via a third-party list import without documented
+  lawful basis for the jurisdiction.
+- Flag: re-permission campaigns not used when consent records are > configurable
+  age threshold.
+
+### 2. Lawful basis assessment
+- Identify the claimed lawful basis per jurisdiction:
+  - GDPR (EU/EEA): consent, legitimate interest (with documented LIA),
+    contract, legal obligation.
+  - CCPA (California): right to opt-out of sale; identify whether the
+    flow constitutes a "sale" under CCPA.
+  - CASL (Canada): express vs implied consent; flag implied consent without
+    an expiry tracking mechanism.
+  - Other jurisdictions: flag if jurisdiction is identified but lawful basis
+    is not documented.
+- Flag: single lawful basis asserted globally when multi-jurisdiction subscribers
+  require jurisdiction-specific bases.
+- Flag: legitimate interest asserted without a documented Legitimate Interest
+  Assessment (LIA).
+
+### 3. Purpose limitation
+- Verify that data collected for one purpose is not used for a materially
+  different marketing purpose without a separate consent.
+- Flag: contact data collected in a Service Cloud context being synced to
+  Marketing Cloud for promotional campaigns without a separate consent capture.
+- Flag: Data Cloud  segments built
+  from data collected under a different purpose than marketing.
+
+### 4. Preference center coverage
+- Verify that a preference center exists and covers all active channels
+  (email, SMS, push, direct mail).
+- Flag: preference center that does not honor opt-outs within a documented
+  processing time (e.g., 10 business days).
+- Flag: preference center that does not propagate suppression to all active
+  sending platforms (Marketing Cloud, Account Engagement, and any third-party
+  senders).
+- Flag: preference center that requires an account login to opt out (barrier to
+  opt-out is a compliance risk).
+
+### 5. Suppression list integrity
+- Verify that suppression lists (global unsubscribes, do-not-contact lists,
+  hard bounces) are applied across all sending platforms.
+- Flag: suppression list sync with > configurable delay (stale suppression
+  can result in sending to opted-out subscribers).
+- Flag: suppression list managed manually without automated sync to all platforms.
+- Flag: hard bounces not suppressed (can damage sender reputation and may
+  violate CAN-SPAM/CASL).
+
+### 6. Subscriber-key design and collision risk
+- Review the subscriber key design in Marketing Cloud
+  .
+- Flag: subscriber keys using email addresses as the key (email changes cause
+  key collisions and duplicate subscriber records).
+- Flag: subscriber key not synchronized with the CRM contact ID (leads to
+  orphaned subscriber records).
+- Flag: subscriber key strategy not defined before Data Cloud integration
+  (can cause identity resolution failures).
+
+### 7. Deliverability authentication
+- Review the sending domain configuration:
+  - SPF: verify that an SPF record exists for the sending domain and includes
+    Marketing Cloud sending IPs.
+  - DKIM: verify that DKIM signing is configured for the sending domain.
+  - DMARC: verify that a DMARC policy exists; flag if policy is `p=none`
+    (monitoring only, no enforcement).
+- Flag: sending from a shared IP pool without dedicated IP warm-up plan.
+- Flag: DMARC policy `p=reject` or `p=quarantine` without monitoring in place
+  (can result in false positives if misconfigured).
+
+### 8. Unsubscribe link integrity
+- Verify that all email sends include a functional unsubscribe link.
+- Flag: unsubscribe link that requires authentication or account creation.
+- Flag: unsubscribe that routes to a preference center with a long opt-out
+  process (more than 2 clicks).
+- Flag: transactional email templates where an unsubscribe link is absent but
+  the email contains promotional content.
+- Flag: one-click unsubscribe not implemented where List-Unsubscribe header
+  is expected by receiving mail providers.
+
+## Evidence requirements
+- Sanitized marketing data flow description; no credentials, API keys, or
+  customer data.
+- Jurisdiction(s) identified or noted as unknown.
+- Consent model description; if absent, flag as a high-risk unknown.
+
+## Output format
+```
+marketing_consent_review_findings:
+  consent_capture:
+    - finding: [description]
+      severity: Critical | High | Medium | Low
+      jurisdiction: [applicable, or "all"]
+      recommendation: [brief]
+  lawful_basis: [same structure]
+  purpose_limitation: [same structure]
+  preference_center: [same structure]
+  suppression_list: [same structure]
+  subscriber_key_design: [same structure]
+  deliverability_authentication: [same structure]
+  unsubscribe_integrity: [same structure]
+
+summary:
+  total_findings: [count]
+  critical_count: [count]
+  high_count: [count]
+escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
+open_questions_for_counsel: [list — do not answer; require legal determination]
+assumptions: [list]
+missing_evidence: [what would improve the review]
+```
+
+## Redaction rules
+- Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
+- Sanitize org IDs, user IDs (replace with placeholders) before sharing in outputs.
+- Subscriber data, email addresses, and contact records must not appear in outputs.
+
+## Privilege / data handling rules
+- This review may surface findings that have regulatory notification implications.
+  Flag and route to privacy counsel before any public statement.
+- Lawful basis assessments are not legal conclusions; all findings require
+  verification by qualified privacy counsel.
+- Regulated-data marketing flows (health, financial) escalate to compliance review.
+
+## Handoff rules
+- Hands off to: salesforce-data-exposure-escalation-protocol (if consent violation
+  constitutes a data exposure event), salesforce-integration-review-skill (if
+  integration design gaps underlie consent failures), salesforce-case-capsule
+  (structured handoff for any Critical finding requiring escalation).
+- Required handoff fields: matter_id, critical_count, escalation_gates_fired,
+  open_questions_for_counsel.
+
+## Audit log fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- Data flow involves regulated health or financial data sent for marketing purposes
+  without documented consent — fire production-data-exposure gate and escalate.
+- Suppression list is confirmed as stale and sends are ongoing — Critical finding;
+  recommend immediate send pause for human review.
+- Lawful basis is absent for GDPR-jurisdiction subscribers — Critical finding;
+  escalate to privacy counsel before any further sends.
+
+## Security notes
+- Read-only static review; never accesses live Marketing Cloud accounts or APIs.
+- Lawful basis findings are not legal conclusions; they require verification by
+  qualified privacy counsel.
+- Unsubscribe failures are a regulatory risk in most jurisdictions; treat as High
+  even when severity appears low.
+- SPF, DKIM, and DMARC findings should be verified against current DNS records
+  by the sending organization's technical team.

package/skills/salesforce/salesforce-marketing-consent-review-skill/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "salesforce-marketing-consent-review-skill",
+  "name": "Salesforce Marketing Consent Review Skill",
+  "type": "skill",
+  "provider": "salesforce",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Reviews Salesforce marketing data flows (Marketing Cloud, Account Engagement, Data Cloud) for consent capture, lawful basis, purpose limitation, preference center coverage, suppression list integrity, subscriber-key collision risk, deliverability authentication (SPF, DKIM, DMARC), and unsubscribe link integrity.",
+  "source_type": "original",
+  "official_docs": [
+    "https://help.salesforce.com/",
+    "https://developer.salesforce.com/docs"
+  ],
+  "security_notes": "Read-only static review; sanitized design documents only; never accesses live Marketing Cloud accounts or APIs. Lawful basis findings require verification by qualified privacy counsel. Regulated-data marketing flows escalated to compliance review.",
+  "last_verified": "2026-05-20",
+  "path": "skills/salesforce/salesforce-marketing-consent-review-skill",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}