@blamejs/exceptd-skills 0.13.3 → 0.13.5

package/data/_indexes/summary-cards.json

@@ -7,7 +7,7 @@
     "kernel-lpe-triage": {
       "description": "Assess Linux kernel LPE exposure — Copy Fail, Dirty Frag, live-patch vs. reboot remediation",
       "threat_context_excerpt": "An AI system discovered this vulnerability in approximately one hour. It is a page-cache copy-on-write (CoW) primitive in the Linux kernel affecting all major distributions since kernel 4.14 (2017). Every major Linux distribution is affected: RHEL 7–9, Ubuntu 18.04–24.04, Debian 9–12, CentOS, Fedora, Amazon Linux 2/2023, SUSE 12/15, Alpine, and derivatives.",
-      "produces": "Produce this structure:\n\n```\n## Kernel LPE Exposure Assessment\n\n**Assessment Date:** YYYY-MM-DD  \n**Kernel Version:** x.x.x  \n**Distribution:** [name + version]\n\n### Exposure Summary\n| CVE | Status | Severity |\n|-----|--------|----------|\n| CVE-2026-31431 (Copy Fail) | [Exposed / Live-patched / Patched] | [Critical/High/Medium/Low] |\n| CVE-2026-43284 (Dirty Frag ESP) | [Exposed / Patched] | [Critical/High/Medium/Low] |\n| CVE-2026-43500 (Dirty Frag RxRPC) | [Exposed / Patched] | [Critical/High/Medium/Low] |\n| CVE-2026-46300 (Fragnesia) | [Exposed / Module-unloaded / Live-patched / Patched] | [C ...",
+      "produces": "The triage produces a structured Kernel LPE Exposure Assessment per host or fleet snapshot. The shape below is consumed downstream by `exploit-scoring` (which converts the per-CVE exposure into RWEP bands), by `incident-response-playbook` (which uses the affected-host count to scope IR), and by `compliance-theater` (which compares the deployed-mitigation field against the org's claimed SI-2 / A.8.8 patch SLA). Operators surfacing the output to auditors should preserve the CISA KEV due-date field verbatim — federal due dates are the authoritative regulatory clock, not internal SLAs.\n\nProduce th ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-125",
@@ -62,7 +62,7 @@
     "ai-attack-surface": {
       "description": "Comprehensive AI/ML attack surface assessment mapped to MITRE ATLAS v5.4.0 with gap flags",
       "threat_context_excerpt": "The AI attack surface is not speculative. It is actively exploited. The following are confirmed, documented threats as of mid-2026.",
-      "produces": "```\n## AI Attack Surface Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [systems/applications assessed]\n\n### Surface Inventory\n| Component | Type | External Input | Tool Use | Risk Level |\n|-----------|------|---------------|----------|------------|\n| [name] | [LLM app / MCP server / coding assistant] | [Yes/No] | [Yes/No] | [Critical/High/Medium/Low] |\n\n### Prompt Injection Exposure\n[Per component: injection surface score, current defenses, estimated bypass rate, recommended controls]\n\n### MCP Trust Assessment\n[Per installed MCP server: signed/unsigned, allowlist status, auth status,  ...",
+      "produces": "The assessment produces a structured AI Attack Surface Assessment report. The shape below is consumed downstream by `mcp-agent-trust` (which converts the MCP Trust Assessment section into per-server policy), by `rag-pipeline-security` (which picks up any RAG-pipeline entries from the Surface Inventory), and by `incident-response-playbook` (which scopes IR against the prompt-injection and AI-C2 exposure bands). CSAF-style auditor evidence bundles consume the Framework Gaps and ATLAS TTP Coverage Gaps sections verbatim — preserve the framework-control IDs as cited.\n\n```\n## AI Attack Surface Asse ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1039",
@@ -116,7 +116,7 @@
     "mcp-agent-trust": {
       "description": "Enumerate MCP trust boundary failures — tool allowlisting, signed manifests, bearer auth, zero-interaction RCE",
       "threat_context_excerpt": "The Model Context Protocol (MCP) is an open protocol for connecting AI assistants to external tools and data sources. It is now the standard integration layer for AI coding assistants: Cursor, VS Code + GitHub Copilot, Windsurf, Claude Code, and Gemini CLI all support MCP servers. Background reality: 41% of 2025 zero-days were AI-discovered (GTIG 2025); Fragnesia (CVE-2026-46300, 2026-05-13) is the canonical AI-driven autonomous-discovery anchor — Zellic's agentic auditor surfaced an 18-year-old kernel primitive that load-bearing MCP-server hosts depend on. The first documented AI-built ...",
-      "produces": "```\n## MCP Trust Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [workstations / AI systems assessed]\n\n### Installed MCP Server Inventory\n| Server | Version | Source | Tools Exposed | Filesystem | Network | Shell | Auth Required | Allowlist |\n|--------|---------|--------|---------------|------------|---------|-------|---------------|-----------|\n\n### CVE-2026-30615 Exposure\n[Windsurf version check — patched/unpatched]\n\n### Trust Posture Score\n[Per server: Critical/High/Medium/Low with factor breakdown]\n\n### Immediate Actions Required\n[Servers to remove, versions to pin, configs to lock] ...",
+      "produces": "The skill produces a structured MCP Trust Assessment per workstation or fleet. The shape below is consumed downstream by `supply-chain-integrity` (which picks up the per-server hash and provenance fields), by `ai-attack-surface` (which integrates the MCP Trust posture into the broader AI surface report), and by `compliance-theater` (which compares the unallowlisted-server count against any vendor-management compliance claim). Operators feeding the output into MDM or endpoint-management policy should preserve the approved-server registry shape verbatim.\n\n```\n## MCP Trust Assessment\n\n**Assessmen ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-22",
@@ -209,7 +209,7 @@
     "compliance-theater": {
       "description": "Detect where an organization passes an audit but remains exposed — seven documented compliance theater patterns",
       "threat_context_excerpt": "The defining mid-2026 reality is that an organization can pass a clean ISO 27001:2022, SOC 2 Type II, or PCI DSS 4.0 audit while remaining exposed to KEV-listed deterministic LPEs and zero-interaction RCEs. The contrast cases drive every theater pattern below:",
-      "produces": "```\n## Compliance Theater Assessment\n\n**Date:** YYYY-MM-DD\n**Framework(s):** [in scope]\n\n### Theater Detection Results\n\n| Pattern | Finding | Key Evidence |\n|---------|---------|--------------|\n| Patch Management | THEATER / CLEAR | [e.g., \"CISA KEV average remediation time: 18 days\"] |\n| Network Segmentation (IPsec) | THEATER / CLEAR | [e.g., \"CVE-2026-43284 unpatched on 12 of 40 hosts using IPsec\"] |\n| Access Control (AI Agents) | THEATER / CLEAR | [e.g., \"No prompt-level logging on Copilot deployments\"] |\n| Incident Response (AI) | THEATER / CLEAR | [e.g., \"Zero AI-specific playbooks in IR  ...",
+      "produces": "The skill produces a structured Compliance Theater Assessment that scores each of the seven theater patterns and surfaces the auditor-facing remediation language for any flagged pattern. The shape below is consumed downstream by `policy-exception-gen` (which converts theater flags into defensible exceptions with concrete compensating controls), by `framework-gap-analysis` (which escalates any newly discovered theater pattern into a Framework Lag Declaration), and by `global-grc` (which rolls up theater findings across EU/UK/AU/ISO jurisdictions per Hard Rule #5). Auditor-facing remediation lan ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -238,7 +238,7 @@
     "exploit-scoring": {
       "description": "Real-World Exploit Priority (RWEP) scoring — CVSS plus KEV, PoC, AI-acceleration, blast radius, live-patch factors",
       "threat_context_excerpt": "RWEP exists because the exploit development cycle has compressed. The factors that CVSS does not model are now the dominant signal in real-world prioritization.",
-      "produces": "```\n## Exploit Priority Assessment\n\n**CVE:** [ID]\n**Assessment Date:** YYYY-MM-DD\n\n### CVSS vs. RWEP\n| Metric | Score | Priority Band |\n|--------|-------|---------------|\n| CVSS | [score] | [None/Low/Medium/High/Critical] |\n| RWEP | [score] | [see table above] |\n| Delta | [RWEP - CVSS×10] | [Explain if significant] |\n\n### RWEP Factor Breakdown\n| Factor | Value | Points |\n|--------|-------|--------|\n| CISA KEV | Yes/No | +25/0 |\n| PoC Public | Yes/No | +20/0 |\n| AI-Assisted | Yes/No | +15/0 |\n| Active Exploitation | Confirmed/Suspected/No | +20/+10/0 |\n| Blast Radius | [description] | [0-15] |\n ...",
+      "produces": "The skill produces a per-CVE Exploit Priority Assessment showing the RWEP score, the factor breakdown (CVSS, KEV, PoC, AI-acceleration, blast radius, live-patch availability), the required-action timeline, and any framework-SLA conflict. The shape below is consumed downstream by `kernel-lpe-triage` (for kernel-class CVEs), by `compliance-theater` (which compares the RWEP-required timeline against the org's CVSS-banded SLA), and by `incident-response-playbook` (which scopes IR per the required-action band). Preserve the RWEP factor rows verbatim — they are the auditable derivation.\n\n```\n## Expl ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -265,7 +265,7 @@
     "rag-pipeline-security": {
       "description": "RAG-specific threat model — embedding manipulation, vector store poisoning, retrieval filter bypass, indirect prompt injection",
       "threat_context_excerpt": "Retrieval-Augmented Generation (RAG) pipelines introduce a unique attack surface that exists at the intersection of traditional data security and AI-specific vulnerabilities. No current compliance framework has adequate controls for this attack surface. The threats in this skill are not theoretical — they have been demonstrated in research and observed in production incidents. Operational context: 41% of 2025 zero-days were AI-discovered (GTIG 2025); the first AI-built in-the-wild zero-day surfaced 2026-05-11 (GTIG AI 2FA-bypass), and Fragnesia (CVE-2026-46300, 2026-05-13) is the canonical ...",
-      "produces": "```\n## RAG Pipeline Security Assessment\n\n**Date:** YYYY-MM-DD\n**Knowledge Base:** [description]\n**Query Volume:** [requests/day estimate]\n\n### Pipeline Map\n[Ingestion → Chunking → Embedding → Store → Retrieval → Context → LLM → Output]\n\n### Attack Class Exposure\n| Attack Class | Possible | Attacker Access Required | Current Mitigations | Risk |\n|---|---|---|---|---|\n| Embedding manipulation (exfil) | | | | |\n| Vector store poisoning | | | | |\n| Chunking exploitation | | | | |\n| Retrieval filter bypass | | | | |\n| Indirect prompt injection | | | | |\n\n### RAG Security Score: [X/80]\n\n### Priority ...",
+      "produces": "The skill produces a structured RAG Pipeline Security Assessment covering vector-store inventory, embedding-model trust posture, retrieval-policy coverage, and observed exfiltration risk per corpus. The shape below is consumed downstream by `ai-attack-surface` (which integrates the per-corpus risk band into the broader AI surface report), by `dlp-gap-analysis` (which picks up the retrieval-policy gaps as DLP-channel findings), and by `mlops-security` (which inherits the embedding-model trust assessment). Operators feeding the output into auditor evidence should preserve the per-corpus retrieva ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1395",
@@ -314,7 +314,7 @@
     "ai-c2-detection": {
       "description": "Detect adversary use of AI APIs as covert C2 — SesameOp pattern, PROMPTFLUX/PROMPTSTEAL behavioral signatures",
       "threat_context_excerpt": "The AI-as-adversary reality that motivates this skill is now operationally documented: 41% of 2025 zero-days were AI-discovered (GTIG 2025), the first AI-built in-the-wild zero-day was confirmed 2026-05-11 (GTIG AI 2FA-bypass case), and Fragnesia (CVE-2026-46300, 2026-05-13) is the canonical AI-driven autonomous-discovery anchor — Zellic's agentic auditor surfaced an 18-year-old Linux kernel primitive. C2 channels riding the same agentic AI infrastructure are the next logical step; CTID Secure AI v2 (2026-05-06, replaces v1) treats AI-API C2 detection as an in-scope control class.",
-      "produces": "```\n## AI C2 Detection Assessment\n\n**Date:** YYYY-MM-DD\n**Scope:** [hosts / network segments assessed]\n\n### Current Detection Coverage\n| Detection Layer | Deployed | Coverage |\n|---|---|---|\n| Process-level AI API baseline | Yes/No | [% of host types covered] |\n| Behavioral correlation (AI + file/cred/scan) | Yes/No | [configured correlations] |\n| TLS inspection for AI traffic | Yes/No | [% of AI API traffic] |\n| Response monitoring | Yes/No | [coverage] |\n\n### Coverage Gaps\n[What's missing from the detection architecture]\n\n### Active Indicators\n[If this is a live investigation: current IOCs,  ...",
+      "produces": "The skill produces a structured AI C2 Detection Assessment covering per-host AI-API egress baselines, behavioral anomaly indicators, and SesameOp-class C2-pattern findings. The shape below is consumed downstream by `incident-response-playbook` (which scopes IR against confirmed C2 indicators), by `ai-attack-surface` (which integrates the detection-gap section into the broader AI surface report), and by `compliance-theater` (which compares the AI-API monitoring coverage against any SI-4 / CC7 anomaly-detection compliance claim). Preserve the per-host egress-baseline shape verbatim — it is the l ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [
@@ -397,7 +397,7 @@
     "threat-model-currency": {
       "description": "Score how current an org's threat model is against 2026 reality — 14-item checklist, currency percentage, prioritized update roadmap",
       "threat_context_excerpt": "Most organizational threat models in circulation today are 2022–2024 vintage. They were written before the operational reality of mid-2026:",
-      "produces": "```\n## Threat Model Currency Assessment\n\n**Date:** YYYY-MM-DD\n**Threat Model Version:** [document version / last update date]\n\n### Currency Score: [X / 28] = [percentage]%\n**Rating:** [Current / Mostly current / Partially current / Significantly stale / Critically stale]\n\n### Class-by-Class Scoring\n| # | Threat Class | Score | Finding |\n|---|---|---|---|\n| 1 | AI-Discovered Kernel Vulnerabilities | 0/1/2 | [specific gap or confirmation] |\n| 2 | Deterministic Kernel LPE | 0/1/2 | |\n| 3 | IPsec Subsystem Exploitation | 0/1/2 | |\n| 4 | Prompt Injection as Enterprise RCE | 0/1/2 | |\n| 5 | MCP Supp ...",
+      "produces": "The skill produces a structured Threat Model Currency Assessment that scores the threat model against each of the 14 threat classes, computes a currency percentage, and emits a priority update roadmap. The shape below is consumed downstream by `framework-gap-analysis` (which converts per-class gaps into Framework Lag Declarations), by `policy-exception-gen` (which generates defensible exceptions for any class the operator cannot remediate immediately), and by `global-grc` (which rolls up the currency score across EU/UK/AU/ISO jurisdictions per Hard Rule #5). Preserve the per-class scoring rows ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -421,7 +421,7 @@
     "global-grc": {
       "description": "Multi-jurisdiction GRC mapping — EU (GDPR/NIS2/DORA/EU AI Act/CRA), UK, AU, SG, JP, IN, CA, ISO 27001:2022, CSA CCM v4",
       "threat_context_excerpt": "US-only GRC posture is structurally incomplete for any organisation operating across EU, UK, AU, SG, IN, JP, or CA in mid-2026. The following regulatory instruments are in force or about to be, and have no direct US-framework equivalent:",
-      "produces": "```\n## Global GRC Assessment\n\n**Date:** YYYY-MM-DD\n**Jurisdictions in scope:** [list]\n**Sectors:** [list]\n\n### Applicable Framework Matrix\n| Framework | Jurisdiction | Trigger | Notification | Penalties | AI Coverage |\n|-----------|-------------|---------|--------------|-----------|-------------|\n\n### Fastest Notification Requirement\n[Which jurisdiction, which framework, what timeline]\n\n### Strictest AI/Security Requirements\n[For current threats: which framework is most demanding]\n\n### Universal Gaps\n[Threats that no applicable framework covers adequately]\n\n### Per-Threat Framework Mapping\n[Fo ...",
+      "produces": "The skill produces a structured Global GRC Assessment that rolls compliance findings across the org's jurisdictional footprint — EU (NIS2, DORA, EU AI Act, CRA), UK (CAF, Cyber Essentials), AU (ISM, Essential 8, APRA CPS 234), ISO 27001:2022 / 42001:2023, NIST, and the expanded set tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `framework-gap-analysis` (which produces per-jurisdiction Framework Lag Declarations), by `policy-exception-gen` (for cross-jurisdictional exception language), and by CSAF-style auditor evidence bundles. Preserve the per-jurisdiction ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -445,7 +445,7 @@
     "zeroday-gap-learn": {
       "description": "Run the zero-day learning loop — CVE to attack vector to control gap to framework gap to new control requirement",
       "threat_context_excerpt": "The zero-day learning cycle has compressed. The frameworks have not.",
-      "produces": "```\n## Zero-Day Learning Loop: [CVE-ID / Vulnerability Name]\n\n**Date:** YYYY-MM-DD\n**RWEP:** [score]\n\n### Attack Vector\n[Extracted attack vector analysis]\n\n### Defense Chain Analysis\n| Layer | Required Control | Framework Coverage |\n|---|---|---|\n| Prevention | [control] | [Covered/Insufficient/Missing] |\n| Detection | [control] | [Covered/Insufficient/Missing] |\n| Response | [control] | [Covered/Insufficient/Missing] |\n\n### Framework Coverage Matrix\n[Per-framework table]\n\n### Gap Classification\n[Missing entirely / Insufficient / Compliant-but-exposed]\n\n### New Control Requirements\n[Generated  ...",
+      "produces": "The skill produces a Zero-Day Learning Loop entry per CVE, capturing attack-vector extraction, control-gap identification, framework coverage assessment, the new control requirement that closes the gap, and an exposure score for the org's environment. The shape below is consumed downstream by `framework-gap-analysis` (which converts the new control requirement into a Framework Lag Declaration), by `defensive-countermeasure-mapping` (which maps the requirement to D3FEND IDs), and by `data/zeroday-lessons.json` (which inherits the lesson entry as a persistent record). Preserve the attack-vector  ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -469,7 +469,7 @@
     "pqc-first": {
       "description": "Post-quantum cryptography first mentality — hard version gates (OpenSSL 3.5+), algorithm sunset tracking, HNDL assessment, loopback learning for NIST/IETF evolution",
       "threat_context_excerpt": "The post-quantum migration is not a planning exercise. It is an operational deadline against an adversary that is already collecting ciphertext.",
-      "produces": "```\n## PQC Readiness Assessment\n\n**Date:** YYYY-MM-DD\n**OpenSSL version:** [X.X.X] — [Pass ≥3.5.0 / FAIL]\n\n### Algorithm Inventory\n| Usage | Current Algorithm | PQC Status | Version Gate | Migration Required |\n|---|---|---|---|---|\n\n### HNDL Exposure\n| Data Type | Sensitivity Window | Key Exchange | HNDL Risk | Action |\n|---|---|---|---|---|\n\n### Version Gate Compliance\n[Per library: pass/fail with specific version found]\n\n### Migration Roadmap\n[Priority-ordered, specific to this system's algorithm inventory]\n\n### Forward Watch Status\n[Which tracked standards have updated since last review; wh ...",
+      "produces": "The skill produces a structured PQC Readiness Assessment that scores the org's post-quantum migration posture against the NIST PQC standards (ML-KEM / FIPS 203, ML-DSA / FIPS 204, SLH-DSA / FIPS 205), CNSA 2.0, and the BSI / ANSSI / NCSC migration guidance. The shape below is consumed downstream by `crypto` playbook runs (which feed the assessment into Phase 5 analyze), by `framework-gap-analysis` (for SC-8 / SC-13 / A.8.24 / A.10 lag declarations), and by `compliance-theater` (which compares the harvest-now-decrypt-later exposure against the org's data-classification claims). Preserve the per ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-327"
@@ -510,7 +510,7 @@
     "skill-update-loop": {
       "description": "Meta-skill for keeping all exceptd skills current — CISA KEV triggers, ATLAS version updates, framework amendments, forward_watch resolution, currency scoring",
       "threat_context_excerpt": "The threat context this skill defends against is not a specific adversary technique — it is the **drift attack against the platform's own currency**: an exceptd installation whose skills, catalogs, framework references, and ATLAS pins age silently between releases until the operator-facing analysis is calibrated to a threat model that no longer exists.",
-      "produces": "```\n## Skill Update Loop Report\n\n**Date:** YYYY-MM-DD\n**Last Full Review:** [date from manifest.json]\n\n### Unprocessed Triggers\n| Trigger Type | Item | Affected Skills | Urgency |\n|---|---|---|---|\n\n### Skill Currency Scores\n| Skill | Last Review | Currency Score | Status |\n|---|---|---|---|\n\n### Prioritized Update Tasks\n[Ordered by urgency: specific skill, specific section, specific required change]\n\n### Forward Watch Status\n[Per skill's forward_watch items: resolved/pending/newly added]\n```\n\n---",
+      "produces": "The skill produces a Skill Update Loop Report covering per-skill `last_threat_review` currency, ATLAS / ATT&CK / D3FEND / CWE catalog version drift, CISA KEV additions since the last review, and the priority queue of skills requiring body updates before the next release. The shape below is consumed downstream by the release-cadence maintainer workflow, by `data/_meta` tracking, and by the predeploy `watchlist` gate. Preserve the per-skill drift columns verbatim — they are the auditable trigger for each forced body refresh.\n\n```\n## Skill Update Loop Report\n\n**Date:** YYYY-MM-DD\n**Last Full Revi ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -534,7 +534,7 @@
     "security-maturity-tiers": {
       "description": "Three-tier implementation roadmap — MVP (ship this week), Practical (scalable today), Overkill (defense-in-depth)",
       "threat_context_excerpt": "The 2026 threat baseline forces an MVP that would have looked like a Practical tier in 2022. The cardinal observed change: attacker capability now compresses the time from disclosure to reliable exploitation to hours for an entire class of vulnerabilities, and AI-mediated attack surfaces (prompt injection, MCP supply chain, AI-API C2) sit outside the perimeter and identity controls every framework relies on. The implications by tier:",
-      "produces": "```\n## Security Maturity Roadmap\n\n**Date:** YYYY-MM-DD\n**Domains in scope:** [list]\n**Current state:** [assessment]\n**Constraint:** [time / team / compliance / budget]\n\n### Priority Sequence\n[Week 1 / Month 1 / Quarter 1 / Year 1 items]\n\n### Domain: [name]\n\n#### Tier 1 — MVP (Ship this week)\n[Specific commands, configurations, verification steps]\n**Done when:** [concrete completion criteria]\n**Cost:** [hours, no new tools needed / minimal tooling]\n\n#### Tier 2 — Practical (Quarter 1)\n[Scalable, monitored, sustainable]\n**Adds:** [what Tier 1 misses that Tier 2 provides]\n**Cost:** [operational o ...",
+      "produces": "The skill produces a Security Maturity Roadmap that scores each in-scope domain against the published tier definitions and surfaces the next-tier upgrade path with budget bands and dependency ordering. The shape below is consumed downstream by `policy-exception-gen` (for domains where the operator chooses a lower tier than the threat model requires), by `compliance-theater` (which compares the claimed tier against deployed controls), and by `global-grc` (for cross-jurisdictional tier obligations). Preserve the per-domain tier rows verbatim — they are the auditable baseline for the upgrade plan ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1188"
@@ -560,7 +560,7 @@
     "researcher": {
       "description": "Triage entry-point for raw threat intel — researches an input across all exceptd data catalogs, RWEP-scores it, and routes the operator to the right specialized skill(s)",
       "threat_context_excerpt": "Most security teams in mid-2026 sit on a torrent of raw threat input: CISA KEV additions, vendor advisories, ATLAS updates, red-team reports, internal SIEM alerts, framework amendment bulletins, supply-chain notices. The two failure modes are symmetric and equally damaging.",
-      "produces": "```\n# Researcher Triage Report — <input>\n\n## What this is\n<one-line classification + canonical reference>\nExample: \"CVE — Linux kernel LPE. Canonical: CVE-2026-31431 (Copy Fail).\"\n\n## RWEP-anchored priority\nRWEP: <score> / 100   CVSS: <score> (for compatibility, not primary)\nDrivers: <CISA KEV: yes/no> | <Public PoC: yes/no> | <AI-discovered/AI-accelerated: yes/no> | <Blast radius: scope> | <Live-patch: available/unavailable> | <Reboot required: yes/no>\nDeterminism: <deterministic / probabilistic with race> | Exploit size: <bytes or LOC if known>\nCatalog status: <full entry present | partial | ...",
+      "produces": "The skill produces a Researcher Triage Report that converts a free-form research query (CVE ID, threat-actor name, framework reference, RFC number, vendor advisory) into a structured triage: canonical identifier, threat-currency assessment, the skill(s) that own follow-on analysis, and the suggested next operator action. The shape below is consumed downstream by `exceptd dispatch` (which routes to matching skills) and by the operator's investigation queue. Preserve the canonical-reference field verbatim — it is the load-bearing field for downstream skill chaining.\n\n```\n# Researcher Triage Repo ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -584,7 +584,7 @@
     "attack-surface-pentest": {
       "description": "Modern attack surface management + pen testing methodology for AI-era environments — NIST 800-115, OWASP WSTG, PTES, ATT&CK-driven adversary emulation, TIBER-EU",
       "threat_context_excerpt": "The attack surface is no longer a list of internet-facing IPs and web apps. By mid-2026 the surface a competent adversary maps for a target enterprise includes seven distinct, simultaneously exploitable layers — and the typical pen test scope covers two of them.",
-      "produces": "```\n## Penetration Test Report — [Engagement Name]\n\n**Engagement window:** [start] – [end]\n**Tester(s) / firm:** [names + certifications]\n**Authorising party:** [client representative]\n**Scope reference:** [PTES Pre-engagement document / TIBER-EU TI-Provider report / equivalent]\n\n### 1. Executive summary\n- Top 5 findings by RWEP, one sentence each.\n- Defense-in-depth verdict: which layers held, which failed.\n- Zero-trust verdict: were implicit-trust crossings reachable?\n- Overall posture characterisation against the mid-2026 attack surface.\n\n### 2. Scope and rules of engagement\n[Verbatim or re ...",
+      "produces": "The skill produces a Penetration Test Report covering scoped attack surface, engagement window, per-finding RWEP-prioritized severity, exploit-chain narrative, and prioritized remediation. The shape below is consumed downstream by `incident-response-playbook` (which scopes IR for any findings that crossed into production data), by `exploit-scoring` (which validates the per-finding RWEP score), and by `compliance-theater` (which compares the findings against the org's claimed control coverage). Preserve the per-finding evidence chain verbatim — it is the load-bearing field for client legal-revi ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1395",
@@ -638,7 +638,7 @@
     "fuzz-testing-strategy": {
       "description": "Continuous fuzzing as a security control — coverage-guided fuzz (AFL++/libFuzzer), AI-assisted fuzz, OSS-Fuzz integration, kernel fuzz (syzkaller), AI-API fuzz, integration into CI/CD as compliance evidence",
       "threat_context_excerpt": "By mid-2026 the asymmetry between offensive and defensive fuzzing has flipped. The defender's question is no longer \"should we fuzz?\" — it is \"are we fuzzing as fast as attackers are fuzzing us?\"",
-      "produces": "```\n## Fuzz Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Component / Estate:** [scope]\n**Assessor:** [role]\n\n### Fuzz-Eligible Interface Inventory\n| Interface | Class | Harness Present | Tool | CI-Gated | Last Run |\n|---|---|---|---|---|---|\n| [name] | parser/IPC/API/kernel/LLM | Yes/No | [AFL++/libFuzzer/syzkaller/RESTler/garak/...] | Yes/No | YYYY-MM-DD |\n\n### Coverage Report\n| Harness | Line Coverage | Branch Coverage | CPU-Hours / Release | Uncovered Reachable Code |\n|---|---|---|---|---|\n| [name] | [N]% | [N]% | [N] | [list of un-fuzzed reachable functions] |\n\n### Crash Inventory ...",
+      "produces": "The skill produces a Fuzz Posture Assessment covering fuzz-eligible interface inventory, harness coverage, crash inventory, and quarter-over-quarter CWE-class trend. The shape below is consumed downstream by `zeroday-gap-learn` (which appends internally found crashes as lesson entries), by `compliance-theater` (which compares the harness-coverage gap against SAMM / BSIMM / SDL compliance claims), and by the SBOM evidence chain (which inherits the per-component fuzz-instrumentation status). Preserve the per-interface CI-gated field verbatim — it distinguishes deployed fuzzing from one-shot secu ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-125",
@@ -681,7 +681,7 @@
     "dlp-gap-analysis": {
       "description": "DLP gap analysis for mid-2026 — legacy DLP misses LLM prompts, MCP tool args, RAG retrievals, embedding-store exfil, and code-completion telemetry. Audit channels, classifiers, protected surfaces, enforcement actions, and evidence trails against modern threat reality and cross-jurisdictional privacy regimes",
       "threat_context_excerpt": "DLP's protected surface inverted between 2024 and 2026. Crown-jewel data is no longer \"rows in this database\" — it is \"anything that crosses an LLM context window.\" Legacy DLP (outbound email, web upload, USB removable media) is solved in the sense that every commercial DLP suite covers those channels and every prescriptive framework cites them. The compliance-relevant exfiltration channels of 2026 are different: free-form LLM prompts, file attachments and RAG retrievals placed into model context, MCP tool-call arguments, code-completion context windows, IDE and dev-tool telemetry, and ...",
-      "produces": "```\n## DLP Gap Analysis\n\n**Date:** YYYY-MM-DD\n**Scope:** [org units, tenants, network segments assessed]\n**Frameworks in scope:** [list, including jurisdictions]\n\n### AI Tool Inventory (Step 1)\n| Tool | Sanctioned? | Identities Using | First Seen | Channel(s) |\n|---|---|---|---|---|\n\n### Channel × Surface × Control Matrix (Steps 2–4)\nFor each tool × channel × protected surface intersection: which DLP control applies (ID from `data/dlp-controls.json`), deployment state (Deployed / Deployed-untuned-for-AI / Absent), residual risk note.\n\n### Gap Register (Step 5)\n| Gap ID | Channel × Surface | Mi ...",
+      "produces": "The skill produces a DLP Gap Analysis covering per-channel coverage (email, web, endpoint, cloud-storage, LLM-prompt, RAG-retrieval), policy enforcement evidence, and the prioritized roadmap to close LLM/RAG exfiltration channels that traditional DLP misses. The shape below is consumed downstream by `ai-attack-surface` (which integrates the LLM-prompt and RAG-retrieval gaps), by `email-security-anti-phishing` (which inherits the email-egress channel findings), and by `compliance-theater` (which compares the deployed DLP channels against the org's claimed data-protection compliance). Preserve t ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1426",
@@ -733,7 +733,7 @@
     "supply-chain-integrity": {
       "description": "Supply-chain integrity for mid-2026 — SLSA L3+, in-toto attestations, Sigstore signing, SBOM (CycloneDX/SPDX), VEX via CSAF 2.0, AI-generated code provenance, model weights as supply-chain artifacts",
       "threat_context_excerpt": "The supply chain has expanded far beyond \"a vulnerable dependency in npm or PyPI.\" In mid-2026 the in-scope artifacts are every build-pipeline input, every CI runner image, every container base, every transitive package, every model weight loaded at inference time, and every snippet of code generated by an AI coding assistant and committed to the repository.",
-      "produces": "```\n## Supply-Chain Integrity Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [pipelines / repositories / model registries / runtime environments assessed]\n**Frameworks in scope:** [NIST 800-218 SSDF | NIST 800-161 | ISO 27001:2022 A.5.21 | EU CRA | EU AI Act | UK NCSC | AU ISM / IRAP | PCI 4.0]\n\n### Pipeline SLSA Scorecard\n| Pipeline | Type (CI / model-train / AI-codegen) | Runner | Current SLSA Level | Provenance Signed? | Attestation Chain? | Gap |\n\n### SBOM Coverage\n| Artifact Class | Format (CycloneDX 1.6 / SPDX 3.0) | Build-Time SBOM | Deploy-Time SBOM | ML-BOM Where Applicable |  ...",
+      "produces": "The skill produces a Supply-Chain Integrity Assessment covering per-pipeline build provenance, SLSA / in-toto / sigstore attestation coverage, SBOM completeness, dependency-risk inventory, and the prioritized roadmap to close gaps against EU CRA, NIST 800-218, and the expanded global framework set. The shape below is consumed downstream by `mcp-agent-trust` (for AI-tool supply-chain rows), by `mlops-security` (for model-artifact provenance), and by `compliance-theater` (which compares the deployed attestation surface against EU CRA Annex I claims). Preserve the per-pipeline attestation rows ve ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1357",
@@ -787,7 +787,7 @@
     "defensive-countermeasure-mapping": {
       "description": "Map offensive findings (CVE / TTP / framework gap) to MITRE D3FEND defensive countermeasures with explicit defense-in-depth, least-privilege, and zero-trust layering",
       "threat_context_excerpt": "ATT&CK and ATLAS are now load-bearing in SOC detection engineering. Detection content is written against technique IDs; red-team reports are mapped to technique IDs; threat intel feeds emit technique IDs. The result: the offensive side of every blue-team discussion is technique-grained and crisp.",
-      "produces": "```\n# Defensive Countermeasure Map — <input>\n\n## What this is\n<one-line classification + canonical reference>\nExample: \"CVE — Linux kernel LPE. Canonical: CVE-2026-31431 (Copy Fail).\"\n\n## Offensive technique set (input to D3FEND query)\n- <AML.T0001-or-similar / T0001-or-similar / CWE-<id> list, with one-line descriptions>\n\n## Defensive-coverage map\n| D3FEND ID | Name | Tactic (DiD layer) | Privilege scope | ZT posture | Deployed? | AI-pipeline applicable? | Framework controls partially mapped | Live-tunable? |\n|-----------|------|--------------------|-----------------|------------|-----------| ...",
+      "produces": "The skill produces a Defensive Countermeasure Map per input (CVE ID, ATLAS / ATT&CK TTP, threat-actor profile, or framework gap), pairing each offensive technique with the D3FEND defensive technique that disrupts it and the deployment layer that owns it. The shape below is consumed downstream by `framework-gap-analysis` (which wraps the map into Framework Lag Declarations), by `policy-exception-gen` (which converts the map into compensating-control language for defensible exceptions), and by every per-domain skill's own Defensive Countermeasure Mapping section. Preserve the D3FEND IDs verbatim ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [
@@ -832,7 +832,7 @@
     "identity-assurance": {
       "description": "Identity assurance for mid-2026 — NIST 800-63 AAL/IAL/FAL, FIDO2/WebAuthn passkeys, OIDC/SAML/SCIM, agent-as-principal identity, short-lived workload tokens, OAuth 2.0 + RFC 9700 BCP",
       "threat_context_excerpt": "Identity is the new perimeter, and the perimeter expanded. The 2026 principal population is no longer \"humans + service accounts\" — it now includes AI agents acting on behalf of users, MCP servers exchanging short-lived tokens, and ephemeral workload identities minted per function invocation. Each of these is a principal that authenticates, holds scopes, and shows up in audit logs — and each was outside the design envelope of every identity standard in production use before NIST 800-63 rev 4 (Q4 2025).",
-      "produces": "```\n## Identity Assurance Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [org units / IdPs / SaaS apps / workload clusters / AI-agent fleets in scope]\n**Jurisdictions:** [EU NIS2 / DORA, UK CAF, AU ISM, ISO 27001, plus IL INCD / CH FINMA / JP FISC / SG MAS / IN CERT-In / NY DFS where applicable]\n\n### Per-Principal Assurance Scorecard\n| Principal | Class (Human/Service/Agent) | Current AAL | Target AAL | Current IAL | Target IAL | Current FAL | Target FAL | Gap |\n|-----------|----------------------------|-------------|------------|-------------|------------|-------------|------------|-- ...",
+      "produces": "The skill produces an Identity Assurance Assessment covering per-IdP AAL/IAL/FAL posture, passkey / WebAuthn / FIDO2 deployment coverage, agent-identity scoping (workload, service-account, AI-agent principal), and the prioritized roadmap to close phishing-resistance gaps. The shape below is consumed downstream by `idp-incident-response` (which scopes IR on confirmed identity compromise), by `email-security-anti-phishing` (which inherits the phishing-resistant-MFA coverage), and by `compliance-theater` (which compares the deployed authenticator class against any AAL2 / AAL3 compliance claim). P ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-269",
@@ -888,7 +888,7 @@
     "ot-ics-security": {
       "description": "OT / ICS security for mid-2026 — NIST 800-82r3, IEC 62443-3-3, NERC CIP, IT/OT convergence risks, AI-augmented HMI threats, ICS-specific TTPs (ATT&CK for ICS)",
       "threat_context_excerpt": "OT is no longer air-gapped. The \"air gap\" is a label on a Visio file, not a property of the production network. IT/OT convergence is a fait decompli at every Tier-1 operator and most Tier-2/3 manufacturers, utilities, and water authorities:",
-      "produces": "Produce this structure verbatim:\n\n```\n## OT / ICS Security Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Site / Operator:** [name]\n**Process(es) in scope:** [e.g., crude distillation unit; 500kV substation; water treatment Train A]\n**Regulatory jurisdictions:** [US/NERC, EU/NIS2, UK/CAF, AU/SOCI+AESCSF, ...]\n\n### Purdue-Level Asset Inventory\n| Level | Assets (count + class) | OS / Firmware Range | Avg Age (years) | Patch Posture |\n|-------|------------------------|---------------------|-----------------|----------------|\n| L0    | ...                    | ...                 | ...      ...",
+      "produces": "The skill produces an OT / ICS Security Posture Assessment covering Purdue-model zone inventory, IEC 62443 zone-and-conduit posture, NERC CIP / TSA-pipeline coverage, AI-augmented threat exposure (NIST IR 8504 ICS-AI), and the prioritized roadmap for safety-system isolation. The shape below is consumed downstream by `sector-energy` (which inherits the NERC CIP rows), by `incident-response-playbook` (which scopes IR with the Purdue-zone affected-asset list), and by `compliance-theater` (which compares the deployed segmentation against IEC 62443 / NERC CIP claims). Preserve the per-zone safety-s ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-287",
@@ -941,7 +941,7 @@
     "coordinated-vuln-disclosure": {
       "description": "Coordinated Vulnerability Disclosure for mid-2026 — ISO 29147 (disclosure) + ISO 30111 (handling) + VDP + bug bounty + CSAF 2.0 advisories + security.txt + EU CRA / NIS2 regulator-mandated disclosure + AI vulnerability classes",
       "threat_context_excerpt": "CVD is no longer optional, and \"we have a security@ alias\" is no longer a program.",
-      "produces": "The skill produces seven artifacts per program assessment:\n\n### 1. CVD Policy Text (ISO 29147 template)\n\n```\n# Coordinated Vulnerability Disclosure Policy — <Organization>\n\n## Scope\nIn scope: <list of products / services / AI systems>\nOut of scope: <list of assets / behaviors>\nAI-systems statement: <explicit scope for model behavior, prompt-injection classes,\ntraining-data, RAG corpora, agent toolchains — or explicit exclusion>\n\n## Safe Harbor\nWe will not pursue legal action for security research conducted in good faith\nwithin the scope and rules below. Specifically: ...\n\n## How to Report\nCont ...",
+      "produces": "The skill produces seven artifacts per program assessment: an ISO 29147-shaped CVD policy text, a `security.txt` file, an ISO 30111-mapped triage workflow, a CSAF 2.0 advisory template, the safe-harbor language, the bug-bounty scope statement, and the jurisdiction-specific disclosure-clock table (EU CRA / NIS2, US, UK, AU, JP, SG). Each artifact is consumed by a different downstream operator: legal review for safe harbor, vendor PSIRT for CSAF, web ops for `security.txt`, executive risk owner for the disclosure-clock table.\n\n### 1. CVD Policy Text (ISO 29147 template)\n\n```\n# Coordinated Vulner ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1357"
@@ -981,7 +981,7 @@
     "threat-modeling-methodology": {
       "description": "Threat modeling methodologies for mid-2026 — STRIDE, PASTA, LINDDUN (privacy), Cyber Kill Chain, Diamond Model, MITRE Unified Kill Chain, AI-system threat modeling, agent-based threat modeling",
       "threat_context_excerpt": "Most \"threat models\" in circulation in mid-2026 are STRIDE diagrams of 2018–2022 vintage. Their failure modes are concrete and current:",
-      "produces": "```\n## Threat Model — <system name>\n**Date:** YYYY-MM-DD\n**Methodology:** <STRIDE-ML + LINDDUN + Diamond | Unified Kill Chain v3.0 | composite ...>\n**Methodology rationale:** <why this combination, not others>\n**Currency triggers:** <list of upstream changes that will require re-run>\n\n### 1. Scope and Actor Inventory\n| Actor | Type (human/service/AI/data) | Trust boundary | Minimum-scope authorisation | Notes |\n|---|---|---|---|---|\n\n### 2. AI / Agent Inventory (required if any AI actor present)\n| Agent | Runtime | Tool-call surface | Plugins / MCP servers | Decides on its own | Escalates to | ...",
+      "produces": "The skill produces a structured Threat Model per system covering the chosen methodology composite (STRIDE-ML + LINDDUN + Diamond, or Unified Kill Chain v3.0, or a domain-specific composite), the data-flow diagram, identified threats with ATLAS / ATT&CK mapping, mitigations with D3FEND ID, and the currency-trigger list that schedules re-runs. The shape below is consumed downstream by `threat-model-currency` (which scores the model against the 14-class checklist), by `framework-gap-analysis` (which converts each unmitigated threat into a Framework Lag Declaration), and by `policy-exception-gen`  ...",
       "key_xrefs": {
         "cwe_refs": [],
         "d3fend_refs": [],
@@ -1019,7 +1019,7 @@
     "webapp-security": {
       "description": "Web application security for mid-2026 — OWASP Top 10 2025, OWASP ASVS v5, CWE root-cause coverage, AI-generated code weakness drift, server-rendered vs SPA tradeoffs, defense-in-depth across the request lifecycle",
       "threat_context_excerpt": "Webapps still ship CWE-79 (Cross-Site Scripting), CWE-89 (SQL Injection), and CWE-22 (Path Traversal) at rates the industry was supposed to have engineered out of existence by 2018. The reason is not mystery — it is AI codegen drift. Coding assistants (GitHub Copilot, Cursor, Windsurf, Claude Code, Codex, Gemini Code Assist) reintroduce OWASP-Top-10-class weaknesses into new code at roughly the rate human review removed them during the 2010s. Industry analysis published in early 2026 across several large-codebase studies converges on the same order of magnitude: approximately **30% of ...",
-      "produces": "```\n## Web Application Security Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [app/repo names, route count, in-scope environments]\n**ASVS Target Level:** [L1 / L2 / L3, with justification by data sensitivity]\n\n### Per-Route Risk Matrix\n| Route | Auth Required | Data Class | CWE Root-Cause Risks | Current Controls | AI-Codegen Blast Radius | RWEP | Remediation |\n|-------|---------------|------------|----------------------|------------------|-------------------------|------|-------------|\n| POST /api/upload | role:editor | regulated | CWE-434, CWE-22, CWE-78 | content-type allowlist; ma ...",
+      "produces": "The skill produces a Web Application Security Assessment covering OWASP ASVS-mapped per-control coverage, OWASP Top 10 + API Top 10 findings, AI/LLM Top 10 exposure for any LLM-integrated routes, dependency-risk inventory, and the prioritized remediation roadmap. The shape below is consumed downstream by `api-security` (for service-to-service routes), by `ai-attack-surface` (for any LLM-integrated component), and by `compliance-theater` (which compares the ASVS-claimed level against the deployed-control evidence). Preserve the per-control coverage rows verbatim — they are the auditable ASVS-le ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-22",
@@ -1086,7 +1086,7 @@
     "ai-risk-management": {
       "description": "AI governance and risk management for mid-2026 — ISO/IEC 23894 risk process, ISO/IEC 42001 management system, NIST AI RMF, EU AI Act high-risk obligations, AI impact assessments, AI red-team programs, AI incident lifecycle",
       "threat_context_excerpt": "AI governance moved from voluntary to mandatory between 2024 and 2026. The transition has three concrete dates that anchor the current state of the practice:",
-      "produces": "```\n## AI Risk Management Programme — <organisation / scope>\n**Assessment Date:** YYYY-MM-DD\n**Standards in scope:** ISO/IEC 42001:2023 | ISO/IEC 23894:2023 | NIST AI RMF 1.0 | EU AI Act (2024/1689) | <jurisdiction-specific frameworks>\n**EU AI Act enforcement reference date:** 2026-08-02 (high-risk system obligations fully enforceable)\n\n### 1. AI Inventory Ledger\n| ID | Name | Owner | Runtime | Data tier | EU AI Act risk tier | Personal data? | Tool-call surface | MCP servers | Dependencies |\n|---|---|---|---|---|---|---|---|---|---|\n\n### 2. AI Impact Assessment Register\n| Use case ID | EU AI  ...",
+      "produces": "The skill produces a structured AI Risk Management Programme assessment scoring the org against ISO/IEC 42001:2023, ISO/IEC 23894:2023, NIST AI RMF 1.0, EU AI Act (Regulation 2024/1689) high-risk-system obligations, and the jurisdiction-specific AI frameworks tracked in `data/global-frameworks.json`. The shape below is consumed downstream by `compliance-theater` (which compares the AI-RM policy against deployed controls), by `ai-attack-surface` (which inherits the AI-system inventory), and by `global-grc` (for cross-jurisdictional AI rollup). Preserve the per-standard control-coverage rows ver ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1426",
@@ -1134,7 +1134,7 @@
     "sector-healthcare": {
       "description": "Healthcare sector cybersecurity for mid-2026 — HIPAA + HITRUST + HL7 FHIR security, medical device cyber (FDA + EU MDR), AI-in-healthcare under EU AI Act + FDA AI/ML SaMD guidance, patient data flows through LLM clinical tools",
       "threat_context_excerpt": "Healthcare has been the most targeted sector for ransomware for three consecutive years, and that ranking has not changed entering mid-2026:",
-      "produces": "Produce this structure verbatim:\n\n```\n## Healthcare Sector Security Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Entity:** [name] (covered entity / business associate / device vendor / digital-health platform)\n**Scope:** [e.g., EHR + ambient-doc pilots + 3 device families; HMO national; payer + provider arms]\n**Regulatory jurisdictions:** [US HHS-OCR + FDA, EU AI Act + MDR, UK ICO + MHRA, ...]\n\n### HIPAA Technical-Safeguard Scorecard\n| §164.312 Control | Implementation | Adequacy vs current TTPs | Theater Risk |\n|------------------|----------------|--------------------------|--------- ...",
+      "produces": "The skill produces a Healthcare Sector Security Posture Assessment covering HIPAA Security Rule + 2025 NPRM coverage, HITRUST control maturity, NIS2 essential-entity obligations (where applicable), FDA pre/post-market cybersecurity for medical devices, and ambient-AI documentation-pilot risk. The shape below is consumed downstream by `incident-response-playbook` (for HIPAA Breach Notification timing), by `compliance-theater` (HITRUST-vs-deployed-control comparison), and by `global-grc` (for cross-jurisdictional healthcare rollup). Preserve the per-control HIPAA / HITRUST rows verbatim — they a ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-200",
@@ -1191,7 +1191,7 @@
     "sector-financial": {
       "description": "Financial services cybersecurity for mid-2026 — EU DORA TLPT, PSD2 RTS-SCA, SWIFT CSCF v2026, NYDFS 23 NYCRR 500, FFIEC CAT, MAS TRM, APRA CPS 234, IL BoI Directive 361, OSFI B-13; Threat-Led Pen Testing schemes TIBER-EU + CBEST + iCAST",
       "threat_context_excerpt": "Financial services is the most-regulated sector for cybersecurity globally and the regulation cadence is accelerating, not slowing. As of mid-2026 every Tier-1 bank, payments processor, broker-dealer, insurer, and significant financial-market infrastructure operates under multiple binding cyber regimes simultaneously. The threat landscape that drives those regimes has shifted materially since 2023.",
-      "produces": "Produce this structure verbatim:\n\n```\n## Financial Sector Cybersecurity Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Institution / Entity:** [name]\n**Regulatory exposure:** [EU DORA / UK FCA+PRA / US NYDFS / AU APRA / SG MAS / HK HKMA / IL BoI / CA OSFI / JP FISC / BR BCB / ...]\n**Critical or important functions in scope:** [list per DORA Art. 8 / equivalent]\n\n### DORA Register of Information Snapshot (where applicable)\n| ICT Third-Party | Service | Critical/Important Function Supported | Concentration Risk | Exit Strategy | Last Assessment |\n\n### PSD2 RTS-SCA Evidence Pack\n| Payment  ...",
+      "produces": "The skill produces a Financial Sector Cybersecurity Posture Assessment covering EU DORA Art. 6-15 + RTS coverage, UK FCA / PRA SS2/21, US NYDFS 23 NYCRR 500 (Nov 2025 amended), AU APRA CPS 234 + CPG 235, SG MAS TRM, HK HKMA SA-2 / TM-G-1, JP FISC, BR BCB, and the BEC / wire-fraud exposure. The shape below is consumed downstream by `incident-response-playbook` (for the DORA 4h initial-notification clock), by `email-security-anti-phishing` (for BEC exposure), and by `global-grc` (for cross-jurisdictional financial rollup). Preserve the per-regulator obligation rows verbatim — they are the audita ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-287",
@@ -1251,7 +1251,7 @@
     "sector-federal-government": {
       "description": "Federal government + defense contractor cybersecurity for mid-2026 — FedRAMP Rev5, CMMC 2.0, EO 14028, NIST 800-171/172 CUI, FISMA, M-22-09 federal Zero Trust, OMB M-24-04 AI risk, CISA BOD/ED; cross-jurisdiction NCSC UK, ENISA EUCC, AU PSPF, IL government cyber methodology",
       "threat_context_excerpt": "Federal government and defense industrial base (DIB) cybersecurity in mid-2026 is defined by five overlapping transformations driven by Executive Order 14028 (May 2021) and its successor directives:",
-      "produces": "```\n## Federal Government / DIB Cybersecurity Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [federal agency / DIB contractor / federal cloud workload / multi-jurisdiction government]\n**Baselines in scope:** [FedRAMP Rev5 Moderate | FedRAMP Rev5 High | CMMC 2.0 Level 1/2/3 | NIST 800-171 Rev 2/3 | NIST 800-172 | FISMA | M-22-09 | M-24-04 | UK GovAssure | EU NIS2 public admin | AU PSPF/ISM E8 | IL CDM v2.1]\n**Phased rollout exposure (CMMC):** [Phase 1 / 2 / 3 / 4]\n\n### FedRAMP Package Status\n| Attribute | Value | Gap |\n| Authorization type | JAB P-ATO / Agency ATO | |\n| Baseline | Moder ...",
+      "produces": "The skill produces a Federal Government / DIB Cybersecurity Assessment covering FedRAMP Rev5 Moderate / High coverage, CMMC 2.0 Level 1/2/3 maturity, NIST 800-171 Rev 2/3 + 800-172 enhanced security requirements, M-22-09 zero-trust strategy progress, M-24-04 AI obligations, UK GovAssure, EU NIS2 public administration, AU PSPF / ISM Essential 8, and IL CDM v2.1. The shape below is consumed downstream by `incident-response-playbook` (for federal IR notification clocks), by `compliance-theater` (FedRAMP-vs-deployed comparison), and by `global-grc` (for cross-jurisdictional government rollup). Pre ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1357",
@@ -1301,7 +1301,7 @@
     "sector-energy": {
       "description": "Electric power + oil & gas + water/wastewater + renewable-integration cybersecurity for mid-2026 — NERC CIP v6/v7, NIST 800-82r3, TSA Pipeline SD-2021-02C, AWWA cyber, EU NIS2 energy + NCCS-G (cross-border electricity), AU AESCSF + SOCI, ENISA energy sector",
       "threat_context_excerpt": "State-sponsored targeting of energy infrastructure has escalated, not plateaued.",
-      "produces": "Produce this structure verbatim:\n\n```\n## Energy-Sector Cybersecurity Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Operator / Site:** [name]\n**Sub-sector(s):** [electric T&D / generation / market ops / pipeline / water / DER aggregation / EV charging]\n**Regulatory jurisdictions:** [US/NERC + TSA + AWWA + state PUCs; EU/NIS2 + NCCS-G + CER; UK/CAF; AU/SOCI+AESCSF; JP/NISC+METI; IL/INCD; other]\n\n### Asset Class Inventory (Purdue + Energy Overlay)\n| Class | Count | Vendor Mix | Protocol Mix | IEC 62351 Status | Avg Age (years) | Patch Posture |\n|-------|-------|------------|-------------- ...",
+      "produces": "The skill produces an Energy-Sector Cybersecurity Posture Assessment covering NERC CIP v6 / v7 coverage, TSA Pipeline Security Directives, IEC 62443 zone-and-conduit posture, ENISA EECSP, ASD Essential 8 + AESCSF (AU), CER NIS2 transposition (EU), and the AI-augmented OT threat exposure. The shape below is consumed downstream by `ot-ics-security` (which inherits the Purdue-zone analysis), by `incident-response-playbook` (for the FERC / NERC EOP-004 incident-classification clock), and by `global-grc` (for cross-jurisdictional energy rollup). Preserve the per-substation / per-pipeline asset rows ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-287",
@@ -1408,7 +1408,7 @@
     "api-security": {
       "description": "API security for mid-2026 — OWASP API Top 10 2023, AI-API specific (rate limits, prompt-shape egress, MCP HTTP transport), GraphQL + gRPC + REST + WebSocket attack surfaces, API gateway posture, BOLA/BFLA/SSRF/Mass Assignment",
       "threat_context_excerpt": "APIs are now the integration substrate of every non-trivial system. The mid-2026 enterprise app is a thin shell of UI calling a fan-out of REST, GraphQL, gRPC, and WebSocket APIs — many of which themselves call **AI-API services** (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI) on the user's behalf. Legacy web-application firewalls were built for HTML form posts and inspect REST badly, GraphQL barely, gRPC binary framing not at all, and AI-API egress not at all. The defensive perimeter has moved from the WAF to the **API gateway and the egress policy**.",
-      "produces": "```\n## API Security Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [API surfaces in scope — REST / GraphQL / gRPC / WebSocket / MCP — environments]\n**OWASP API Top 10 2023 Target:** [verification level + justification by data sensitivity]\n\n### API Inventory (by Protocol)\n| Protocol | Endpoint / Service | Auth Model | Schema Source | Data Class | AI-API Consumption | Provenance | Inventory Status |\n|----------|--------------------|------------|---------------|------------|--------------------|------------|------------------|\n| REST | GET /api/v1/orders/{id} | OAuth bearer (JWT) | OpenAP ...",
+      "produces": "The skill produces an API Security Assessment covering REST / GraphQL / gRPC / WebSocket / MCP per-surface coverage, OWASP API Top 10 2023 + OWASP API Sec for LLM Top 10 mapping, per-endpoint authentication / authorization / rate-limit / schema-validation evidence, and the prioritized remediation roadmap. The shape below is consumed downstream by `webapp-security` (for browser-facing APIs), by `mcp-agent-trust` (for MCP surfaces), and by `compliance-theater` (which compares the deployed API controls against PCI 4.0 6.2 / OWASP ASVS L2-L3 claims). Preserve the per-endpoint control-evidence rows ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-287",
@@ -1469,7 +1469,7 @@
     "cloud-security": {
       "description": "Cloud security for mid-2026 — CSPM/CWPP/CNAPP posture, CSA CCM v4, AWS/Azure/GCP shared responsibility, cloud workload identity federation, runtime security with eBPF, AI workloads on cloud",
       "threat_context_excerpt": "Cloud is where AI runs. Every consequential AI service — OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, GCP Vertex AI — is a multi-tenant cloud workload. Every enterprise that consumes those services is exposing some portion of its corpus, its prompts, and its access tokens across a shared-tenancy boundary that the consumer does not administer. Every enterprise that hosts its own AI inference (Bedrock with custom models, Azure OpenAI deployments, SageMaker endpoints, Vertex endpoints, GKE/EKS/AKS-hosted vLLM / TGI / Triton) inherits the full posture of the underlying cloud ...",
-      "produces": "Produce this structure verbatim:\n\n```\n## Cloud Security Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Operator:** [name]\n**Clouds in scope:** [AWS, Azure, GCP, OCI, Alibaba, ...]\n**AI-service providers in scope:** [Bedrock, Azure OpenAI, Vertex, OpenAI, Anthropic, ...]\n**Regulatory jurisdictions:** [US/FedRAMP/NYDFS, EU/NIS2/DORA/GDPR, UK/GovAssure, AU/IRAP, JP/ISMAP, SG/MTCS, IN/MeitY, BR/LGPD, CN/MLPS2.0, ...]\n\n### Multi-Cloud Account Inventory\n| CSP | Accounts / Subscriptions / Projects | Regions Active | IaC Coverage | Governance (Org / MG / Folder) |\n\n### CSPM Scorecard (per accou ...",
+      "produces": "The skill produces a Cloud Security Posture Assessment covering per-cloud (AWS / Azure / GCP / OCI / Alibaba) CIS Benchmark coverage, CSA CCM v4 control mapping, IAM least-privilege posture, IMDS / SSRF / metadata-service hardening, KMS / HSM key-management, and the prioritized remediation roadmap. The shape below is consumed downstream by `cloud-iam-incident` (which scopes IR with the IAM-finding list), by `container-runtime-security` (for workload-tier issues), and by `compliance-theater` (which compares the per-cloud control coverage against FedRAMP / IRAP / C5 / ENS / ISMAP claims). Preser ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-287",
@@ -1531,7 +1531,7 @@
     "container-runtime-security": {
       "description": "Container + Kubernetes runtime security for mid-2026 — CIS K8s Benchmark, NSA/CISA Hardening, Pod Security Standards, Kyverno/Gatekeeper admission, Sigstore policy-controller, eBPF runtime detection (Falco/Tetragon), AI inference workload hardening",
       "threat_context_excerpt": "Kubernetes is no longer \"the cloud-native orchestrator.\" It is the AI inference runtime. KServe, vLLM, Triton Inference Server, Ray Serve, Seldon, BentoML, and the Hugging Face TGI / text-generation-inference family all ship as K8s workloads. Anywhere there is a production LLM endpoint in mid-2026 there is a K8s cluster underneath it, and the cluster's hardening posture is the LLM endpoint's hardening posture.",
-      "produces": "Produce this structure verbatim:\n\n```\n## Container + Kubernetes Runtime Security Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Cluster(s) in scope:** [cluster name + K8s version + distribution (EKS / GKE / AKS / OpenShift / Rancher / k0s / Talos / kubeadm) + node OS]\n**Workload classes in scope:** [general microservices / AI inference (KServe / vLLM / Triton / Ray Serve) / data / batch]\n**Regulatory jurisdictions:** [US / EU NIS2+CRA / UK NCSC CAF / AU ISM / IL INCD / SG GovTech / TW CSMA / sector-specific]\n\n### CIS Kubernetes Benchmark Scorecard\n| Section | Total Checks | Pass | Fail  ...",
+      "produces": "The skill produces a Container + Kubernetes Runtime Security Posture Assessment covering per-cluster CIS Kubernetes Benchmark coverage, NSA / CISA Kubernetes Hardening Guide alignment, admission-control (Kyverno / OPA / Gatekeeper) policy maturity, runtime detection (Falco / Tetragon) coverage, sandboxing (gVisor / Kata) deployment, and the prioritized remediation roadmap. The shape below is consumed downstream by `cloud-security` (for the cloud-tier IAM and KMS dependencies), by `supply-chain-integrity` (for image provenance), and by `compliance-theater` (which compares deployed admission-con ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-269",
@@ -1593,7 +1593,7 @@
     "mlops-security": {
       "description": "MLOps pipeline security for mid-2026 — training data integrity, model registry signing, deployment pipeline provenance, inference serving hardening, drift detection, feedback loop integrity; covers MLflow / Kubeflow / Vertex AI / SageMaker / Azure ML / Hugging Face",
       "threat_context_excerpt": "MLOps replaced ad-hoc ML by 2023 — MLflow, Kubeflow Pipelines, Weights & Biases, Vertex AI Pipelines, SageMaker Pipelines, Azure ML Studio, and Hugging Face Hub are now the operational substrate for most production ML. By mid-2026, adversarial pressure has caught up. The MLOps lifecycle (data ingestion → feature store → training pipeline → experiment tracking → model registry → deployment pipeline → inference serving → monitoring → feedback loop) is now a contiguous supply chain whose every handoff is a documented attack class.",
-      "produces": "```\n## MLOps Pipeline Security Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Scope:** [MLOps stack(s): MLflow / Kubeflow / Vertex AI / SageMaker / Azure ML / Hugging Face / DIY]\n**Models in Scope:** [count, classification, deployment surfaces]\n**Frameworks in scope:** [NIST 800-218 SSDF | SLSA v1.0 | ISO/IEC 42001:2023 | NIST AI RMF | OWASP LLM Top 10 | EU AI Act | UK DSIT AI Cyber Code | AU AI Safety Standard | JP Society Principles | IL INCD AI | SG AI Verify | IN MeitY draft | NYDFS Part 500]\n\n### MLOps Stack Inventory\n| Stage | Tooling | Hosted / Self-Managed | Auth Model | Notes |\n|---|-- ...",
+      "produces": "The skill produces an MLOps Pipeline Security Assessment covering training-pipeline integrity, model-registry trust posture, deployment-time signing / attestation, drift-detection coverage, and post-deployment behavioral-regression test cadence across MLflow / Kubeflow / Vertex AI / SageMaker / Azure ML / Hugging Face / DIY stacks. The shape below is consumed downstream by `supply-chain-integrity` (for model-artifact provenance), by `ai-attack-surface` (for the model-serving inventory), and by `compliance-theater` (which compares the deployed model-governance against ISO 42001 / NIST AI RMF cl ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-1426",
@@ -1797,7 +1797,7 @@
     "age-gates-child-safety": {
       "description": "Age-related gates and child online safety for mid-2026 — COPPA + CIPA + California AADC + GDPR Art. 8 + DSA Art. 28 + UK Online Safety Act + UK Children's Code + AU Online Safety Act + IN DPDPA child provisions + KOSA pending; age verification standards (IEEE 2089-2021, OpenID Connect age claims); AI product age policies",
       "threat_context_excerpt": "The age-related regulatory wave that began with the UK Children's Code (in force Sept 2021) and California AADC (signed Sept 2022) crested in 2023-2025 and is in active enforcement entering mid-2026. The compliance surface for any consumer-facing product reachable by users under 18 is now approximately twenty-five overlapping jurisdictional regimes plus emerging AI-specific obligations, with enforcement asymmetry that punishes \"we don't track children\" as ignorance, not exemption.",
-      "produces": "Produce this structure verbatim:\n\n```\n## Age Gates and Child-Safeguarding Posture Assessment\n\n**Assessment Date:** YYYY-MM-DD\n**Entity:** [operator name]\n**Scope:** [products / services in scope; cohorts served; jurisdictions]\n**Regulatory jurisdictions:** [US COPPA + CIPA + AADC + state laws + KOSA-if-enacted; EU GDPR Art. 8 + DSA Art. 28 + AVMSD + CSAM-Regulation-pending; UK OSA + Children's Code; AU OSA + under-16; IN DPDPA; BR LGPD; CN Minors Protection Law + PIPL Art. 31; SG OSA; JP youth protection; KR PIPA; QC Law 25]\n\n### Likely-Accessed-By-Children Inventory (Step 1)\n| Product / Servi ...",
+      "produces": "The skill produces an Age Gates and Child-Safeguarding Posture Assessment covering US COPPA / CIPA, California AADC, UK Children's Code (ICO), Ireland Fundamentals for a Child-Oriented Approach, EU DSA Art. 28 (online platforms), KOSA (US, where enacted), GDPR Art. 8, AU Online Safety Act + eSafety Basic Online Safety Expectations, and emerging KSA / SG / IN child-protection guidance. The shape below is consumed downstream by `dlp-gap-analysis` (for child-data flow detection), by `incident-response-playbook` (for child-data breach notification clocks), and by `global-grc` (for cross-jurisdicti ...",
       "key_xrefs": {
         "cwe_refs": [
           "CWE-200",