report-writer-casebook

You produce casebook.html — a single self-contained pentest deliverable styled like an operator's field report. You DO NOT touch report.md, report.html, timeline.md, hosts.csv, engagement.yaml, or anything under evidence/. You only emit casebook.html (and optionally regenerate it if it already exists).

When to invoke

• At engagement Final (user says "wrap up", "we're done", or runs /report casebook)
• On any explicit operator request to refresh the casebook view
• NOT on Capture triggers (that's the markdown report-writer's job)

Inputs (read-only)

engagements/<client-slug>/<YYYY-MM-DD>/
├── engagement.yaml      ← client, dates, model, scope, assessor
├── report.md            ← canonical findings (parse F-sections by their headings)
├── timeline.md          ← event-line entries
├── hosts.csv            ← host,ip,finding_id,proto,port
└── evidence/
    ├── raw/*.txt        ← terminal-style command transcripts (inline into .term blocks)
    └── F*/*.txt         ← per-finding evidence files

Output

engagements/<client-slug>/<YYYY-MM-DD>/
└── casebook.html        ← single self-contained HTML (~250-500 KB depending on evidence inlining)

No external dependencies except https://cdn.jsdelivr.net/npm/[email protected]/dist/mermaid.min.js and Google Fonts (loaded at view time). The CSS and most JS are inlined.

Run

python skills/scripts/render_casebook.py \
    --engagement engagements/<client-slug>/<YYYY-MM-DD>/ \
    --out engagements/<client-slug>/<YYYY-MM-DD>/casebook.html

The renderer is idempotent — each run regenerates the file from the current state of the engagement dir.

Dynamic data sources — every section is engagement-specific

Nothing in the casebook is hardcoded to a particular engagement. Each section synthesizes from the engagement files; the renderer was de-templated so an AD engagement, a web-app test, and an HTB box each produce a faithful report. What drives what:

Section	Source of truth	Fallback if absent
Hero title / subhead	engagement.yaml (client, model, scope_in, assessor); severity counts	generic "Security assessment"
Exec severity grid	finding severities, affected-host fields, _dwell() from timeline.md, root_flag/user_flag	—
Mitigation roadmap (P0/P1/P2)	each finding's #### Remediation items, bucketed by their **Immediate:** / **Short-term:** / **Long-term:** label	unlabeled items → P1
Residual-risk note	derived outcome + compromised hosts	generic
Story prose	report.md ## Engagement Narrative or ## Executive Summary (verbatim)	stitched from Critical/High finding descriptions
Story headline	engagement.yaml headline: (optional)	"How the chain actually ran."
Story stats	findings counts, timeline length, hosts compromised, dwell, objective flag	—
Attack graph (mermaid)	attack_graph.mmd if present	synthesized linear chain F01→…→outcome, node colors by phase
Kill-chain replay	timeline.md + hosts.csv (always)	section skipped if timeline empty
Attack chains	report.md ## Attack Chains	synthesized from ordered finding titles + outcome
Dead ends	report.md ## Dead Ends (- title — why bullets)	section omitted entirely (no stale placeholder)
Strengths	report.md ## Summary of Strengths (bullets)	section omitted
Close caption	findings counts + outcome flags	generic