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

1. If `--url` specified:

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

1. If no source specified:

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

1. 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.

1. 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

1. 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

1. 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

1. 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:

1. For each technique used in the attack:

• List the protective controls from techniques.json
• Identify which controls were missing (enabled the attack)

1. Generate a Controls Gap Summary:

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

1. 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

1. Write the JSON file to flows/red-team/<engagement-name>.json
2. Validate JSON: python3 -c "import json; json.load(open('file'))"
3. 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`

1. 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.

Pentest vs Red Team Handling

Red Team Reports (attack chains):

• Typically have sequential steps (A → B → C → D)
• Generate connected flow with edges between techniques
• Entry point connects to first technique, exit point to last

Pentest Reports (isolated findings):

• May have unconnected findings per component
• Generate parallel techniques within components
• Entry point fans out to multiple techniques
• Each finding may have its own exit point or shared "Findings Reported" exit

The skill auto-detects based on report structure:

• Sequential numbering / "then we..." / "next..." → chained flow
• Bullet lists / severity ratings / individual findings → parallel flow