# Redteam Report Template

Client-facing red-team deliverable format, codifies the Subject / Observations /...

- Repository: https://github.com/Zyrexnn/Cybermes (987 stars)
- Category: Documents
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add Zyrexnn/Cybermes --skill redteam-report-template -g -a claude-code -y`
Codex: `npx skills add Zyrexnn/Cybermes --skill redteam-report-template -g -a codex -y`
Cursor: `npx skills add Zyrexnn/Cybermes --skill redteam-report-template -g -a cursor -y`
Gemini CLI: `npx skills add Zyrexnn/Cybermes --skill redteam-report-template -g -a gemini-cli -y`

## Description

Client-facing red-team deliverable format, codifies the Subject / Observations / Description / Impact / Recommendation / PoC structure used for external red-team engagements (not bug-bounty platform reports). Different audience, different tone, different cadence. Built from an authorized engagement deliverable where 14 findings were packaged into a 52KB MD + 2.2MB DOCX with 16 embedded screenshots. Use when the engagement is "external red team for an enterprise client" (not H1/Bugcrowd/Intigriti), when generating the final report, when the client has specified a custom report format, or when packaging findings into DOCX/PDF.

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

## When to use

Use this skill for **client-deliverable** reports:
- External red-team engagements with a signed SOW
- Pentest reports going to a CISO / IT-Sec team (not a triager)
- Findings that will be reviewed by both technical and non-technical stakeholders
- Reports that need DOCX/PDF output (not just markdown / platform UI)

Do NOT use for:
- Bug-bounty platform submissions (use `report-writing` / `bugcrowd-reporting` instead)
- Quick proof-of-concept memos
- Internal team writeups

---

## The 6-section format per finding

This is the canonical structure each finding follows:

```markdown
## Finding F##: <descriptive title>

**Severity:** Critical / High / Medium / Low / Informational
**Status:** Confirmed / Patched mid-engagement / Suspected (1 signal)
**CVSS 3.1:** <score> (<vector>)
**Affected Asset:** <URL / IP / app name>

### 1. Subject
<One-line statement of the issue. Plain English, no jargon.>

### 2. Observations
<Bulleted list of what was observed during testing. Concrete facts only, no interpretation yet.>
- <Observation 1>
- <Observation 2>
- ...

### 3. Description
<Technical explanation of the vulnerability. 2-4 paragraphs. Reader should understand WHY the observations indicate a vulnerability, what the underlying flaw is.>

### 4. Impact
<What an attacker could achieve. Concrete attacker outcomes, NOT generic CIA triad statements. Tie to the client's business, money, data, reputation, regulatory exposure.>

### 5. Recommendation
<Specific, actionable remediation. Vendor patch, configuration change, code-level fix. Avoid "implement security best practices", say what specifically.>

### 6. Proof of Concept (PoC)
<Steps to reproduce, numbered. Include the exact HTTP requests, payloads, tools used.>

**Step 1:** <action>
```http
<full HTTP request or curl one-liner>
```

**Step 2:** <action>
```
<response excerpt>
```

**Screenshot:**
![F##_descriptive_name](screenshots/F##_descriptive_name.png)
```

---

## Severity & status disciplines

The rest: https://github.com/Zyrexnn/Cybermes/blob/HEAD/knowledge/Claude-BugHunter/skills/redteam-report-template/SKILL.md