patchSAFE
Skills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
A Claude Code skill that turns verified security findings into candidate fixes: ranks the queue, routes each finding to the right verification path, and writes every diff as inert text for human review — it never applies a patch to your repo. The last leg of the vulnerability cycle: consumes /triage output (preferred) or any findings file the triage ingest recognizes, and delegates vuln-pipeline results to the execution-verified vuln-pipeline patch ladder. For how it fits the pipeline and how to review what it produces, see docs/patching.md.
Requirements
- Claude Code CLI installed and authenticated
- A findings input:
TRIAGE.json(preferred — already verified and
ranked), VULN-FINDINGS.json (unverified; the skill warns), INCIDENTS.json (untriaged D&R output; the skill warns), or a vuln-pipeline results/// directory
- A read-only checkout of the target codebase (
--repo, default cwd) —
required for static mode
- For pipeline input only: the vuln-pipeline installed and sandboxed, since
the skill shells out to vuln-pipeline patch. The target's config.yaml needs a build_command (the in-container rebuild step after applying a diff) and optionally a test_command (the regression suite for the regress tier). All four shipped C/C++ targets have build_command; only canary sets test_command — on the others the regress tier is skipped.
Usage
/patch results///TRIAGE.json --repo ./my-service # canonical: triaged findings /patch results///TRIAGE.json --repo ./my-service --top 5 # only the 5 highest-severity /patch results/// --model # pipeline results → verification ladder /patch findings.json --repo ./src --id f003 # one finding by id /patch results///TRIAGE.json --repo ./src --fresh # ignore checkpoint, start over
How the input routes: a pipeli
c7f8d948fb02OBSERVED · 2026-10-21Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| claude-code | mentioned |
What it tells the agent
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: patch
description: Generate candidate fixes for verified security findings. Consumes
TRIAGE.json (preferred), VULN-FINDINGS.json, INCIDENTS.json, or a vuln-pipeline results
directory. Pipeline input is delegated to the execution-verified
`vuln-pipeline patch` ladder; static-analysis input gets a per-finding
patch subagent + independent reviewer and is written as inert diffs for
human review. Writes PATCHES/bug_NN/{patch.diff,patch_result.json},
PATCHES.md, and PATCHES.json. Use when asked to "fix the findings",
"patch these vulns", "generate fixes", or "close the loop on triage".
argument-hint: "<findings-path> [--repo PATH] [--top N] [--id fNNN] [--model M] [--fresh]"
allowed-tools:
- Read
- Glob
- Grep
- Write
- Task
- Bash(python3 .claude/skills/_lib/checkpoint.py:*)
- Bash(vuln-pipeline patch:*)
- Bash(rg:*)
- Bash(grep:*)
- Bash(ls:*)
- Bash(wc:*)
- Bash(head:*)
- Bash(file:*)
- Bash(jq:*)
---
# patch
Third leg of the static pipeline (`/vuln-scan` → `/triage` → `/patch`).
Turns a ranked list of verified findings into candidate diffs.
The skill **never applies a diff** to the target repo. Output is inert text
in `./PATCHES/` for a human to review and apply out-of-band — see
`docs/patching.md#reviewing-generated-patches`. There is no `--apply` or
`--approve` flag by design: the capability isn't present, so it can't be
prompt-injected into use.
Invoke with `/patch <findings-path> [--repo PATH] [--top N] [--id fNNN]
[--model M] [--fresh]`.
**Arguments** (parse from `$ARGUMENTS`):
- findings path (first positional, required): `TRIAGE.json`,
`VULN-FINDINGS.json`, a pipeline `results/<target>/<ts>/` directory, or any
JSON the `/triage` ingest table recognizes.
- `--repo PATH`: target codebase, read-only (default cwd). Required for
static mode; the skill stops if cited files don't resolve under it.
- `--top N`: patch only the N highest-severity true positives (static mode).
- `--id fNNN`: patch only the finding with this id.
- `--model M`: passed through to `vuln-pipeline patch` in execution-verified
mode. Ignored in static mode (subagents inherit the orchestrator's model).
- `--fresh`: ignore `./.patch-state/` checkpoint and start over.
**Tools.** Prefer Read, Glob, Grep, Write, Task. Some sessions do not
provision Glob or Grep; `allowed-tools` is a permission filter, not a loader.
When they are unavailable, fall back to the read-only Bash commands
whitelisted above: `rg`/`grep` for search, `ls` for enumeration,
`head`/`file`/`wc` for sniffing, `jq` for JSON ingest. Bash is otherwise
permitted only for `python3 .claude/skills/_lib/checkpoint.py` (state I/O)
and `vuln-pipeline patch` (execution-verified delegate). `find` is NOT
permitted.
**Write scope.** The Write tool may target ONLY paths under `./PATCHES/` and
`./.patch-state/`. Never write into `--repo`, never `git apply`, never
`patch`, never edit target source. If a step seems to require it, the step is
wrong.
---
## Checkpointing (runs before Phase 0 and after every phase)
State persists to `./.patch-state/` so a fresh `/patch` session resumes
without re-spawning patch or reviewer subagents. All checkpoint I/O goes
through `python3 .claude/skills/_lib/checkpoint.py` (atomic, JSON-validated).
The Write→`--from` pattern keeps repo-derived bytes out of Bash argv; never
pass payload via heredoc or stdin.
State files: `progress.json` (single source of truth: `{"status":
"running"|"complete", "phase_done": N, "shards_done": [...]}`),
`phaseN.json`, `_chunk.tmp`.
**Start of run.** Bash:
`python3 .claude/skills/_lib/checkpoint.py load ./.patch-state`
- `status == "absent"` OR `"complete"`, OR `--fresh` in `$ARGUMENTS` →
fresh start. Bash:
`python3 .claude/skills/_lib/checkpoint.py reset ./.patch-state`,
proceed to Phase 0.
- `status == "running"` with `phase_done == N` → resume. Read
`phase0.json`..`phaseN.json` in order (and any `shard_*.json` listed in
`shards_done`), merge into working state, print
`Resuming from checkpoint: Phase N complete`, skip to Phase N+1. Do not
re-spawn any subagent whose output is already checkpointed.
**End of every phase N.** Write tool → `./.patch-state/_chunk.tmp` with the
phase's JSON, then Bash:
`python3 .claude/skills/_lib/checkpoint.py save ./.patch-state <N> <name> --from ./.patch-state/_chunk.tmp`
**End of run.** After writing `PATCHES.md` and `PATCHES.json`, Bash:
`python3 .claude/skills/_lib/checkpoint.py done ./.patch-state 4`
---
## Phase 0: Parse arguments and detect mode
### 0a. Parse `$ARGUMENTS`
Extract findings path (first positional), `--repo` (default `.`), `--top`,
`--id`, `--model`, `--fresh`. If no findings path, stop and ask.
### 0b. Detect mode
Inspect the findings path:
- **execution-verified mode** when the path is a directory containing
`reports/manifest.jsonl` OR `found_bugs.jsonl` OR `run_*/result.json`
(pipeline output) — unless an `INCIDENTS.json` is present anywhere in it:
D&R run dirs also contain `run_*/result.json`, and their incidents route
static. The findings have PoC bytes + ASAN traces + reproduction
commands; the pipeline's verification ladder applies.
- **static mode** otherwise: `TRIAGE.json`, `VULN-FINDINGS.json`,
`INCIDENTS.json` (the `/dnr-*` output), generic finding JSON, or markdown.
No PoC; the oracle is a fresh-context reviewer.
Record `mode` in working state. The two modes share Phase 1 ingest then fork
at Phase 2.
**Checkpoint:** Write tool → `./.patch-state/_chunk.tmp`:
`{"phase": 0, "mode": "exec"|"static", "args": {repo, top, id, model, findings_path}}`
Then Bash:
`python3 .claude/skills/_lib/checkpoint.py save ./.patch-state 0 mode --from ./.patch-state/_chunk.tmp`
---
## Phase 1: Ingest and normalize
Same input contract as `/triage` Phase 1. Normalize every input format to a
flat `findings[]` of dicts. Pull what's present; never guess what's absent.
### 1a. Recognized containers (priority order)
1. **`TRIAGE.json`** — read `.findings[]`. *Trust audit
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.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
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.
c7f8d948fb02full audit observations/trust-audit/skill/anthropics__patch.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-21 | c7f8d948fb02 | SAFE | B | 89 | first audit |
Questions
What does the patch — anthropics/defending-code-reference-harness skill do?
Skills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can /customize
Is patch — anthropics/defending-code-reference-harness safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can patch — anthropics/defending-code-reference-harness access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does patch — anthropics/defending-code-reference-harness work with?
Its documentation mentions claude-code. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (c7f8d948fb02), read on 2026-10-21. The repository is watched, and a new audit runs when it changes — this is the first audit.
Add this badge to your README
Shows this page's audit result and links back to it. It updates when the audit does.
[](https://modelsatlas.com/skills/anthropics/patch/)
Not your listing, or something out of date? Claim or update your listing.