Update to NPMScan

{
  "description": "Turn a flagged npm supply-chain finding — or just a vague, non-technical description of one (\"this package looks sketchy,\" \"someone said we got hacked,\" \"npm install did something weird\") — into concrete remediation steps. Use whenever the user wants to know what to actually do about a suspicious/compromised/flagged package, however precisely or vaguely they describe it — not for the initial trust/vulnerability investigation itself (see package-trust-check/dependency-audit for that).",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 293
    },
    {
      "relative_path": "references/test-prompts.md",
      "size_in_bytes": 10772
    }
  ],
  "name": "incident-response",
  "skill_md_contents": "---\nname: incident-response\ndescription: Turn a flagged npm supply-chain finding — or just a vague, non-technical description of one (\"this package looks sketchy,\" \"someone said we got hacked,\" \"npm install did something weird\") — into concrete remediation steps. Use whenever the user wants to know what to actually do about a suspicious/compromised/flagged package, however precisely or vaguely they describe it — not for the initial trust/vulnerability investigation itself (see package-trust-check/dependency-audit for that).\n---\n\n# Incident response\n\nUse this skill once the user wants to know what to actually *do* about a\nsupply-chain concern, not just what was found — whether that concern is a\nprecise tool finding already in this conversation, or just a worried,\nnon-technical description of a symptom. Most users will not know terms like\n\"lifecycle script\" or a `rule` id, and will not think to run an npmscan tool\nthemselves first — reformulating a vague description into the right call is\nthis skill's job, not something to push back on the user for. This is the\nlast step, not a replacement for `package-trust-check` (single-package trust\nquestions) or `dependency-audit` (multi-package audits): those skills\ninvestigate and report; this one turns a concern — precise or vague — into\nan actionable plan.\n\n## Reading a vague or non-technical request\n\nDo not require the user to already know a `rule` id, a playbook name, or\nnpmscan's own vocabulary. Translate what they actually said using their\nintent, not their exact words. Common shapes and what they map to:\n\n| What the user says (any rough equivalent) | What to do |\n|---|---|\n| Names a specific package and says it's \"sketchy,\" \"hacked,\" \"compromised,\" or just \"is this safe\" | Run `package-trust-check`'s investigation first (get_package, check_maintainer_changes, check_package_provenance, analyze_install_script as applicable) — you need real findings before a remediation plan means anything. Once findings exist, continue to step 2 below. |\n| Names a package AND describes a specific symptom (\"it downloads something during install,\" \"the maintainer changed\") | Run the one finding tool that actually checks that symptom (analyze_install_script for install-time behavior, check_maintainer_changes for ownership, check_package_provenance for publish/build mismatches) rather than the full trust-check sweep — faster, and still grounds the answer in a real finding. |\n| Describes a symptom with NO package name — \"what do we do about a postinstall that downloads a binary,\" \"how do we respond to a typosquat,\" \"what's the process for a maintainer takeover\" | No finding tool has anything to check. Go straight to `get_remediation_playbook({ id: \"...\" })` with your best-guess playbook id from the table below. A wrong guess is harmless — it comes back `matched: false` — so guess confidently rather than asking the user to be more specific first. |\n| Totally generic, no package, no symptom — \"we got a security alert, what do I do,\" \"help, is this bad\" | The one case worth a single clarifying question: ask what specifically happened or which package/alert, since there is nothing yet to ground a plan in. Don't guess a playbook id from nothing. |\n\nSymptom → playbook `id` guesses for the no-package-name case:\n\n- downloads/runs a binary, executable, or installer during install → `postinstall-binary`\n- name looks like / is close to a well-known package, \"typosquat,\" \"fake version of X\" → `suspected-typosquat`\n- general \"hacked,\" \"compromised,\" \"malicious code,\" \"supply chain attack\" with no more specific detail → `supply-chain-compromise`\n- runs shell commands, `exec`, spawns a process during install → `child-process-in-install`\n- \"calls out,\" \"connects to a server,\" \"phones home\" during install → `unexpected-network-install`\n- \"new maintainer,\" \"ownership changed,\" \"ownership transfer,\" \"ex-employee's account\" → `maintainer-change-flagged`\n- \"provenance,\" \"build doesn't match the repo,\" \"install script wasn't in the source,\" \"someone bypassed CI\" → `provenance-mismatch`\n\n## Steps\n\n1. Read the request per the table above. If a finding already exists in\n   this conversation (a prior `analyze_install_script`,\n   `check_maintainer_changes`, or `check_package_provenance` result), skip\n   straight to step 2 with its `findings[].rule` value(s).\n2. Call `get_remediation_playbook({ rules: [...] })` with every distinct\n   `rule` value from the finding(s) in one call — it batches and deduplicates,\n   so don't call it once per rule. Use `id` instead for a symptom-only\n   request with no live finding (see the table above).\n3. If the underlying finding's `riskTier` came back `none` (or the findings\n   array was empty), say plainly that no remediation is needed rather than\n   still calling this tool to manufacture a plan — an incident-response\n   playbook implies there's something to respond to.\n4. For each `matched: true` result, present that playbook's `title`,\n   `severity`, and `steps` directly in your answer — the step `text` plus\n   its `why`, in order — not a paraphrase and not just a link. Lead with the\n   match's own `situationNote` when one exists (what this specific rule\n   actually found) before the steps, so the response is grounded in the real\n   finding rather than reading as generic boilerplate — this matters most\n   when a batch has several different rules landing on the same playbook\n   (see step 6). If you got here from an `id` guess rather than a real\n   finding (no `situationNote`), say so plainly (\"this sounds like it might\n   be X — here's that playbook; tell me more if it's actually something\n   else\") rather than presenting a guess as a confirmed diagnosis. Close\n   with the playbook's `preventionTips` when the user's question has any\n   forward-looking angle (\"how do we stop this happening again,\" a policy/CI\n   question, or just naturally as part of a full incident report), and cite\n   its `references` (each labeled `incident` or `reading`) so the user can\n   verify the real-world grounding themselves — don't call an `incident`\n   reference a \"reading\" or vice versa, that distinction is deliberate.\n   Include the `npmscanUrl` too so the user can also read it on the docs\n   site.\n5. For any `matched: false` result, say so plainly using the tool's own\n   `note` (e.g. \"this finding is baseline/informational, not something with\n   its own response plan\") — don't silently drop it or invent generic advice\n   in its place. If your own `id` guess came back unmatched, try the\n   next-closest guess from the table, or ask the one clarifying question\n   from the \"totally generic\" row rather than giving up.\n6. When a findings array maps to more than one distinct playbook (e.g. a\n   `check_maintainer_changes` result with both a turnover finding and a\n   repository-transfer finding pointing at the same playbook, or a mixed\n   maintainer + provenance investigation pointing at two different ones),\n   present each matched playbook once, not once per originating finding.\n\n## Do not\n\n- Do not write your own remediation steps once a finding tool has run —\n  call `get_remediation_playbook` and use its actual `steps`/`why` text,\n  don't paraphrase or improvise around it.\n- Do not refuse to help, or ask the user to look up a `rule`/playbook id\n  themselves, just because their request was vague — that is exactly the\n  case the table above exists for. Only ask a clarifying question in the\n  genuinely-nothing-to-go-on case.\n- Do not treat `matched: false` as \"this is safe\" — it means no dedicated\n  playbook exists for that specific rule, which is a different statement\n  than \"no risk here.\" Say what the tool's `note` actually says.\n- Do not skip a finding tool and go straight to an `id` guess when the user\n  named a specific package — a guess is only for the no-package-name,\n  symptom-only case. When a package is named, ground the answer in a real\n  finding first.\n- Do not present an `id`-guessed playbook as if it were a confirmed\n  diagnosis — say plainly that it's your best read of their description.\n- Do not call `get_remediation_playbook` once per rule when a findings array\n  has several — batch all the rule values into one call's `rules` array.\n- Do not force a playbook onto a clean/`none`-risk-tier result just because\n  the user asked \"what should I do\" — say no action is needed.\n- Do not embellish a playbook's `references` beyond what's returned — cite\n  only the `label`/`url` the tool gave you, and preserve whether the tool\n  marked it `incident` (a real, verified compromise) or `reading`\n  (background material, not itself a breach) rather than upgrading a\n  `reading` reference into a claimed incident.\n\n## Tools used\n\n`get_remediation_playbook`, plus whichever of `analyze_install_script`,\n`check_maintainer_changes`, `check_package_provenance` is needed to produce\nthe finding this skill responds to — see `agents/openai.yaml` for the MCP\nserver dependency, and `references/test-prompts.md` for the test cases to\nrun in ChatGPT Developer Mode before submitting.\n"
}