How CTF-Sandbox-Orchestrator Routes to Sub-Skills: Evidence-Driven Routing Explained

The CTF-Sandbox-Orchestrator routes to sub-skills by evaluating the dominant evidence surface against a router matrix and instantiating the matching $competition-* child skill via the master-route.ps1 PowerShell engine.

The CTF-Sandbox-Orchestrator serves as the single default entry point for every competition-style task in the zhaoxuya520/reverse-skill repository. Unlike manual skill selection, this orchestrator implements an evidence-first routing system that automatically narrows CTF, exploit, reverse engineering, and DFIR tasks to the most specialized sub-skill based on observable technical blockers.

Three-Stage Routing Architecture

Stage 1: Establish the Sandbox Model

The orchestrator assumes all user-presented targets, binaries, hosts, or identities live inside a sandbox environment. According to CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md, it builds a minimal node-map and records the first observable evidence—such as a network request, file artifact, or crash dump—before making any routing decisions.

Stage 2: Identify the Dominant Surface

While analyzing the initial evidence, the orchestrator asks: What domain now dominates the problem? It searches for a decisive blocker within the evidence stream, such as a "WebSocket handshake," "JWT claim confusion," or "Firmware partition." The authoritative mapping of these surfaces to skill tokens lives in router-matrix.md located at CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md.

Stage 3: Route to the Narrowest Child Skill

Once a single surface is clearly dominant, the orchestrator instantiates the matching child skill using a $competition-* variable (e.g., $competition-web-runtime or $competition-jwt-claim-confusion). This logic is implemented in skills/scripts/master-route.ps1, which evaluates the matrix and transfers control to the selected skill's entry point.

Routing Mechanics and Re-Routing Logic

The orchestrator's routing behavior follows four strict mechanical rules:

1. Default Entry Only: The orchestrator's SKILL.md marks it as the only implicit skill. All other competition-* skills are downstream-only and unreachable without passing through the orchestrator.

2. Evidence-First Decision: The system never prompts users to name a child skill. Instead, it selects the first narrow flow that can be proven from the evidence, such as identifying a "request-normalisation-smuggling parser" as the active blocker.

3. Router Matrix Structure: The router-matrix.md file contains a table of rules mapping dominant surfaces to child-skill tokens. Examples include:

   • Route By Dominant Surface → Web And Runtime → $competition-web-runtime
   • Route By Dominant Surface → Crypto, Stego, Mobile → $competition-crypto-mobile

4. Dynamic Re-Routing: If evidence drifts during analysis—broadening or revealing a new decisive boundary—the child skill returns control to the orchestrator. The orchestrator re-evaluates the matrix and selects a new $competition-* token, ensuring the workflow always remains on the most specific path.

PowerShell Implementation Details

The skills/scripts/master-route.ps1 file implements the generic routing engine. The script evaluates the current evidence against the router matrix and launches the appropriate child skill:

# master-route.ps1 (simplified)

# $evidence holds the current dominant evidence type (e.g. 'web-runtime')

switch ($evidence) {
    'web-runtime'               { $nextSkill = $competition-web-runtime }
    'jwt-claim-confusion'       { $nextSkill = $competition-jwt-claim-confusion }
    'zip-archive'               { $nextSkill = $competition-zip-archive }
    # … (all entries from router-matrix.md)

}

# Hand over control to the chosen child skill

if ($nextSkill) {
    Write-Host "Routing to sub-skill:" $nextSkill
    & "$PSScriptRoot/../$nextSkill/SKILL.ps1"
}

Child skills reside in directories under CTF-Sandbox-Orchestrator/competition-*/, with each directory containing a SKILL.md that defines the specialized domain logic. When the orchestrator identifies a "WebSocket handshake" as the dominant blocker, it references $competition-websocket-runtime, which maps directly to CTF-Sandbox-Orchestrator/competition-websocket-runtime/SKILL.md.

Re-routing occurs when the current skill no longer matches the dominant surface:

# Pseudo-code illustrating re-routing logic

if ($currentSkill -and -not (MatchesDominantSurface $currentSkill)) {
    Write-Host "Evidence drifted – returning to orchestrator"
    Invoke-Expression "$PSScriptRoot/../ctf-sandbox-orchestrator/SKILL.ps1"
}

Key Files in the Routing System

• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md: Defines the orchestrator's core rules and the list of available $competition-* tokens.
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md: The authoritative routing matrix mapping dominant evidence surfaces to child-skill identifiers.
• skills/scripts/master-route.ps1: The PowerShell engine that reads the matrix, evaluates evidence, and launches selected sub-skills.
• skills/scripts/case-init.ps1: Guard script ensuring case scope and evidence chain preparation before routing occurs.
• CTF-Sandbox-Orchestrator/competition-*/SKILL.md: Individual downstream skills (e.g., competition-web-runtime) that handle concrete domain analysis.

Summary

• The CTF-Sandbox-Orchestrator acts as the mandatory entry point for all CTF-style tasks in the zhaoxuya520/reverse-skill repository.
• Routing relies on three stages: establishing the sandbox model, identifying the dominant evidence surface, and instantiating the narrowest matching child skill.
• The router-matrix.md file provides the deterministic mapping between technical blockers and $competition-* skill tokens.
• The master-route.ps1 PowerShell script implements the routing engine, transferring control to child skills based on evidence evaluation.
• Dynamic re-routing ensures the analysis path automatically adjusts when evidence surfaces change during task execution.

Frequently Asked Questions

What triggers the CTF-Sandbox-Orchestrator to route to a specific sub-skill?

The orchestrator routes based on the dominant evidence surface identified in the initial task data. When a decisive blocker like a JWT claim, WebSocket handshake, or firmware partition is detected, the orchestrator matches this surface against the router-matrix.md mapping and instantiates the corresponding $competition-* child skill.

Can I manually select a sub-skill without going through the orchestrator?

No. According to the source code in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md, all competition-* skills are designated as downstream-only. The orchestrator is the single implicit entry point, and sub-skills must be reached through its evidence-driven routing logic.

What happens if the evidence changes during analysis?

The system supports re-routing. If the evidence drifts and the current child skill no longer matches the dominant surface, control returns to the orchestrator. The master-route.ps1 script re-evaluates the evidence against the router matrix and selects a new, more appropriate child skill to handle the updated technical context.

Where are the routing rules defined?

The routing rules live in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md. This file contains the authoritative mapping of dominant surfaces (e.g., "Web And Runtime", "Crypto, Stego, Mobile") to their respective child-skill tokens, which the master-route.ps1 script consumes to make routing decisions.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}