dnr-respond

Lead-in-hand incident response: take one concrete starting point and answer the four questions an incident commander needs, in order — what happened, did it succeed, how far did it go, and what do we do about it. The output is a verdict, a quantified blast radius, a root cause proven in source, and a response plan that is proposed, never executed.

Invoke with

/dnr-respond <lead> [--logs dir] [--repo path] [--fresh]

The lead (
$1
) can be:

an incident id from the hunt's
```
INCIDENTS.json
```
(e.g.
```
INC-2
```
) — the
```
/dnr-hunt
```
handoff
an alert pasted from an alert queue (JSON line or prose)
an IOC: an IP, an account name, a route, a session identifier
free text ("a customer says their address was quoted in a phishing email")

Other arguments:

```
--logs
```
= logs directory or dnr target directory (same resolution as
```
/dnr-hunt
```
; defaults to
```
targets/dnrcanary
```
if it exists, else cwd).
```
--repo
```
= application source (defaults to the target's
```
app/
```
).
```
--fresh
```
= ignore any checkpoint in the run dir's
```
.dnr-respond-state/
```
and mint a new run dir.

Hard rules (shared with /dnr-hunt — the track's contract)

Log evidence alone never confirms a vulnerability.
```
confirmed_exploited
```
requires log evidence + the flaw in source + a PoC fired locally this session. Otherwise the ceiling is
```
suspected
```
.
Query, don't read. Never
```
Read
```
or
```
cat
```
a log file;
```
wc
```
/
```
head
```
/
```
tail
```
to profile,
```
grep
```
/
```
awk
```
/
```
sort
```
/
```
uniq
```
/
```
python3
```
to interrogate. Small files (alert queues, error logs under ~200 lines) may be read whole.
Propose, never execute. No blocking, disabling, rotating, or config changes — in any environment, including the demo app. The plan names actions; humans execute them.
Local only. PoCs fire at
```
127.0.0.1
```
against an instance you started. Never touch a remote host.
Every number is a query result. "How many records" and "how many customers" get answered by pipelines run this session, never estimated.

Run directory and checkpointing

First action — establish the run directory, the same way

/dnr-hunt

does, but as a consumer. Let

TARGET

be the basename of the resolved

--logs

/target path (default

targets/dnrcanary

) and

SCOPE

that path.

Lead is
INC-n
(the
```
/dnr-hunt
```
handoff, or a second lead from a hunt you already started responding to): work the response into the investigation that incident lives in.
```
{RUN}
```
is the newest
```
results/TARGET/<timestamp>/
```
directory that contains an
```
INCIDENTS.json
```
— find it with Bash, e.g.
```
ls -1d results/TARGET/*/ | sort -r | while read d; do [ -f "$d/INCIDENTS.json" ] && echo "$d" && break; done
```
. Do not call
```
rundir
```
for an
```
INC-n
```
lead —
```
rundir
```
mints a fresh empty dir once a prior
```
/dnr-respond
```
in that dir has completed, which would strand the incident's
```
INCIDENTS.json
```
in the old dir. Only if no run dir holds an
```
INCIDENTS.json
```
(you were handed
```
INC-n
```
but never ran the hunt) fall through to the
```
rundir
```
line below.

Any other lead (alert, IOC, free text): Bash

python3 .claude/skills/_lib/checkpoint.py rundir results/TARGET --state .dnr-respond-state --scope "SCOPE"

(append

--fresh

if it's in

$ARGUMENTS

). This adopts the newest run dir for the target if one exists, else mints a fresh

results/TARGET/<timestamp>/

That path is

{RUN}

; substitute the literal path everywhere below, and double-quote it (and

SCOPE

) in Bash.

Checkpoint mechanics are identical to

/dnr-hunt

, state dir

{RUN}/.dnr-respond-state/

, phases 0–4. When

{RUN}

already holds a completed

.dnr-respond-state

from an earlier lead,

load

reports

complete

and the rules below reset it cleanly — a second lead enriches the same

INCIDENTS.json

and writes its own

RESPONSE-<lead>.md

. On start:

python3 .claude/skills/_lib/checkpoint.py load {RUN}/.dnr-respond-state

— absent/complete/

--fresh

→

reset

and start at Phase 0; running with

phase_done == N

→ read

phase0.json

…

phaseN.json

, resume at N+1. After each phase: Write payload to

{RUN}/.dnr-respond-state/_chunk.tmp

, then

checkpoint.py save {RUN}/.dnr-respond-state <N> <name> --from {RUN}/.dnr-respond-state/_chunk.tmp

. Never write

progress.json

directly; never pass payload via heredoc/stdin. After outputs:

checkpoint.py done {RUN}/.dnr-respond-state 4

Phase 0 — Parse the lead, locate inputs

Resolve
```
--logs
```
(dnr target config or bare directory) and inventory log files (
```
du
```
,
```
wc -l
```
,
```
head -2
```
each — identify formats and field positions). The corpus is expected to exist already — the target README covers generating it.
Parse the lead into starting entities:
- ```
INC-n
```
  → read that entry from
```
{RUN}/INCIDENTS.json
```
  (the run dir adopted above); its IPs, accounts, routes, and timeline rows are the seed set.
- alert line → source IP, rule, path, timestamp.
- IOC → the entity itself.
- free text → extract the observables (who reported, what data, when); the seed set may start as just a route or a table name.
State the working question in one sentence (e.g. "did 203.0.113.66's activity against /login succeed, and if not, what did?"). Everything in Phase 1 serves that question.

Checkpoint

phase0.json

{"lead": ..., "lead_type": ..., "entities": {"ips": [], "accounts": [], "routes": [], "windows": []}, "question": ..., "logs_dir": ..., "repo": ..., "files": [...]}

Phase 1 — Scope: pull everything the entities touched

For each seed entity, extract its complete activity, then expand one ring:

Per IP: every request — time-ordered, with route, status, size, UA, and authenticated user. Summarize phases of behavior, don't paste hundreds of lines.
Per account: every login (from which IPs), every authenticated request. Compare against that account's historical pattern in the same corpus — new IP, new UA, new volume, new hours are all signal. (A new IP alone is baseline noise — users roam; combine it with volume, cadence, or what the session did next before treating it as a lead.)
Per route: who else hit it the same way in the window? One attacker found via an alert may not be the only one.
Ring expansion (once): entities discovered above join the set — the account an IP logged into, the second IP that touched the same account, the route a session pivoted to. Expand once, deliberately; /dnr-hunt's open-ended loop is the tool when scope keeps growing.
Correlate the error log and alert queue rows for all entities into one timeline.

Checkpoint

phase1.json

{"activity": [{"entity", "summary", "first_seen", "last_seen", "requests", "key_lines": [...]}], "expanded_entities": [...], "timeline": [...]}

Phase 2 — Verdict and blast radius

Answer the working question with evidence on both sides:

Did it succeed? Status codes alone don't answer this — a 401 wall says no; 200s with anomalous sizes, error-then-success progressions, and data-shaped responses say yes. State the verdict and the discriminating evidence.
Blast radius, quantified. What data was reached: which routes/tables, how many records, over what time span, belonging to how many distinct users/customers. Each figure comes from a pipeline (count the exfil-page sizes, count the distinct ids walked, join walked ids to owners via the app's own data if available locally — running the target's deterministic
```
seed_command
```
early, before Phase 3, is fine).
Containment status check (read-only). Is the activity ongoing at the end of the corpus window, or did it stop? When was the last attacker action?
If the verdict is "did not succeed", the workup doesn't end — say what the attacker was trying and why it failed; that feeds the plan's hardening section and the
```
ruled_out
```
record.

Checkpoint

phase2.json

{"verdict": ..., "succeeded": bool, "discriminators": [...], "blast_radius": {"data": ..., "records": N, "distinct_victims": N, "window": ...}, "ongoing": bool, "last_activity": ...}

Phase 3 — Root cause and PoC

Same bar as

/dnr-hunt

Phase 3–4:

Read the implicated handler(s) in
```
--repo
```
; name the flaw (or the defense) at file/function precision; check sibling routes for the same flaw class.
Seed and start the app locally per target config:
```
seed_command
```
/
```
app_command
```
are target-relative — run them with the target directory as cwd; launch in the background via a single command that prints the PID (the same
```
python3 -c "...subprocess.Popen..."
```
pattern /dnr-hunt Phase 4 shows, with the port override env var if the default port is busy). Fire the minimal PoC, record command + response excerpt, fire the negative PoC against defended routes, then
```
kill <pid>
```
(never by port or pattern).
No runnable app → verdict ceiling is
```
suspected
```
, stated explicitly.

Checkpoint

phase3.json

{"root_cause": {"file", "function", "mechanism"}, "poc": {"command", "status", "response_excerpt"}, "negative_poc": {...}, "siblings_checked": [...]}

Phase 4 — The response plan (PROPOSED, NEVER EXECUTED) and outputs

Write the plan to

{RUN}/RESPONSE.md

— or

{RUN}/RESPONSE-<lead>.md

(e.g.

RESPONSE-INC-2.md

) if a

RESPONSE.md

from a different lead already exists in the run dir; never silently overwrite another incident's plan. Sections, every action carrying what / why / risk-if-wrong:

Verdict & summary — three sentences: what happened, did it succeed, how far it went.
Timeline — the merged entity timeline from Phase 1.
Containment (proposed) — block/deny candidates (IPs, sessions, tokens), accounts to suspend, routes to rate-limit or disable. For each: the evidence line that justifies it and what breaks if the call is wrong (e.g. blocking a NAT IP locks out legitimate users behind it).
Eradication & remediation (proposed) — the code fix, described at file/function level, handed off as a
```
/triage
```
-compatible vuln entry; interim mitigations if the fix will take time.
Recovery (proposed) — exactly which credentials rotate (the queried list, not "all users"), which customers get notified (the distinct-victim list from Phase 2), what monitoring confirms the attacker is out.
Detection engineering (proposed) — the rules that would have caught this earlier, derived from what you actually used to find it: the discriminating queries from Phase 2 turned into alert logic (e.g. error-rate per source on a route; sequential-id access cadence; account-from-new-IP at volume). Note which existing alerts fired, which were noise, and what that says about the queue.
Open questions — what this corpus cannot answer (earlier history, other log sources, whether stolen data was used elsewhere).

Then update

{RUN}/INCIDENTS.json

(same schema as

/dnr-hunt

; create it if absent): add or enrich this incident — verdict, quantified impact, root cause, PoC, timeline. Extra keys are fine — graders match on content, not structure. Negative outcomes go to

ruled_out

Mark complete (

checkpoint.py done {RUN}/.dnr-respond-state 4

) and point the user onward (substitute the literal

{RUN}

path):

for the fix, from inside
```
{RUN}
```
:
```
/triage INCIDENTS.json --repo <repo>
```
then
```
/patch TRIAGE.json --repo <repo>
```
— both write to the directory they're invoked from, so running them there lands the verdicts and patches beside the incidents
on a dnr target:
```
python <target>/grade.py {RUN}/INCIDENTS.json
```
to self-score (the user runs this)
a human reviews and executes (or rejects) each proposed action; nothing in RESPONSE.md has been done

Customizing beyond the demo

Feed it your real alert queue one alert at a time — the lead parser takes any JSON or prose alert; the method doesn't change.
Auth logs, CDN/WAF exports, and EDR threat events slot into Phase 1 as additional per-entity activity sources; keep the single merged timeline.
The Phase 4 plan template is the part most worth adapting to your org: map containment to your actual controls (WAF rules, IdP session revocation, feature flags) — still as proposals routed to the owning team, never as actions the agent takes.

dnr-respond

NPX Install

Tags

SKILL.md Content

dnr-respond

Hard rules (shared with /dnr-hunt — the track's contract)

Run directory and checkpointing

Phase 0 — Parse the lead, locate inputs

Phase 1 — Scope: pull everything the entities touched

Phase 2 — Verdict and blast radius

Phase 3 — Root cause and PoC

Phase 4 — The response plan (PROPOSED, NEVER EXECUTED) and outputs

Customizing beyond the demo