vuln

# Vulnetix Vulnerability Lookup Skill ## Use when - You receive a CVE / GHSA / PYSEC / RUSTSEC / GO / SNYK identifier and need its full enrichment profile (CVSS v3.1 + v4, EPSS, CISA KEV, SSVC decision, x_attackSurface, x_exploitationMaturity, x_remediationTimeline). - A package name (express, lodash, log4j-core) is mentioned and you need every known vulnerability for it filtered to the installed version. - A teammate links a security advisory and you need to assess whether `package-lock.json` is in the affected range. - `.vulnetix/memory.yaml` carries a stale triage entry and you want to refresh enrichment without re-running `/vulnetix:exploits`. - You need the canonical `affected[]` list across all ecosystems (npm + maven + amazon-linux + redhat + ...) for a single CVE. ## Don't use for - Applying fixes — use `/vulnetix:fix`. - Generating Snort / YARA / Nuclei detection content — use `/vulnetix:detection-rules`. - Building a SOC daily queue — use `/vulnetix:soc-triage`. - Searching for exploited vulnerabilities across the wider DB — use `/vulnetix:exploits-search`. ## Conventions This skill follows [`_lib/contract.md`](../_lib/contract.md): the Vulnetix CLI is auto-installed by hooks, `.vulnetix/capabilities.yaml` is always present, every `vulnetix vdb` call is piped through a verified `jq` filter from [`_lib/jq/`](../_lib/jq/), independent calls run in parallel as concurrent Bash tool calls, and trailing follow-ups are limited to one line. See the contract for output...