@raishin/vanguard-frontier-agentic 2.0.0 → 2.1.0

package/skills/marketing/marketing-pixel-data-leakage-review/references/workflow-and-output.md

@@ -0,0 +1,129 @@
+# 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 visitor data, no ad-platform credentials):
+- Tag manager container export showing pixels, triggers, and the variables they read
+- Pixel snippets (Meta Pixel, TikTok Pixel, Google Ads / floodlight, LinkedIn Insight Tag, etc.)
+- A representative conversion or page-view event payload (the parameters actually sent)
+- The `dataLayer` specification or a sample `dataLayer` push
+- The list of page types the pixels load on, especially any sensitive-context pages
+- Whether advanced/automatic matching is enabled on any pixel
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly.
+
+### Step 2 — Page-context classification
+
+Classify the pages each pixel loads on before inspecting payloads. Context alone can be the leak:
+- **Special-category context**: health/medical, mental health, reproductive, financial hardship, loan/credit, legal, sexual orientation, religious, immigration.
+- **Authenticated context**: post-login account, transaction, order-history, or profile pages.
+- **General marketing context**: homepage, blog, top-of-funnel landing pages.
+
+Any advertising or social pixel firing in a special-category or authenticated context is HIGH on context alone — the URL, referrer, and page title reveal the person's circumstances regardless of payload contents.
+
+### Step 3 — Payload PII audit
+
+Inspect every parameter the pixel transmits. Flag direct identifiers and quasi-identifiers:
+
+```text
+# HIGH — raw email in the page URL, forwarded into the pixel page-view event
+https://example.com/welcome?email=jane.doe@example.com
+Meta Pixel: track('PageView')   # pixel reads location.href → email leaves the page
+
+# HIGH — PII pushed into dataLayer and mapped to event parameters
+dataLayer.push({ event: 'signup', user_email: 'jane.doe@example.com', phone: '+15551234567' });
+
+# CORRECT — only a non-identifying conversion signal
+dataLayer.push({ event: 'signup', signup_tier: 'free' });
+```
+
+Check for: email, phone, full name, postal address, date of birth, government IDs, account numbers, precise geolocation, and free-text fields that may contain any of the above.
+
+### Step 4 — Form-field auto-capture audit
+
+Identify any feature that captures form input without an explicit field allowlist:
+- Meta Pixel **Advanced Matching** (automatic) — scrapes form fields on the page.
+- Google **enhanced conversions** with auto-detection rather than a defined selector.
+- Tag-manager **form-submit** triggers with a variable capturing all field values.
+- Generic input/keystroke listeners.
+
+```text
+# HIGH — automatic advanced matching scrapes every form field on the page
+fbq('init', 'PIXEL_ID', {}, { autoConfig: true });
+
+# LOWER RISK — matching restricted to explicitly chosen, hashed fields
+fbq('init', 'PIXEL_ID');
+fbq('track', 'Lead');   # no automatic field scraping; identifiers handled server-side if needed
+```
+
+Auto-capture is HIGH because it collects whatever the visitor typed, including fields the marketer never intended to send.
+
+### Step 5 — Identifier-handling audit
+
+For any identifier intentionally sent for matching:
+- Confirm SHA-256 hashing where the ad platform's API requires it, and confirm hashing happens before transmission, not by the ad network on receipt.
+- Note that hashing is pseudonymization, not anonymization — it still constitutes disclosure of personal data and still requires a lawful basis and consent scope.
+- Confirm a redaction or allowlist layer strips PII from URLs and referrers before any pixel reads `location`.
+
+Missing hashing where required is HIGH. Missing a redaction layer is MEDIUM.
+
+### Step 6 — Payload minimization audit
+
+Conversion events should send the minimum signal needed for measurement:
+- A conversion flag and a coarse category are usually sufficient.
+- Precise revenue, full order line items, account balances, or SKU-level health/financial detail sent to an ad network is MEDIUM — it is more than measurement requires.
+
+### Step 7 — Consent-load ordering check
+
+Note whether pixels load before the consent signal. Flag as MEDIUM and explicitly defer the full consent-gating analysis to the `marketing-consent-data-collection-review` skill — do not duplicate that analysis here.
+
+### 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
+<payload provided | container provided | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security and scope notes
+
+- This is a static review. Never request real visitor data, real conversion logs, or ad-platform credentials. Work from sanitized payloads with placeholder values.
+- A leak found here may be a reportable breach under HIPAA, the FTC Health Breach Notification Rule, or state law — flag that possibility and route the determination to qualified counsel and the incident-response process. Do not make the breach-notification call yourself.
+- Never recommend a fix that keeps PII flowing to the ad network "but hashed" as a complete remedy — hashing is mitigation, not elimination.
+- Never recommend removing a pixel without naming the conversion measurement lost and a server-side or consent-scoped alternative.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.

package/skills/marketing/martech-access-governance-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: martech-access-governance-review
+description: Use this skill when reviewing access governance across a marketing technology stack — OAuth grants and connected apps, API keys and tokens, CRM and marketing-automation role assignments, and integration scopes. Trigger when a user provides an OAuth connected-app inventory, an integration scope list, a CRM/MAP role matrix, an API-key inventory, or asks whether their martech integrations are over-permissioned, whether stale connectors still hold live tokens, or how to apply least privilege to their marketing stack.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: security
+  lifecycle: experimental
+---
+
+# Martech Access Governance Review
+
+## Purpose
+This skill reviews identity and access governance across a marketing technology stack — the CRM, marketing automation platform, CDP, analytics, and the long tail of connected SaaS apps. Marketing operations accumulate OAuth grants, API keys, and seat permissions faster than any other business function, and rarely deprovision them. The result is a stack where third-party connectors hold full-CRM scopes, a single shared admin key authenticates a dozen tools, and a contractor's connected app still has a live refresh token a year after the engagement ended. This is one of the most exploited SaaS breach paths: the marketing stack holds the entire customer database and is governed loosely. The review catches over-broad OAuth scopes, shared and non-rotating credentials, stale grants, missing token expiry, and absent ownership before they become an incident.
+
+## Lean operating rules
+- Treat any third-party connected app granted a full-read or read-write scope over the entire CRM contact/lead database when its function needs a narrow scope as HIGH — over-broad scope is the blast radius if that vendor is breached.
+- Treat a single API key or service account shared across multiple tools or integrations as HIGH — it cannot be rotated or revoked without an outage, and a leak compromises every consumer.
+- Treat any long-lived API key or OAuth grant with no rotation schedule and no expiry as HIGH — a leaked non-expiring credential is valid until someone notices.
+- Treat a connected app, integration, or token tied to a departed employee, ended vendor engagement, or decommissioned tool that still holds a live grant as HIGH — stale credentials are unattended attack surface.
+- Treat a CRM or marketing-automation integration credentialed with an admin or owner role when an API-only or limited integration role exists as HIGH — privilege beyond function violates least privilege.
+- Treat a connected app or API key with no named human or team owner as HIGH — unowned credentials are never reviewed and never revoked.
+- Flag marketing user seats holding bulk-export or full-database-export permission beyond the few who need it as MEDIUM — bulk export is the exfiltration path.
+- Flag the absence of a recurring access-review cadence for connected apps and integration credentials as MEDIUM.
+- Flag OAuth grants that include offline-access / refresh-token scope where only short-lived interactive access is needed as MEDIUM.
+- Flag credentials transmitted or stored in plaintext (in tag managers, spreadsheets, shared docs, or automation tools) as HIGH.
+- Do not recommend revoking a grant without naming the integration it powers and the marketing workflow that breaks.
+- Label every finding with evidence basis: inventory provided, role matrix provided, documentation-based, or inference from missing config.
+
+## References
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review or formatting the final answer.
+
+## Response minimum
+Return, at minimum:
+- OAuth scope blast-radius findings (connected apps over-scoped vs function)
+- Shared / non-rotating credential findings
+- Stale grant findings (departed users, ended vendors, dead tools)
+- Integration role assessment (admin used where limited role exists)
+- Ownership and access-review cadence gaps
+- Bulk-export permission distribution assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/martech-access-governance-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "martech-access-governance-review",
+  "name": "Martech Access Governance Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review access governance across a marketing technology stack — OAuth connected apps, API keys, CRM and marketing-automation roles, and integration scopes — for least-privilege violations, shared and stale credentials, and missing ownership.",
+  "source_type": "original",
+  "official_docs": [
+    "https://datatracker.ietf.org/doc/html/rfc6749",
+    "https://oauth.net/2/scope/",
+    "https://csrc.nist.gov/glossary/term/least_privilege",
+    "https://owasp.org/www-project-top-ten/",
+    "https://csrc.nist.gov/pubs/sp/800/207/final"
+  ],
+  "security_notes": "A marketing technology stack holds the full customer database and accumulates OAuth grants, API keys, and seats faster than it deprovisions them. Over-broad connector scopes, shared non-rotating credentials, and stale grants from departed staff or ended vendors are a heavily exploited SaaS breach path. Review works from sanitized inventories only; never request, collect, or echo credential values, tokens, or secrets.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/martech-access-governance-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/marketing/martech-access-governance-review/references/workflow-and-output.md

@@ -0,0 +1,116 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide one or more of the following as sanitized inventories (redact every credential value — names and scopes only, never the secret itself):
+- Connected-app / OAuth grant inventory for the CRM and marketing automation platform (app name, scopes granted, grant date, owner)
+- API-key inventory (key name/label, the tool it authenticates, scope, rotation history — never the key value)
+- CRM and marketing-automation role matrix (roles, permissions, which integrations and users hold each)
+- The list of marketing tools in the stack and how each authenticates
+- Offboarding process for departed employees and ended vendor engagements, if documented
+
+If the user provides only a partial set, note which sections are absent and scope findings accordingly. If a user pastes an actual credential value, stop, tell them not to, and ask them to treat it as compromised and rotate it.
+
+### Step 2 — Build the integration map
+
+For each integration, record: what it is, what marketing function it performs, what data it touches, and the minimum scope that function requires. This "needed scope" baseline is what every granted scope is measured against.
+
+### Step 3 — OAuth scope blast-radius audit
+
+For every connected app, compare granted scope to needed scope.
+
+```text
+# HIGH — a form/survey tool granted full read-write over all CRM contacts
+App: SurveyTool
+Granted: crm.objects.contacts.read, crm.objects.contacts.write, crm.objects.deals.read
+Needed:  crm.objects.contacts.write  (it only creates contacts from form fills)
+
+# CORRECT — scope matches function
+App: SurveyTool
+Granted: crm.objects.contacts.write
+```
+
+Flag every scope granted beyond function as HIGH. The blast radius of any connected app is the data its scope can reach if that vendor is breached — and SaaS supply-chain breaches routinely pivot through exactly these grants.
+
+### Step 4 — Credential-sharing and rotation audit
+
+- A single API key or service account used by more than one tool or integration is HIGH — it cannot be rotated or revoked for one consumer without breaking the others, and a single leak compromises all of them.
+- Any key or grant with no rotation schedule and no expiry is HIGH.
+- A "personal" API key issued under an individual employee's account, rather than a dedicated integration identity, is MEDIUM — it breaks when they leave and carries their full personal permissions.
+
+### Step 5 — Stale-grant audit
+
+Identify grants that should no longer exist:
+- Connected apps or tokens owned by departed employees.
+- Grants from vendor engagements or trials that have ended.
+- Credentials for tools that were decommissioned but never disconnected.
+- OAuth refresh tokens that are still valid because nothing ever revoked them.
+
+Every live stale grant is HIGH — it is access nobody is watching.
+
+### Step 6 — Integration role audit
+
+Check the role each integration authenticates with:
+- An integration using an admin or owner role when an API-only or limited integration role exists is HIGH.
+- An integration that can change other users' permissions, billing, or security settings, when it only needs to read or write records, is HIGH.
+
+### Step 7 — Ownership and review-cadence audit
+
+- Every connected app and integration credential must have a named human or team owner. Unowned credentials are HIGH — nobody will ever review or revoke them.
+- There must be a recurring access-review cadence (for example, quarterly) covering connected apps and integration credentials. Its absence is MEDIUM.
+
+### Step 8 — Bulk-export and credential-storage audit
+
+- Identify which marketing seats hold full-database or bulk-export permission. This is the exfiltration path; it should be held by the few who need it. Broad distribution is MEDIUM.
+- Identify where credentials are stored. Credentials in spreadsheets, shared docs, tag-manager variables, or automation-tool fields in plaintext are HIGH. They belong in a secrets manager.
+
+### 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
+<inventory provided | role matrix provided | documentation-based | inference>
+
+## Findings
+
+### CRITICAL
+- [C1] <finding title>: <description> — <remediation>
+
+### HIGH
+- [H1] <finding title>: <description> — <remediation>
+
+### MEDIUM
+- [M1] <finding title>: <description> — <remediation>
+
+### LOW
+- [L1] <finding title>: <description> — <remediation>
+
+## Safe next actions
+1. <action>
+2. <action>
+
+## Open questions
+- <question requiring user clarification>
+```
+
+---
+
+## Security and scope notes
+
+- This is a static review. Never request, collect, store, or echo credential values, API keys, tokens, or secrets. Work from inventories of names and scopes only.
+- If the user pastes a real credential, treat it as compromised: tell them, and recommend immediate rotation.
+- Apply least privilege and zero-trust assumptions: every integration should hold the narrowest scope, the shortest-lived token, and a named owner.
+- Never recommend revoking a grant without naming the integration it powers and the marketing workflow that breaks — propose the scoped-down replacement grant alongside the revocation.
+- When evidence is partial, scope each finding to what was provided and state the assumption explicitly.

package/skills/marketing/programmatic-supply-chain-integrity-review/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: programmatic-supply-chain-integrity-review
+description: Use this skill when reviewing ads.txt, app-ads.txt, and sellers.json files for a publisher or advertiser's programmatic supply chain to detect unauthorized resellers, domain-spoofing exposure, and SupplyChain Object gaps. Trigger when a user provides an ads.txt file, an app-ads.txt file, a sellers.json endpoint response, or asks whether their programmatic supply chain has unauthorized intermediaries, IVT exposure, domain-spoofing risk, or whether their supply chain declaration satisfies IAB Tech Lab, MRC, or DSP procurement requirements.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: finops
+  lifecycle: experimental
+---
+
+# Programmatic Supply Chain Integrity Review
+
+## Purpose
+This skill reviews ads.txt, app-ads.txt, and sellers.json declarations for a publisher's or advertiser's programmatic supply chain to detect unauthorized resellers, domain-spoofing exposure, SupplyChain Object gaps, and IVT-exposure vectors. Ads.txt (IAB Tech Lab v1.1) and app-ads.txt are the publisher's machine-readable authorization of which exchanges and resellers may sell their inventory; sellers.json (IAB Tech Lab v1.0) is the exchange's machine-readable disclosure of which sellers it represents. When these files are inconsistent — an ads.txt RESELLER entry that no exchange discloses in sellers.json, a DIRECT entry that resolves as `is_confidential:1`, or a whitelisted domain whose ads.txt is absent — the supply chain is opaque to buyers, exposing them to unauthorized intermediary fees and exposing publishers to domain spoofing. The SupplyChain Object (OpenRTB extension) enables bid-time audit of the complete reseller path; gaps in the declared path are treated as invalid traffic by MRC-compliant measurement vendors and many DSP procurement teams. The review works from the raw text of the artifact files pasted as input and produces severity-labelled findings with remediation.
+
+## Lean operating rules
+- Treat ads.txt RESELLER entries for exchange accounts that do not appear in any sellers.json file for that exchange as HIGH — these are undisclosed intermediaries whose presence in the resale chain cannot be verified by buyers, constituting unauthorized supply path opacity under IAB Tech Lab ads.txt 1.1.
+- Treat a whitelisted publisher domain whose ads.txt file is entirely absent as HIGH — the absence means buyers cannot verify any authorized seller relationship; the domain is categorically IVT-exposed per MRC Invalid Traffic Detection guidelines and most DSP whitelisting criteria.
+- Treat a DIRECT entry in ads.txt where the corresponding seller account in sellers.json carries `is_confidential:1` as HIGH — a DIRECT relationship by definition requires transparent publisher identity; confidential resolution contradicts the DIRECT classification and is a domain-spoofing risk vector.
+- Treat ads.txt entries that reference exchange account IDs not present in the exchange's sellers.json at all (orphaned account IDs) as HIGH — the account cannot be verified as a legitimate seller, which is a signal of domain spoofing or stale declarations.
+- Treat a `seller_type: INTERMEDIARY` entry in sellers.json that has no corresponding ads.txt RESELLER entry on the publisher domain as MEDIUM — the intermediary is declared by the exchange but not authorized by the publisher, creating a supply path discrepancy.
+- Treat SupplyChain Object declarations with incomplete node chains (missing `asi`, `sid`, or `rid` fields in intermediate nodes) as MEDIUM — incomplete chains reduce bid-time auditability and may cause DSP procurement filters to reject the bid.
+- Flag MEDIUM when the ads.txt file has not been updated within twelve months and active exchange relationships are known to have changed — stale declarations expose revenue to unauthorized resellers who retain old account relationships.
+- Flag the absence of app-ads.txt for a mobile app publisher as MEDIUM when the publisher's ads.txt covers only web inventory — app inventory without app-ads.txt is unprotected by IAB Tech Lab supply-chain controls.
+- Do not recommend removing a RESELLER entry without first confirming whether it represents a legitimate revenue path that can be replaced with a DIRECT relationship or a disclosed intermediary.
+- Label every finding with evidence basis: ads.txt provided, sellers.json provided, documentation-based, or inference from absent file.
+
+## 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:
+- RESELLER-to-sellers.json consistency assessment (unauthorized intermediaries)
+- DIRECT-entry confidentiality conflict assessment (domain-spoofing risk)
+- Orphaned account ID assessment (account IDs in ads.txt not in sellers.json)
+- Absent ads.txt / app-ads.txt assessment for whitelisted domains
+- SupplyChain Object completeness assessment
+- Stale declaration assessment
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/marketing/programmatic-supply-chain-integrity-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "programmatic-supply-chain-integrity-review",
+  "name": "Programmatic Supply Chain Integrity Review",
+  "type": "skill",
+  "provider": "marketing",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review ads.txt, app-ads.txt, and sellers.json files for a publisher or advertiser's programmatic supply chain to detect unauthorized resellers, domain-spoofing exposure, and SupplyChain Object gaps.",
+  "source_type": "original",
+  "official_docs": [
+    "https://iabtechlab.com/ads-txt/",
+    "https://iabtechlab.com/sellers-json/",
+    "https://iabtechlab.com/supplychain-object/",
+    "https://mediaratingcouncil.org/sites/default/files/Standards/MRC%20Invalid%20Traffic%20Detection%20and%20Filtration%20Guidelines%20Addendum.pdf",
+    "https://iabtechlab.com/app-ads-txt/"
+  ],
+  "security_notes": "Supply chain integrity reviews work from the raw text of ads.txt, app-ads.txt, and sellers.json files pasted as input. Never request DSP credentials, exchange account tokens, or bid-stream logs. ads.txt and sellers.json are publicly resolvable files; the artifact is the publisher's or exchange's own exported text, not a live crawl of production endpoints.",
+  "last_verified": "2026-05-17",
+  "path": "skills/marketing/programmatic-supply-chain-integrity-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/marketing/programmatic-supply-chain-integrity-review/references/workflow-and-output.md

@@ -0,0 +1,164 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Collect inputs
+
+Ask the user to provide the following as raw pasted text (these are public files; no credentials required):
+- The full content of `ads.txt` from the publisher domain root (e.g., `example.com/ads.txt`)
+- The full content of `app-ads.txt` if the publisher has mobile app inventory
+- The relevant excerpt or full content of the exchange's `sellers.json` endpoint response — at minimum the entries corresponding to the publisher's account IDs
+- The list of exchanges and resellers the publisher has active relationships with, to identify stale or missing entries
+- SupplyChain Object node declarations if the user has access to bid-stream samples or SSP configuration exports
+
+If only ads.txt is provided without sellers.json, note that RESELLER-to-sellers.json consistency findings are inference only.
+
+### Step 2 — ads.txt structural audit
+
+Parse each line of the ads.txt file. Each valid entry has the format:
+```
+<exchange domain>, <publisher account ID>, <relationship>, <certification authority ID>
+```
+Where `<relationship>` is `DIRECT` or `RESELLER`.
+
+Check for:
+- Malformed lines (missing fields, incorrect field count, invalid relationship value).
+- Duplicate entries (same exchange domain + account ID combination appearing more than once).
+- Entries using IP addresses instead of domain names (not permitted by the spec).
+- Entries missing the certification authority ID (optional per spec, but flag absence as informational).
+
+```text
+# MALFORMED — missing account ID field
+openx.com, RESELLER
+
+# DUPLICATE — same entry appears twice
+appnexus.com, 12345, DIRECT, f08c47fec0942fa0
+appnexus.com, 12345, DIRECT, f08c47fec0942fa0
+```
+
+### Step 3 — RESELLER-to-sellers.json consistency audit
+
+For every RESELLER entry in ads.txt, cross-reference with the corresponding exchange's sellers.json:
+- Does the account ID appear in the exchange's sellers.json?
+- If present, does the `seller_type` match the expected value (PUBLISHER, INTERMEDIARY, or BOTH)?
+- Is the seller domain in sellers.json consistent with the publisher's domain?
+
+```text
+# HIGH — RESELLER entry with no sellers.json disclosure
+ads.txt: rubicon.com, 98765, RESELLER, 0bfd66d529a55807
+sellers.json (rubicon.com): account ID 98765 — not found
+→ unauthorized intermediary; buyer cannot verify the resale relationship
+
+# CORRECT — RESELLER disclosed in sellers.json
+ads.txt: rubicon.com, 11111, RESELLER, 0bfd66d529a55807
+sellers.json: { "seller_id": "11111", "name": "Example Publisher", "seller_type": "PUBLISHER", "domain": "example.com" }
+```
+
+Each RESELLER entry absent from sellers.json is a separate HIGH finding with the exchange domain and account ID as the finding identifier.
+
+### Step 4 — DIRECT entry confidentiality conflict audit
+
+For every DIRECT entry in ads.txt, cross-reference with sellers.json:
+- Is the account ID present in sellers.json?
+- Does the entry carry `is_confidential: 1`?
+
+A DIRECT entry by definition declares that the exchange sells the publisher's inventory with no intermediary. A `is_confidential: 1` flag in sellers.json means the exchange is hiding the seller's identity from buyers. This is contradictory and constitutes a domain-spoofing risk vector.
+
+```text
+# HIGH — DIRECT entry resolves as confidential in sellers.json
+ads.txt: exchange.com, 55555, DIRECT, abc123
+sellers.json: { "seller_id": "55555", "is_confidential": 1 }
+→ DIRECT relationship cannot be verified; domain-spoofing risk
+
+# CORRECT — DIRECT entry with transparent seller identity
+ads.txt: exchange.com, 55555, DIRECT, abc123
+sellers.json: { "seller_id": "55555", "name": "Example Publisher", "domain": "example.com", "is_confidential": 0 }
+```
+
+### Step 5 — Orphaned account ID audit
+
+Identify ads.txt entries where the account ID does not appear in the exchange's sellers.json at all (neither disclosed nor confidential):
+- This may indicate stale entries from a terminated exchange relationship.
+- It may also indicate domain spoofing: a bad actor adds a publisher's domain to their own exchange account without authorization.
+- Flag as HIGH; request the user confirm whether the exchange relationship is active.
+
+### Step 6 — Absent ads.txt audit for whitelisted domains
+
+If the user provides a list of domains they have whitelisted for programmatic buying:
+- For each domain, confirm whether ads.txt is present.
+- A whitelisted domain with no ads.txt is categorically IVT-exposed: the domain has not declared any authorized seller, meaning all inventory sourced from that domain bypasses supply-chain controls.
+- Flag each absent ads.txt as HIGH with the domain name.
+
+```text
+# HIGH — whitelisted domain with no ads.txt
+Domain: news-publisher.example.com
+ads.txt: not found (HTTP 404 / file absent)
+→ all inventory from this domain is unverifiable; IVT-exposed per MRC guidelines
+```
+
+### Step 7 — SupplyChain Object completeness audit
+
+If the user provides SupplyChain Object node declarations from bid-stream samples or SSP configuration:
+- Verify `complete: 1` is set — a value of 0 means the chain is declared incomplete, which MRC and most DSPs treat as an IVT signal.
+- For each intermediate node, verify `asi` (SSP domain), `sid` (account ID at that SSP), and `rid` (request ID, recommended) are present.
+- Flag missing required fields in intermediate nodes as MEDIUM.
+- Flag `complete: 0` as HIGH when it is set intentionally — it effectively declares the supply chain is unverifiable.
+
+### Step 8 — Stale declaration assessment
+
+Without a dated changelog, stale detection is inference:
+- If the user discloses that exchange relationships have changed in the past twelve months, flag stale declaration as MEDIUM.
+- Note that stale RESELLER entries may retain account IDs from terminated relationships that could be reused by unauthorized parties.
+
+### Step 9 — app-ads.txt coverage gap
+
+If the publisher has mobile app inventory:
+- Confirm app-ads.txt is present at the developer domain (as declared in the app store listing).
+- Absence is MEDIUM — mobile app inventory without app-ads.txt is outside IAB Tech Lab supply-chain protection.
+
+### Step 10 — Produce the output
+
+Format findings using the Output format section below.
+
+---
+
+## Output format
+
+```
+## Verdict
+<one sentence: pass / needs work / critical issues found>
+
+## Evidence level
+<ads.txt provided | sellers.json provided | app-ads.txt provided | documentation-based | inference from absent file>
+
+## 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. ads.txt, app-ads.txt, and sellers.json are public files. Never request DSP credentials, exchange account tokens, bid-stream logs, or revenue reports containing publisher financial data.
+- An unauthorized RESELLER entry may represent a legitimate old relationship that was not removed when the exchange contract ended, or it may represent an active unauthorized intermediary taking arbitrage margin. The distinction requires the publisher to confirm the exchange relationship status — do not assume malicious intent, but flag the opacity clearly.
+- Domain spoofing via DIRECT-to-confidential conflicts is a known fraud vector documented in MRC Invalid Traffic Detection guidelines. Surface the risk explicitly without overstating certainty about active fraud.
+- When evidence is partial (e.g., ads.txt provided but no sellers.json), scope findings to inference and state the assumption explicitly.
+- Do not recommend removing a RESELLER entry without first confirming whether it represents a legitimate revenue path that can be replaced with a DIRECT relationship or a disclosed intermediary — revenue loss from removing legitimate paths is a real operational risk.

package/skills/qa/ci-test-pipeline-review/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: ci-test-pipeline-review
+description: Use this skill when reviewing how a CI pipeline runs tests — gating, sharding, parallelism, fail-fast behavior, artifact retention, and flaky-test quarantine wiring. Trigger when a user provides a CI workflow file (GitHub Actions, GitLab CI, CircleCI, Jenkins), asks why CI is slow or unreliable as a merge gate, or wants to know whether their test pipeline actually blocks bad merges. This skill reviews CI configuration statically; it does not trigger or run pipelines.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-17"
+  category: delivery
+  lifecycle: experimental
+---
+
+# CI Test Pipeline Review
+
+## Purpose
+This skill reviews how a CI pipeline runs tests — not the tests themselves, but the pipeline that decides whether they block a merge. A test suite only protects the main branch if the pipeline runs it, runs it on the merge gate, fails the build when it fails, and finishes fast enough that developers do not route around it. The review catches non-blocking test steps, soft-failure escape hatches, missing required-check enforcement, un-sharded slow suites, fail-fast that hides parallel failures, missing artifacts, and quarantine lanes wired so that quarantined tests silently never run again.
+
+## Lean operating rules
+- Treat a test step that cannot fail the build — `|| true`, `continue-on-error: true`, `set +e`, an exit code swallowed, a non-blocking/optional check — as CRITICAL: the suite exists but gates nothing, and every "green" merge is unverified.
+- Treat tests that run only post-merge (on `push` to main, nightly) and not on the pull-request merge gate as HIGH — regressions are caught after they are already on the main branch.
+- Treat the test job not being a required status check for branch protection as HIGH — the run is advisory and a merge can proceed red. (Flag as inference if branch-protection config is not provided.)
+- Treat `fail-fast: true` on a test matrix as MEDIUM — it cancels sibling shards on the first failure, hiding how many shards actually failed and forcing repeated partial runs.
+- Treat a large suite in a single un-sharded job as HIGH when wall-clock time blocks merges — recommend a shard matrix sized to the suite.
+- Treat the absence of test-result and failure-artifact upload (JUnit XML, traces, screenshots, logs) as HIGH — a CI-only failure is then undebuggable and engineers re-run blindly.
+- Treat caching of dependencies/build but not keyed correctly (stale cache, no lockfile in the key) as MEDIUM — stale caches cause non-reproducible passes and failures.
+- Treat a quarantine lane that excludes flaky tests from gating with no scheduled non-blocking run and no tracking as HIGH — quarantined tests then never run again and the coverage is silently lost.
+- Treat secrets exposed to test jobs triggered by `pull_request_target` or to fork PRs as CRITICAL security exposure — flag and stop.
+- Treat a missing concurrency/cancel-in-progress group on PR test runs as LOW — wasted runners, not a correctness issue.
+- Do not recommend disabling or making a flaky check non-blocking as the fix — recommend quarantine with a scheduled run and an owner.
+- Label every finding with evidence basis: CI config provided, branch-protection config provided, documentation-based, or inference.
+
+## 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:
+- Gating findings (non-blocking steps, soft-failure escape hatches, required-check enforcement)
+- Merge-gate timing findings (PR vs. post-merge, sharding, parallelism)
+- Fail-fast and matrix configuration findings
+- Artifact and observability findings (test results, failure artifacts)
+- Quarantine-lane wiring findings
+- Security findings (secret exposure to test jobs)
+- Severity-labelled finding list (critical / high / medium / low)
+- Safe next actions

package/skills/qa/ci-test-pipeline-review/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "ci-test-pipeline-review",
+  "name": "CI Test Pipeline Review",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review how a CI pipeline runs tests — gating, sharding, parallelism, fail-fast, artifact retention, quarantine wiring, and secret exposure — to verify the test suite actually blocks bad merges. Static review only.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs",
+    "https://docs.github.com/en/repositories/configuring-branches-and-merges/about-protected-branches",
+    "https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions",
+    "https://docs.gitlab.com/ee/ci/yaml/",
+    "https://playwright.dev/docs/test-sharding"
+  ],
+  "security_notes": "Static review only — reads CI workflow and branch-protection configuration, never triggers or runs pipelines. Flags secret exposure to test jobs on pull_request_target or fork PRs. Never request or accept CI secrets, deploy keys, or registry tokens; ask for sanitized workflow files.",
+  "last_verified": "2026-05-17",
+  "path": "skills/qa/ci-test-pipeline-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}