Audit machines for CVE exposure without changing state

Runs a read-only local security-exposure audit answering whether the user's machine or projects are affected by a specific CVE, breach, or package advisory, then writes a dated Markdown report to a fixed audits folder as the permanent record of the check, even when the verdict is "not affected."

Use it when the user asks whether their machine or projects are affected by a CVE, breach, or package advisory, or when a read-only local security exposure report is the appropriate response. It is strictly read-only: no installs, removes, upgrades, restarts, network calls, or file modifications outside the audit-reports folder, and sudo is never used. If a check would require a state-changing command, it is skipped and marked "not checked (would require state change)" in the results table rather than run. The rule against breaking read-only never bends on its own: if the verdict comes back "Affected," the remediation command goes in the report's Follow-ups section and the audit stops there - the user runs it themselves.

The report itself follows a fixed template: a title and date header naming the host, the CVE or advisory in scope with a one-line description and affected versions, an audit-results table, a verdict section, an "action taken" line that always states nothing was installed, removed, or changed since the audit is diagnostic only, and a follow-ups section. Verdict wording is precise and consistent: "Not affected" means the package or binary is absent, patched, or not running and not exposed; "Affected" means a vulnerable version is present and reachable by the attack vector; and "Partially affected" means the package is present but mitigated, for instance installed but not running or a listener bound only to loopback, with the mitigation spelled out in the report's bullets. Tone matches the two existing reference reports already sitting in the audits folder: terse, factual, bulleted, with no hedging language anywhere. One of those references, a long-form baseline audit, uses a deliberately different layout and should not be copied; the other, a dated example-advisory report (plus any newer dated advisory reports alongside it), is the actual format this skill's own output should match line for line. The date stamped into both the filename and the report body always comes from the current environment's own date, never guessed or left blank.

Anyone who needs a fast, honest, read-only answer to "am I affected by this?" for a specific CVE or advisory, backed by a permanent, dated audit-trail report rather than a verbal yes-or-no with nothing to show for it later.