/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

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

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

• Connect source.bottom → target.top for vertical flows within component
• Connect source.right → target.left for cross-component flows
• Add labels from report evidence ("Stolen AWS_ACCESS_KEY_ID", "via PR #123")
• Use `"type": "smoothstep"` for all edges

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