| name | walkthrough |
| description | Assemble a report-ready walkthrough.md for a SOLVED engagement - populate the Evidence gallery from the poc/ images captured during the engagement, and draft the step-by-step reproduction from state/loot/log (Killchain.md for pentest/bugbounty, state.md's Chain/Status for ctf) without fabricating. Use when asked to "write the walkthrough", "assemble the walkthrough", "close out the box/engagement", or at close-out once an engagement is marked SOLVED. |
Walkthrough auto-assembly
Turn a solved engagement into the full, report-ready targets/<eng>/walkthrough.md: rendered
evidence, a populated ## Evidence gallery, and a drafted narrative, so the operator only
reviews/polishes instead of assembling from scratch.
Convention: mark close-out explicitly
At close-out, write a STATUS heading into state.md:
## STATUS: SOLVED
(OWNED / ROOTED / COMPLETE also count.) This is the close-out signal: once present, the
CLAUDE.md execution loop runs Skill(walkthrough) (then Skill(learn)).
Steps
(a) Confirm the evidence is on disk (capture any missing key state now)
Evidence is captured LIVE during the engagement, straight into poc/ (via capture.sh /
Skill(screenshot)) -- there is no staging/drain step anymore. Confirm the PNGs are on disk,
and if a key state (foothold shell, the flag, an exploited render) was never captured, capture
it now before assembling:
ls targets/<eng>/poc/*.png targets/<eng>/poc/**/*.png 2>/dev/null
A walkthrough with an empty gallery means evidence was not captured as steps landed -- fix that
by capturing the reproducible states now, not by fabricating.
(b) Scaffold + gallery
python3 scripts/build-walkthrough.py <eng>
Idempotent: scaffolds the walkthrough structure from the framework template if missing, and
populates the ## Evidence gallery from every rendered card on disk. Never clobbers existing
narrative -- safe to re-run after step (a).
(c) Draft the narrative -- never fabricate
Read state.md (for ctf, also its ## Chain/## Status sections, the live working copy of
the attack path and the SOLVED/flags marker) and loot.md for the active engagement; for
pentest/bugbounty also read Killchain.md and log.md (a ctf engagement has neither; its live
chain and narrative live in state.md instead). Write the step-by-step reproduction into the
non-Evidence sections (Access -> Recon -> Foothold -> Privilege escalation -> root/flag), using
the EXACT commands, creds, and per-step results already captured in those files. If a fact needed
for a section is not present in the state files, do NOT invent it; leave a clearly marked
_TODO: <what is missing>_ for the operator instead.
Record HOW each vuln was DISCOVERED, not only the exploit. Every Foothold/Privesc step carries a
short "found via:" note - the probe/test/observation that revealed the bug (e.g. "found via:
registered a tag-marker username, saw it reflected unescaped in the users table"), so the reader can
re-FIND it, not just re-fire the payload. The discovery step IS part of the reproduction; a
walkthrough that only shows the working exploit hides how you got there.
Rewrite each command to the HUMAN form for the reader (technical team / client). log.md holds
the messy automation that actually ran (base64/pty wrappers, exports, ;-merged diagnostic
pipelines) - the walkthrough must NOT. Each step is ONE standalone command a person would type:
concrete values + FULL paths, no $VAR/export (inline an env var on the one command,
KRB5CCNAME=/tmp/x.ccache impacket-... ), no ;/&& chains, no echo banners. A merged
diagnostic from log.md becomes 2-3 clean single commands here. Interactive sub-steps (an smbclient
get, an su + password) are shown as the plain human action, not scripted.
(d) Preserve exploit scripts
Copy any exploit script (payload, escape/forge script, webshell) into
targets/<eng>/poc/scripts/, the same exploit-script-preservation discipline ctf-box and screenshot use --
the reviewer needs the code and the state together, not just a screenshot. Save it as <name>.md
with the code in a ```py/```sh/```js fence, NOT a bare .py/.sh/.js -
Obsidian only previews .md/images in the GUI, so a raw-extension script is invisible to the operator
reading the walkthrough. Reference the .md from the matching step; inline the actual payload as a
fenced block in the step itself so the walkthrough is self-contained.
(e) Verify complete
Before finishing, confirm:
- no unfilled template markers remain (
<entrypoint>, <foothold, or a bare - target: /
- reach: stub line), and
- the
## Evidence gallery has at least one rendered image reference row.
If either check fails, go back and fill the gap (more evidence to drain, more narrative to draft)
rather than leaving the walkthrough half-done.
Scope and safety
All output stays under targets/<eng>/ (gitignored) -- never write client data into session/*
or wiki/. Every step here is best-effort: build-walkthrough.py is idempotent and no-clobber.
Real client engagements still go through Skill(evidence) for redaction before the walkthrough
ships in a report; CTF/lab work can skip that.
On demand
Invoke this skill directly whenever you are ready to write the walkthrough, assemble the
walkthrough, or close out the box/engagement -- the same steps apply.
