# Offensive Reporting

Penetration test and red team report writing methodology.

- Repository: https://github.com/SnailSploit/Claude-Red (10186 stars)
- Category: Documents
- License: MIT
- Last updated: 2026-10-12
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add SnailSploit/Claude-Red --skill offensive-reporting -g -a claude-code -y`
Codex: `npx skills add SnailSploit/Claude-Red --skill offensive-reporting -g -a codex -y`
Cursor: `npx skills add SnailSploit/Claude-Red --skill offensive-reporting -g -a cursor -y`
Gemini CLI: `npx skills add SnailSploit/Claude-Red --skill offensive-reporting -g -a gemini-cli -y`

## Description

Penetration test and red team report writing methodology. Covers executive summary structuring (risk-led narrative for non-technical readers), technical finding format (title, severity, affected scope, narrative, reproduction steps, impact, remediation, references), CVSS v3.1 / v4.0 scoring with vector justification, OWASP risk rating, evidence hygiene (redacting credentials, hashing client data, time-stamping every action), screenshot and PoC artifact management, finding chain narratives, scope/limitations/assumptions documentation, retest evidence and remediation tracking, deliverable formats (PDF, DOCX, HTML, JSON for SIEM ingestion), client-customer-deliverable separation, and common report mistakes (over-CVSSing, undermining the triager, missing the 'so what'). Use at the end of an engagement when authoring a deliverable, when restructuring a draft for executive readability, or when establishing a reusable report template for a consulting practice.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Penetration Test Reporting, Professional Methodology

A great finding lost in a bad report is a wasted finding. Reports are the artifact the client pays for, the auditor reads, and the developer fixes from. Treat the report with the same rigor as the exploit.

## Quick Workflow

1. Capture evidence as you exploit, never reconstruct after the fact
2. Draft each finding immediately while context is fresh; one finding = one numbered file
3. Build the executive summary last, after all findings are scored
4. Two-pass review: technical accuracy first, then read-as-CISO for narrative
5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system

---

## Report Structure (Standard)

```
1. Executive Summary             ← Last to write, first read
2. Engagement Overview
   2.1 Scope
   2.2 Methodology
   2.3 Limitations / Assumptions
   2.4 Timeline
   2.5 Team
3. Risk Summary                  ← Heatmap, finding count by severity
4. Technical Findings            ← One per finding, sorted by severity
5. Attack Narratives / Chains    ← Critical chains called out separately
6. Strategic Recommendations     ← Programmatic, not finding-by-finding
7. Appendices
   A. Tools Used
   B. Indicators of Compromise (for blue team)
   C. Raw Evidence Pointers
   D. Glossary
```

---

## Executive Summary, The 90-Second Read

The executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.

**Structure (one page max):**

1. **Engagement context**, what was tested, when, by whom (1 sentence)
2. **Headline finding**, the worst thing you found, in business terms (2, 3 sentences)
3. **Risk verdict**, overall posture in plain language (1 paragraph)
4. **Counts**, number of findings by severity, in a small table
5. **Top 3 strategic recommendations**, programmatic fixes, not "patch CVE-X"

The rest: https://github.com/SnailSploit/Claude-Red/blob/HEAD/Skills/utility/offensive-reporting/SKILL.md