Remediate Vulnerability

Skill name: remediate-vuln

Remediate vulnerability packets from a Snyk explain report. Use when the user asks an agent to evaluate, fix, suppress, exclude, or otherwise resolve one or more dependency or code vulnerability packets generated by the vulnerability CLI, including packets from remediation-packets.md or remediation-packets.json.

Use this skill to process one Snyk explain packet at a time. The goal is to convert a packet into a small, verified remediation or a documented acceptance decision.

Inputs

Accept any of these:

• A pasted dependency packet whose ID starts with D-.
• A pasted code packet whose ID starts with C-.
• A path to build/dependencies/remediation-packets.json or .md plus a packet ID.
• A path to build/code/remediation-packets.json or .md plus a packet ID.
• A packet report path plus an explicit run mode for multiple packets.

If no packet is identifiable, ask for the packet text, packet ID, or packet report path.

Run Modes

Default to reviewed mode unless the user explicitly requests another mode.

reviewed mode:

• Process one packet.
• Update the audit log and rerun verification.
• Stop and report the result for human review before continuing.

batch mode:

• Process the packet queue in priority order without stopping after every packet.
• Update the audit log after every packet.
• Rerun the relevant scan and explain command after every packet unless the user explicitly sets a different cadence.
• Stop immediately on any blocker condition.

Batch mode must be explicit. Accept phrasing such as:

Use $remediate-vuln in batch mode for all code packets until the first blocker.

Use $remediate-vuln in batch mode for the next 10 dependency packets.

Useful optional controls:

• max_packets: maximum packets to process before stopping.
• stop_on_suppression: stop before committing or recording accepted risk.
• stop_on_major_upgrade: stop before dependency major-version upgrades or framework migrations.
• verification_cadence: each_packet by default.

Blocker conditions:

• dirty worktree changes that would mix unrelated user work
• ambiguous exploitability, ownership, runtime reachability, or business risk
• any suppression, accepted risk, false positive, or deferral not already authorized by the user
• dependency major-version upgrade, framework migration, or broad refactor
• failed install, build, lint, test, scan, or explain verification
• packet remains unchanged after a plausible direct fix
• merge conflict or generated lockfile change that cannot be explained
• missing credentials, secrets, private registry access, or Snyk access

Mandatory Preflight

Before editing:

• Identify the target repository and target project directory.
• Run git status --short --branch in the target repository.
• If the worktree is dirty, report the dirty files and avoid mixing unrelated changes. Continue read-only unless the user already authorized edits in that dirty state.
• Inspect the real source of truth. Do not rely only on Snyk output.
• Read the local remediation guide when available: tools/vuln/docs/remediation.md.

Never suppress or exclude a finding before understanding why it cannot be fixed directly.

Packet Routing

• For dependency packets (D-...), read references/dependency.md.
• For code packets (C-...), read references/code.md.

Standard Workflow

• Restate the packet in operational terms:
• vulnerable package or rule
• severity or level
• affected path/file
• source and sink when relevant
• Classify the remediation path.
• Propose the smallest verifiable next step before editing, unless the user has already explicitly asked for implementation.
• Apply only the scoped change needed for that packet.
• Rerun the relevant scan and explain command with the same --target.
• Compare the new packet queue:
• disappeared: resolved
• changed: explain the residual risk and next packet
• unchanged: reassess before adding ignores/exclusions
• Append or update the packet entry in docs/vulnerability-remediation-log.md. Use npm run cli -- audit open --target /path/to/project to create/open it.
• Report exact verification evidence.

Verification Commands

Use the same target directory that generated the packet.

Dependency packet:

npm run cli -- deps build --target /path/to/project
npm run cli -- deps explain --target /path/to/project

Code packet:

npm run cli -- code build --target /path/to/project
npm run cli -- code explain --target /path/to/project

If the CLI is not in the current repo, locate it or ask the user for the vulnerability CLI directory.

Suppression Rules

Use suppression only when at least one is true:

• No compatible fixed version exists.
• A direct fix would require a larger migration the user chooses to defer.
• The finding is a confirmed false positive.
• A mitigation exists but Snyk cannot recognize it.
• The vulnerable path is test/deprecated/generated code and is not shipped or executed in production.

Every suppression must include project-specific rationale, scope, and a follow-up condition. Prefer narrow suppression over broad directory or package suppression.

Final Response

Report:

• what changed, or if no edits were made
• which packet or packets were addressed
• run mode used
• verification commands and outcomes
• audit log entry status
• any remaining packets or manual checks
• dirty worktree caveats