Skip to content
Back to skills

Forensic Report

ASecurity

Use when writing, assembling or validating a forensic report or report package — after evidence has been collected, when the user asks to write up an investigation, produce findings, review a draft report, or check a package before release.

  • 5 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 3, 2026
researchrustgo

Security analysis

A100/100

Pro scans all 5 files and shows the line behind each finding

Scanned October 3, 2026

npx -y skills add yldio/skills --skill forensic-report --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Forensic Report?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Forensic Report
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/yldio-forensic-report/badge)](https://www.skillsdirectory.com/skills/yldio-forensic-report)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: forensic-report
description: Use when writing, assembling or validating a forensic report or report package — after evidence has been collected, when the user asks to write up an investigation, produce findings, review a draft report, or check a package before release.
user-invocable: true
disable-model-invocation: true
---

# Forensic report — write and validate

Turn collected evidence into a report package a sceptical reader can challenge
and a second examiner can reproduce. Packages follow the layout of the
`forensic-investigation` skill's `assets/template/`; procedure context is
`references/RUNBOOK.md` steps 5–7 and conduct rules are `references/PROCESS.md`
Part 2, both in this skill's folder.

Two modes. Writing a package: follow "Write". Checking one (yours or
another's): follow "Validate". A package is not done until it passes Validate.

## Write

Order: REPORT.md findings first, then TIMELINE.md, METHODOLOGY.md,
POSTMORTEM.md, INDICATORS.md, RECOMMENDATIONS.md, README.md last (it
summarises the rest). Every template carries its own fill instructions.

Finding anatomy — every finding, no exceptions:

```text
### N. Finding F-0X — <one plain assertion>
Source: `evidence/<specific-file>` [, `analysis/<file>`]
<the data>
<the reasoning, arithmetic shown inline>
Alternatives considered: <each one, and what excludes it or keeps it open>
Consequence: <what it means operationally>
What would change this: <the observation that would overturn it>
Confidence: <established fact | assessment low/moderate/high | reported | unknown>
```

Phrasing rules:

- State how strongly the findings support one explanation over a named
  alternative. Never state the probability that the explanation is true —
  that inversion (the transposed conditional) is the classic forensic error.
- Confidence words come from the fixed vocabulary in METHODOLOGY §6. Grade by
  corroboration and tamper-resistance: one uncorroborated tamperable source
  is at most a weak assessment, whatever it shows.
- Facts and interpretation stay visibly separate. Opinions are labelled and
  carry their basis.
- No claims about guilt, intent or identity beyond what the records carry. A
  credential is not a person; a user agent is not an identity.
- Unknowns are written as unknown. Do not fill a gap with a plausible guess.
- A layperson must be able to follow the results; mechanism detail goes under
  the plain statement.
- Cite specific evidence files, not globs, wherever a specific file exists.

## Validate

Work through `references/validation.md`, gate by gate, and report failures
with file and line. Two rules for the validator:

1. **Blind first.** Re-derive the key figures from `analysis/` and `evidence/`
   before reading the report's conclusions, and write your numbers down.
   Then compare. Checking the report's arithmetic after reading its
   conclusions is how reviewers inherit the author's errors.
2. **Verify, don't trust.** Run the hash check. Re-run the transform script if
   it exists. Resolve every cross-reference (F/Q/R/C identifiers, § numbers).
   A checklist item passes on evidence, never on the document's say-so.

Report the outcome as: gates passed, gates failed (with locations), and a
verdict — release, fix first, or re-examine.

## Rationalisations to refuse

| Thought | Reality |
|---------|---------|
| "The finding is obvious, one source is enough" | Single-source findings are where corrections come from. Corroborate or downgrade the confidence label. |
| "I'll round the numbers for readability" | Show exact figures and the arithmetic; readability comes from structure. |
| "The reader will understand this means X is guilty" | The report states evidence strength against alternatives. Nothing more. |
| "Validation slows the release" | An uncaught material error costs a public correction and the package's credibility. |
| "I wrote it, so I know it's consistent" | Authors cannot see their own drift. Run the checklist or hand it to someone who will. |

## Handling

Report packages contain sensitive material. Keep them inside their declared
boundary and never paste their contents into external services. This skill
sends nothing to any external service; writing and validation are local file
work over the package.

Files in this skill

  • SKILL.md4.2 KB
  • references/PROCESS.md10.7 KB
  • references/REFERENCES.md8.2 KB
  • references/RUNBOOK.md8.9 KB
  • references/validation.md4.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…