RemediationSAFE

A single hub to find Claude Skills, Agents, Commands, Hooks, Plugins, and Marketplace collections to extend Claude Code, Claude Desktop, Agent SDK and OpenClaw

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: remediation
description: Get a context-aware remediation plan for a vulnerability with fix verification steps
argument-hint: <vuln-id>
user-invocable: true
allowed-tools: Bash, Read, Glob, Grep, Edit, Write
model: sonnet
---

# Vulnetix Remediation Plan Skill

This skill generates a comprehensive, context-aware remediation plan for a specific vulnerability using the VDB V2 remediation API. It auto-detects your repository's ecosystem, package manager, installed versions, container images, and OS to provide targeted fix guidance including registry upgrades, source patches, distribution advisories, workarounds, CWE-specific remediation strategies, and verification commands.

**How this differs from `/vulnetix:fix`:** The existing `/vulnetix:fix` skill fetches V1 fix data and proposes manual manifest edits. This skill uses the V2 `remediation plan` endpoint which provides **context-aware** guidance (ecosystem, version, OS, container), **CWE remediation strategies**, **CrowdSec threat intelligence** (live exploitation data), **workaround effectiveness scoring**, **SSVC decision support**, and **verification commands** per package manager.

## Vulnerability Memory (.vulnetix/memory.yaml)

This skill reads and updates the `.vulnetix/memory.yaml` file in the repository root. This file is shared with `/vulnetix:fix`, `/vulnetix:exploits`, `/vulnetix:package-search`, `/vulnetix:vuln`, and `/vulnetix:exploits-search`.

### Schema

The canonical schema is defined in `/vulnetix:fix`. This skill updates base fields and appends remediation plan events to the history log.

### Reading Prior State

**At the start of every invocation:**

1. Use **Glob** to check if `.vulnetix/memory.yaml` exists in the repo root
2. If it exists, use **Read** to load it and check for the vuln ID or aliases
3. Use **Glob** for `.vulnetix/scans/*.cdx.json` -- cross-reference for component data
4. If a prior entry exists, display:
   ```
   Previously seen: <vulnId> -- <developer-friendly status> (as of <date>)
   Priority: <P1/P2/P3/P4> (<score>) (if cwss data exists)
   Last decision: <developer-friendly decision> -- "<reason>"
   ```

### Writing Updated State

**After completing the remediation plan (Step 7):**

1. If no entry exists, create one with `status: under_investigation`, `discovery.source: user`
2. If an entry exists, update `severity`, `safe_harbour`, and `versions.fixed_in` from the remediation plan data. Merge aliases.
3. **Do NOT change `status` or `decision`** unless the user explicitly makes a decision during the conversation
4. Append to `history`: `event: remediation-plan`, detail: summary of fix options found (registry fixes, source fixes, workarounds, distribution patches)
5. Confirm to the user

### VEX Status Mapping

- `not_affected` --> "Not affected"
- `affected` --> "Vulnerable"
- `fixed` --> "Fixed"
- `under_investigation` --> "Investigating"

## Dependabot Integration

When `gh` CLI is available (check with `gh auth status 2>/dev/null`), query Dependabot alerts for the vuln ID to cross-reference with the remediation plan.

1. Query alerts matching this vuln ID
2. If a Dependabot PR exists, note it in the output: `"Dependabot PR #N proposes this upgrade -- consider reviewing and merging it"`
3. Update the `dependabot` section in the memory entry

## Workflow

### Step 1: Load Memory and Detect Repository Context

1. Load `.vulnetix/memory.yaml` as described above
2. Use **Glob** to detect manifest files and determine:
   - **Ecosystem** -- npm, pypi, maven, go, cargo, rubygems, packagist
   - **Package manager** -- npm, yarn, pnpm, pip, poetry, uv, cargo, go, maven, gradle, bundler, composer
3. If the vuln ID is already in memory with a `package` field, use that package name
4. If not, run a quick lookup to get affected products:
   ```bash
   vulnetix vdb vuln "$ARGUMENTS" -o json
   ```
   Extract affected package names and ecosystems from the response.
5. For each affected package found in the repo, detect the installed version using the priority chain: lockfile --> manifest --> installed artifacts --> unknown

### Step 2: Auto-Populate Context Flags

Build the CLI flags automatically from repository state:

| Flag | Source | How to detect |
|------|--------|---------------|
| `--ecosystem` | Manifest files | From Step 1 ecosystem detection |
| `--package-name` | VDB response or memory | Affected package name matching repo |
| `--current-version` | Lockfile/manifest | Installed version from Step 1 |
| `--package-manager` | Manifest file type | `package-lock.json` --> npm, `yarn.lock` --> yarn, `poetry.lock` --> pip/poetry, etc. |
| `--purl` | Constructed | If ecosystem + name + version are known, construct `pkg:<eco>/<name>@<version>` |
| `--container-image` | Containerfile/Dockerfile | Use **Glob** for `Containerfile`, `Dockerfile`, `*.dockerfile`. If found, **Read** and extract `FROM` image reference (e.g., `node:18-alpine`) |
| `--os` | OS detection | Check for `/etc/os-release` or infer from container base image |
| `--vendor` | VDB response | From affected products vendor field |
| `--product` | VDB response | From affected products product field |

Always set:
- `--include-guidance` -- includes CWE-specific remediation strategies
- `--include-verification-steps` -- includes per-package-manager verification commands

If no package context can be determined (no manifests, no memory), run the command without package-specific flags -- the API will still return general remediation guidance.

### Step 3: Execute Remediation Plan Query

```bash
vulnetix vdb remediation plan "$ARGUMENTS" -V v2 --include-guidance --include-verification-steps -o json [context flags]
```

**CLI Reference** (from `vulnetix vdb remediation plan` docs):

| Flag | Type | Description |
|------|------|-------------|
| `--ecosystem` | string | Package ecosystem (npm, pypi, maven, go, cargo, etc.) |
| `--package-name` | string | Package name |
| `--current-version` | string | Currently installed version (enables

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.