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

If --file specified:
- Read the file content
- Detect format (markdown, txt, json, csv, yaml)
- Extract structured findings
If --url specified:
- Fetch the URL content
- Parse as report or findings page
If no source specified:
- Prompt user to paste report content
- Or use context from current conversation
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

Read techniques.json to get the full SITF technique library.
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
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
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
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 structure (identical to /attack-flow output):

{
  "metadata": {
    "name": "Engagement Name",
    "title": "Canvas Display Title",
    "created": "ISO-8601 timestamp",
    "version": "1.0",
    "framework": "SITF",
    "source": "red-team-report",
    "description": "Brief engagement description"
  },
  "nodes": [],
  "edges": []
}

Metadata field guidelines:

name: Short identifier (e.g., "acme-2026q1", "client-sdlc-audit")
title: Concise canvas title, max 5-7 words (e.g., "ACME CI/CD Pipeline Assessment", "Client SDLC Red Team Q1")
description: One sentence summary, max 150 characters
Do NOT write paragraph-length titles — save details for technique customLabels and evidence fields

Node types (same as /attack-flow):

entryPoint: How the engagement started (Assumed Breach, External Attacker, Insider, etc.)
component: SITF component container (endpoint, vcs, cicd, registry, production)
technique: Attack technique from techniques.json
technique-gap: Placeholder for missing SITF technique
exitPoint: Engagement outcome (Data Exfiltration, Persistence, Supply Chain Compromise, etc.)

Special metadata for red team flows:

Add "source": "red-team-report" to metadata
Add "engagement" field if client/engagement name is known
Add "scope" array listing in-scope components

Node Structure - Technique (with evidence)

{
  "id": "technique-c003-1",
  "type": "technique",
  "position": { "x": 95, "y": 160 },
  "data": {
    "id": "T-C003",
    "name": "PWN Request / Poisoned Pipeline Execution",
    "component": "cicd",
    "stage": "Initial Access",
    "description": "Full description from techniques.json",
    "risks": ["risk1", "risk2"],
    "controls": { "protective": [], "detective": [] },
    "customLabel": "Exploited workflow in repo X",
    "evidence": "PR #142 triggered workflow with write permissions",
    "severity": "Critical"
  },
  "zIndex": 10,
  "width": 160,
  "height": 96
}

Phase 5: Control Gap Analysis

After generating the flow, analyze defensive gaps:

For each technique used in the attack:
- List the protective controls from techniques.json
- Identify which controls were missing (enabled the attack)

Generate a Controls Gap Summary:

| Technique | Missing Control | OWASP SPVS |
|-----------|-----------------|------------|
| T-C003    | Minimal workflow permissions | V3.1 |
| T-C005    | Log sanitization | V2.5 |

Prioritize recommendations by:
- Number of techniques the control would prevent
- Severity of findings it addresses

Phase 6: Validation

Run this checklist before outputting:

[ ] Valid JSON structure (parse test passes)
[ ] Required fields: metadata.{name,title,created,version,framework,source}, nodes[], edges[]
[ ] All node IDs are unique
[ ] All edge source/target reference valid node IDs
[ ] Technique nodes use data.id and data.name (NOT techniqueId/label)
[ ] Technique nodes include full risks[] and controls from techniques.json
[ ] All techniques centered within components (x = component.x + 45)
[ ] Component heights adequate for technique count
[ ] Out-of-scope findings noted but not forced into SITF
[ ] Evidence preserved in customLabel or evidence fields
[ ] Exit points connected to terminal techniques
[ ] No orphaned nodes: every non-entry node has an incoming edge, EXCEPT roots marked "Contributing:"
[ ] Edge labels: at most 3-5 non-empty, each 1-2 words, transparent background
[ ] No client-identifying details unless the user confirmed the flow stays private

Phase 7: Output

Write the JSON file to flows/red-team/<engagement-name>.json
Validate JSON: python3 -c "import json; json.load(open('file'))"
Provide output summary:

## Red Team Flow: <engagement-name>

### Attack Chain
1. Initial Access via [entry point]
2. [Technique] → [Technique] → ...
3. Impact: [exit point]

### Techniques Used
| ID | Name | Component | Evidence |
|----|------|-----------|----------|
| T-C003 | PWN Request | CI/CD | PR #142 |
| ... | ... | ... | ... |

### Control Gaps Identified
| Missing Control | Would Prevent | Priority |
|-----------------|---------------|----------|
| Minimal workflow permissions | T-C003, T-C005 | High |
| ... | ... | ... |

### Out-of-Scope Findings
- [Finding X]: Generic cloud attack, see MITRE ATT&CK T1078

### Technique Gaps
- [Finding Y]: No matching SITF technique, run `/technique-proposal`

If technique-gaps exist, recommend /technique-proposal for each

Confidentiality

Red team reports are usually confidential, and flows may end up in a public repo or PR. Unless the user says otherwise, use a neutral engagement name, and leave client names, internal hostnames, account names and real secrets out of labels, evidence and metadata.

Iterating on a User-Edited Flow

Users often adjust the layout in the visualizer and save over the file, then ask for more changes.

Edit the file in place. Preserve the user's positions and sizes, and only move what the new change requires
Saving from the visualizer currently resets metadata.name to "Attack Flow" and drops title/description (check source, engagement and scope too). Check the metadata after every user save and restore it
To summarize the user's edits, diff the file against your last generated version

Examples

From File

/red-team-flow acme-2026q1 --file ./reports/acme-final-report.md

From URL

/red-team-flow client-audit --url https://internal.wiki/engagements/client-findings

From Pasted Text

/red-team-flow demo-engagement

We started with access to a developer laptop (assumed breach). Found GitHub 
PAT in ~/.config/gh/hosts.yml. Used the token to access private repos and 
discovered hardcoded AWS credentials in a workflow file. The AWS creds had 
admin access to production S3 buckets. We exfiltrated customer data as POC.

red-team-flow

Files1

SKILL.md.claude/skills/red-team-flow/SKILL.md