The front door for this repo. With no argument: a 30-second intro, then an offer to walk you through your first run on the canary target. With a question: answers it from this repo's own docs and source, cites where it looked, and hands you the next command. Use for "how do I…", "why does…", "where is…", "can this…", or just "/quickstart" to get oriented.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Two modes, picked by whether $ARGUMENTS is empty.
$ARGUMENTS as the operator's question.Keep it short and a little warm; this is the first thing a new operator sees.
Say roughly:
Welcome! This repo takes you from finding your first vulnerability to patching at scale, using a set of Claude Code skills and an autonomous pipeline. Two ways in: interactive skills (no setup, safe, start here) and the autonomous pipeline (Docker, scales to hundreds of parallel agents).
The ramp-up:
| Day 1 | Threat-model + first static scan + triage | | Day 2 | Run the reference pipeline (C/C++) | | Day 3-4 | Customize it for your stack | | Week 2 | Autonomous scanning, triage, and patching |
Day-1 goal: threat-model, scan, and triage the bundled canary target. Most teams get there before lunch.
Remind them to export CLAUDE_CODE_SUBAGENT_MODEL=<model-id> so subagents
use the same model as the session.
Then AskUserQuestion with three options:
README.md Step 1 and stop.Runs the three Step-1 skills on targets/canary, pausing after each to show
what landed on disk. These only read/write files in the repo; no sandbox
needed.
/threat-model bootstrap targets/canary via Task. When done, open
THREAT_MODEL.md, show the focus areas, explain in 2-3 sentences how
this steers the scan./vuln-scan targets/canary via Task. When done, open
targets/canary/VULN-FINDINGS.md, summarize the count and top 2-3
findings, point at VULN-FINDINGS.json./triage targets/canary/VULN-FINDINGS.json via Task. When done, open
TRIAGE.md, explain what changed vs. raw findings (verified, deduped,
re-ranked).Pause for the operator between each (AskUserQuestion); don't barrel through.
Close with a one-line recap of the three artifacts on disk, then point at
README Step 2 for the execution-verified pipeline. Never run vuln-pipeline
or anything that executes target code here; that's Step 2 and needs
Docker + a sandbox.
Answer the operator's question using this repo as ground truth: README,
docs/*.md, harness/*.py, dnr_harness/*.py, targets/*/config.yaml,
.claude/skills/*.
Don't answer from general knowledge when the repo has a specific answer.
| If the question is about… | Read first | Then offer |
|---|---|---|
| running the pipeline | docs/pipeline.md, README Step 2 | the recon / run command |
| too many findings, triage | docs/triage.md | /triage <path> |
| porting, Java/Go/Rust/etc. | docs/customizing.md, README Step 3 | /customize |
| safety, sandbox, Docker | docs/security.md | cite; no action |
| rate limits, 429, token budget | docs/pipeline.md: Rate limits, docs/troubleshooting.md#rate-limits | cite the numbers |
| duplicates, dedup | docs/troubleshooting.md#duplicate-findings | known_bugs: hint |
| CLI flags, "what does --X do" | harness/cli.py (grep the argparse) | exact flag + example |
| which model, subagent pinning | docs/troubleshooting.md: Subagents | the export line |
| best practices, prompting | docs/best-practices.md, docs/prompting.md | cite the principle |
| threat model, attack surface, scope | docs/threat-model.md | /threat-model bootstrap <target-dir> |
| scan, audit, find vulns | .claude/skills/vuln-scan/SKILL.md | /vuln-scan <target-dir> |
| "how do I start" | README Step 1 | offer Guided first run |
| patching, fix, diff, re-attack | docs/patching.md, README Step 4 | /patch <input> |
| threat hunting, incident response, logs | docs/detection-response.md | /dnr-hunt or /dnr-respond |
| autonomous D&R, dnrcanary | docs/detection-response.md, targets/dnrcanary/README.md | the dnr-pipeline run command |
| binary, embedded, other domains | docs/other-use-cases.md | cite section |
| anything else | README Table of contents | best-match doc |
> source: the file(s) and section you used.Grep for it in
harness/cli.py or the target configs and quote what you find.まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Adapt this C/C++ ASAN vulnerability pipeline to a different vulnerability class, target shape, language, or detection mechanism. Use when the user wants to port, migrate, retarget, customize, or fork the pipeline for something other than C/C++ memory-safety bugs — web apps, smart contracts, deserialization, ML systems, or any other domain.
日本語の概要は準備中です。原文の説明を表示しています。
Proactive threat hunt over web/application logs — no alert in hand. Profiles the corpus, runs a hypothesis-driven hunt loop with a mandatory written ledger, confirms suspects in source, detonates a local PoC, and writes INCIDENTS.json + INCIDENT_REPORT.md. Use when asked to "hunt the logs", "find the campaign", "look for signs of compromise", or "run dnr-hunt". The no-alert entry to the detection & response track; /dnr-respond is the lead-in-hand entry.
日本語の概要は準備中です。原文の説明を表示しています。
Incident response workup for a lead in hand — an alert, an IOC, or a /dnr-hunt finding. Scopes the lead across the logs, verdicts whether the attack succeeded, quantifies blast radius, confirms root cause in source with a local PoC, and writes a proposed (never executed) containment/remediation/recovery plan. Use when asked to "respond to this alert", "work this incident", "how bad is this", or "run dnr-respond". /dnr-hunt is the no-alert entry to the same track.
日本語の概要は準備中です。原文の説明を表示しています。
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".
日本語の概要は準備中です。原文の説明を表示しています。
Build a threat model for a target codebase. Three modes: "interview" walks an application owner through the four-question framework and produces a threat model from their answers; "bootstrap" derives a threat model from the code plus past vulnerabilities (CVEs, git history, pentest reports) when no owner is available; "bootstrap-then-interview" chains the two when both owner and codebase are present. All write THREAT_MODEL.md in a shared schema. Use when asked to "threat model", "build a threat model", "map the attack surface", or "what should we be worried about in this codebase".
日本語の概要は準備中です。原文の説明を表示しています。
Triage a batch of raw security findings. Verify each is real, collapse duplicates, re-rank by derived exploitability, and tag with an owner. Takes a directory or file of scanner output and writes TRIAGE.json + TRIAGE.md sorted by what actually needs engineering attention. Use when asked to "triage findings", "validate scanner output", "prioritize vulns", or "review the backlog". Runs interactively by default; pass --auto to skip the interview.
日本語の概要は準備中です。原文の説明を表示しています。