/red-team-flow

name: red-team-flow
description: Generate SITF-compliant attack flow JSON from red team or pentest reports. Accepts report files, URLs, or pasted findings. Use when documenting offensive security engagements.
argument-hint: <engagement-name> [--file path | --url url | paste report text]
tools: Read, Grep, Glob, WebFetch, Write, Bash

Red Team Flow Generator

Generate SITF-compliant attack flow JSON files from red team or penetration testing reports.

Usage

/red-team-flow <engagement-name> [source]

• `engagement-name`: Identifier for the engagement (e.g., "acme-2026q1", "client-sdlc-audit")
• `source`: One of:
• `--file <path>`: Path to report file (markdown, txt, json, pdf)
• `--url <url>`: URL to report or findings page
• Omit to paste report text directly in conversation

Arguments: $ARGUMENTS

Supported Input Formats

The skill accepts red team and pentest reports in various formats:

Text-Based Reports

• Markdown reports with findings sections
• Plain text engagement notes
• Bullet-point attack chains
• Executive summaries with technical appendix

Structured Formats

• JSON findings export
• CSV with columns: finding, target, technique, evidence
• YAML engagement summaries

Report Sections Recognized

The skill looks for these common report patterns:

• "Findings", "Vulnerabilities", "Attack Path", "Kill Chain"
• "Initial Access", "Lateral Movement", "Privilege Escalation"
• "Recommendations", "Remediation" (used for control mapping)
• Numbered steps (1., 2., 3. or Step 1, Step 2)
• MITRE ATT&CK references (T1xxx)

Instructions

When this skill is invoked:

Phase 1: Report Ingestion

1. **If `--file` specified:**

• Read the file content
• Detect format (markdown, txt, json, csv, yaml)
• Extract structured findings

2. **If `--url` specified:**

• Fetch the URL content
• Parse as report or findings page

3. **If no source specified:**

• Prompt user to paste report content
• Or use context from current conversation

4. **Normalize the input:**

• Extract attack steps/findings into a structured list
• Identify: target component, action taken, evidence, outcome
• Preserve attack chain order if present

Phase 2: Technique Mapping

1. Read `techniques.json` to get the full SITF technique library.

2. For each finding/attack step, find the best matching technique:

• Match by **action semantics**, not surface keywords
• Map pentest terminology to SITF:
• "GitHub Actions exploit" → T-C003 (PWN Request) or T-C004 (Script Injection)
• "Stole AWS creds from logs" → T-C005 (Secret Exfiltration from Workflow)
• "Published malicious package" → T-R004 (Publishing Malicious Package)
• "Accessed prod via stolen token" → T-P001 (Abuse Production Credentials)
• If MITRE ATT&CK IDs are in the report, cross-reference with SITF mappings

3. If no matching SITF technique exists:

• Check if finding is **in-scope** for SITF (SDLC/supply-chain related)
• If in-scope: Create placeholder with `"type": "technique-gap"`
• If out-of-scope (generic infra attack): Note in output, reference MITRE ATT&CK
• If the **initial access** is out-of-scope (e.g. exploiting an internet-facing app, MITRE T1190), describe it in the entry point's `customLabel` and connect the entry point directly to the first in-scope technique

4. For pentest reports with isolated findings (not chained):

• Group findings by target component
• Create parallel technique nodes within each component
• Connect entry point to each finding independently

5. **Contributing conditions** (a misconfiguration that enabled a step but wasn't an action the team took, e.g. tokens written to logs): show as a technique node only if it carries useful controls. Prefix its `customLabel` with "Contributing:" and connect it with a dashed edge (see `/attack-flow` Phase 4)

Phase 3: Layout Calculation

Apply these layout rules (consistent with `/attack-flow`):

Rule 1: Component Layout (Left-to-Right by Attack Flow)

• Order components by their **sequence in the attack chain**
• If findings aren't chained, order by: endpoint → vcs → cicd → registry → production
• Component x-positions: Use increments of ~300px starting from x=50

Rule 2: Technique Ordering (Top-to-Bottom)

• **Chained attacks**: Order by attack sequence
• **Isolated findings**: Order by severity (Critical → High → Medium → Low)
• Vertical gap between techniques: ~130px
• First technique starts at y = component.y + 80

Rule 3: Technique-Component Centering

• technique.x = component.x + (component.width - technique.width) / 2
• With component.width=250 and technique.width=160: offset = 45
• Example: component at x=50 → technique at x=95

Rule 4: Component Sizing

• Width = 250px (standard)
• Height = max(500, (technique_count × 130) + 160)

Rule 5: Edge Connections

• Technique nodes only have a `top` target handle and a `bottom` source handle (`app/visualizer.html`). Entry points expose `right`/`bottom` sources, exit points `left`/`top` targets
• Use `sourceHandle: "bottom"`, `targetHandle: "top"` within a component. For cross-component edges, `right`/`left` is the convention, but on technique nodes it falls back to bottom/top. Don't design layouts that rely on side connections
• Use `"type": "smoothstep"` for all edges
• Edge JSON structure (including dashed edges) is the same as `/attack-flow` Phase 4

Rule 6: Edge Labels (Minimal)

• Labels overlap nodes on the canvas. Leave most edges unlabeled (`"label": ""`)
• Label at most 3-5 key pivots (typically cross-component), 1-2 words each: "AWS keys", "PAT", "PR #123"
• Report evidence (secret names, PR numbers, commands) goes in technique `customLabel` / `evidence`, never on edges
• Use `"labelStyle": { "fill": "#DC2626", "fontWeight": 600, "fontSize": 10 }` and a transparent `"labelBgStyle": { "fill": "#FFFFFF", "fillOpacity": 0 }`

Phase 4: JSON Generation

Generate attack flow JSON with this