/should-i-care

name: should-i-care
description: Single-CVE applicability triage that evaluates whether a CVE actually applies to the user's environment by reasoning about discriminating conditions against a skill-maintained environment profile; triggers when a user asks whether they are affected by a CVE, whether a CVE applies to them, or wants to assess a CVE against their environment.
license: MIT

should-i-care

Single-CVE applicability triage. The user asks "am I affected by CVE-X?" and the skill returns a reasoned verdict evaluated against the user's environment profile.

The value is NOT product matching. Scanners do that via CPE. The value is **condition evaluation**: does the vulnerability actually apply given the specific conditions in the user's environment: deployment model (OWA vs. Exchange Online), protocol state (RC4 still allowed), memory protections (ASLR disabled), a feature toggled on or off. This is the step a CPE match cannot perform. It is the manual step a human does after a scanner flags a hit.

Core principle

Anchor on the canonical CVE record for **identity** (what the CVE is). Evaluate **conditions** (under what circumstances it applies) against the user's environment profile. Return one of three verdicts with a full, source-backed reasoning chain.

The reasoning chain is the product. It is the user's basis for cross-checking. I can be wrong about condition research. The output must always expose its logic so the user can verify.

Output language

Answer in the user's language. The structural examples in this skill are written in English to fix the shape of the output; the answer itself follows whatever language the user is writing in.

The environment file

The skill reads and maintains a single environment file at a fixed path: `~/.config/should-i-care/environment.md`. The skill does not look in the working directory and does not look in the skill directory. If the file is absent, see **First-run** below.

This file is skill-maintained state, not a document the user keeps beside a project. It has to be found again on every run regardless of which directory Claude Code was launched from, and it has to survive skill updates. Writing it into the working directory is non-deterministic: launch Claude Code somewhere else and the profile is not found, so the skill starts over from an empty inventory. Writing it into the skill directory is unsafe, since a skill update or a re-clone can overwrite it. A fixed user-level path avoids both, so the location is always `~/.config/should-i-care/environment.md`.

The file has two layers.

Layer 1: Inventory

What is in the environment: product, version/build, deployment model. This is the cheap first gate. If the product is not present (including any product that implies the CVE's target component, see **Component derivation** below) the assessment ends as not affected (subject to the absence-of-evidence rule).

**Exposure** is an optional Layer 1 attribute. Values: `internet-facing`, `internal`, `unsure`. It is meaningful ONLY for entries that accept inbound connections: server services (web server, mail server, directory service, database) and network/appliance gear (VPN gateway, firewall, management interfaces). Do NOT ask for it or attach it to client devices, client operating systems, laptops, or mobile devices; those do not listen for inbound connections, so exposure says nothing about them. Apply the same discipline used for Layer 2 conditions: only ask when it moves the verdict or the urgency. Concretely, exposure is relevant only when BOTH of these hold: the affected entry is a service that accepts inbound connections, AND the CVE has a network-reachable vector. For a local-only vector (local privilege escalation, requires local access), exposure is irrelevant and must not be asked. When exposure is relevant but missing for the affected service, ask one closed question (internet-facing or internal?), then write it back to that inventory entry as a Layer 1 attribute with source and date via the normal write-back-with-confirmation path. Exposure sharpens urgency; it never by itself decides applicability (see **Urgency tag**).

Layer 2: Condition store

Discriminating settings: "OWA in use?", "RC4 allowed?", "ASLR disabled?", auth mode. Grows organically, one CVE at a time. Each condition carries:

• `value`
• `last_verified` (date)
• `source` (e.g. user-confirmed)
• volatility tag: `stable` or `volatile`
• optional `notes` (one short qualifier)

The written form in the file is a single Markdown table, one row per condition, with columns `Condition | value | last_verified | source | volatility | notes`. Write Layer 2 to environment.md as this table, not as nested bullet blocks, so the file stays scannable as conditions accumulate. The fields above are what each row holds; the table is how they are stored.

Do not confuse this storage table with the `Condition | your state | Sources` table in Layout A: that one presents a verdict in chat, this one stores conditions in the file. They are different tables for different purposes.

Format is plain Markdown. No CPE in the template. CPE may appear as an optional power-user field for one product if the user wants it; it is never required.

The user must never be required to hand-edit the file. Every change happens via **write-back with confirmation** (see below): the user confirms in chat, then I write the file directly on the local filesystem. The template exists so a curious user can read what happened; the path to every change is the chat. Because the skill runs on an agent with a local filesystem, the write-back is automatic and persists across sessions.

Assessment log (optional)

An optional `## Assessment log` section records verdicts chronologically, one entry per assessment: date, CVE ID, the verdict, and a one-line basis (why it was cleared or flagged). It is written via the same write-back-with-confirmation path. It is the user's audit trail and the "why w