# CTF-Sandbox-Orchestrator: How It Routes to 40+ Sub-Skills in the Reverse-Skill Repository

> Explore the CTF-Sandbox-Orchestrator, the entry point skill that models challenge environments and routes tasks to over 40 sub-skills using a router matrix.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: deep-dive
- Published: 2026-08-08

---

**The CTF-Sandbox-Orchestrator is the entry-point skill that models challenge environments as sandboxes and routes tasks to over 40 specialized sub-skills by consulting a router matrix based on dominant evidence types.**

The `reverse-skill` repository provides a structured framework for analyzing CTF competitions and security challenges. At its core, the **CTF-Sandbox-Orchestrator** serves as the central router that interprets task contexts and delegates to domain-specific sub-skills. This orchestrator ensures that every competition-type task begins with a consistent sandbox model before narrowing to the most specific investigation path.

## What Is the CTF-Sandbox-Orchestrator?

The **CTF-Sandbox-Orchestrator** is declared in [`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md) as the default skill for any competition work. It operates on the fundamental assumption that all targets are **sandbox-internal** until proven otherwise. Unlike standalone analysis tools, this orchestrator maintains active control throughout the entire investigation lifecycle, only releasing control to a child skill after identifying a decisive evidence path.

The orchestrator functions as a **stateful router** rather than a simple dispatcher. It builds an internal model of the challenge environment, tracks the progression of evidence discovery, and dynamically adjusts its routing decisions as new blockers or surfaces emerge during analysis.

## Core Architecture and Design Principles

### Entry Point and Sandbox Modeling

The orchestrator is defined in [`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md) as the mandatory entry point for all competition tasks. Upon activation, it constructs a generic **node-map** representing the environment topology: hosts → proxies → processes → containers. This sandbox model treats every target as an internal entity within the competition environment, creating a consistent analytical context regardless of the specific challenge domain.

### Evidence Priorities and Routing Logic

Routing decisions follow a strict **evidence hierarchy** defined in the skill configuration. The orchestrator evaluates potential investigation paths in this priority order:

- **Runtime behavior**
- **Traffic** (network captures and flows)
- **Assets** (files and resources)
- **Process/container** information
- **Persisted state** (databases, logs)
- **Generated artifacts** (output files, reports)
- **Source** code
- **Comments** and documentation

This ordering ensures that dynamic analysis of active systems takes precedence over static examination of source code or documentation.

### The Router Matrix

The definitive routing logic resides in [`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md). This matrix maps **dominant surface types** to specific `$competition-*` child skills. The orchestrator consults this matrix only after the sandbox model is active and a clear blocker has been identified, ensuring routing decisions are contextually grounded in the live environment state.

## How Routing Works in Practice

The orchestrator implements a five-phase routing workflow:

1. **Sandbox Activation** – Build the node-map of hosts, proxies, processes, and containers to establish the environment model.

2. **Identify Dominant Blocker** – Detect the first decisive evidence type (e.g., an HTTP endpoint, a binary crash, a JWT claim, or an anomalous traffic pattern).

3. **Consult Router Matrix** – Map the blocker's category to a specific `$competition-*` child skill using the definitions in [`references/router-matrix.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/references/router-matrix.md).

4. **Load Child Skill** – Internally load only the selected sub-skill or its reference file; all other skills remain downstream-only and are not activated.

5. **Re-Routing** – If the investigation path broadens or the dominant blocker changes, the orchestrator returns to phase 1 and may select a different child skill to handle the new evidence type.

This mechanism ensures that only the most relevant domain expertise is engaged for any given challenge state.

## The 40+ Sub-Skill Ecosystem

The router matrix defines **over 40** child skills, each prefixed with `$competition-` and residing in dedicated folders under `CTF-Sandbox-Orchestrator/competition-*`. These skills are organized into functional domain families:

- **Web & Runtime**: `$competition-web-runtime`, `$competition-browser-persistence`, `$competition-websocket-runtime`
- **Reverse / Exploit / DFIR**: `$competition-reverse-pwn`, `$competition-malware-config`, `$competition-firmware-layout`, `$competition-pcap-protocol`
- **Crypto / Stego / Mobile**: `$competition-crypto-mobile`, `$competition-zip-archive`, `$competition-stego-media`, `$competition-android-hooking`, `$competition-ios-runtime`
- **Agent / Cloud / Container / Supply-Chain**: `$competition-prompt-injection`, `$competition-agent-cloud`, `$competition-container-runtime`, `$competition-supply-chain`, `$competition-k8s-control-plane`
- **Identity & Windows**: `$competition-identity-windows`, `$competition-windows-pivot`, `$competition-lsass-ticket-material`, `$competition-dpapi-credential-chain`, `$competition-kerberos-delegation`

Each child skill contains specialized reference files that guide the detailed investigation once the orchestrator delegates control.

## Implementation and Code Structure

The orchestrator implements a **detect → map → load** decision flow. The skill engine processes the markdown configuration files to execute this logic:

```yaml

# Routing logic used by the orchestrator (simplified)

if sandbox_active:
    blocker = detect_dominant_blocker(task_context)
    child_skill = router_matrix[blocker.category]   # e.g. "$competition-web-runtime"

    load_skill(child_skill)                         # internal load, no user prompt

else:
    activate_sandbox()

```

```yaml

# Example router-matrix entry mapping evidence to skill

# Web & Runtime → General site, API, auth, session, upload …

"web-api" => "$competition-web-runtime"

```

These configurations demonstrate how the orchestrator transitions from evidence detection to skill invocation without manual intervention.

## Key Source Files

The orchestration logic depends on these specific files within the `reverse-skill` repository:

- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md)** – Defines the orchestrator skill, core rules, four-phase workflow, and evidence priorities.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md)** – The definitive routing matrix that maps dominant surfaces to child `$competition-*` skills.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/web-api.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/web-api.md)** – Reference for Web-API domain; loaded when routing selects `$competition-web-runtime`.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reverse-native.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reverse-native.md)** – Reference for native reverse-engineering tasks; used for `$competition-reverse-pwn`.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/crypto-mobile.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/crypto-mobile.md)** – Reference for crypto, stego, and mobile domains.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/agent-cloud.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/agent-cloud.md)** – Reference for agent, cloud, container, and supply-chain challenges.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/identity-windows.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/identity-windows.md)** – Reference for identity-related Windows tasks.
- **[`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reporting.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reporting.md)** – Guidelines for formatting final evidence reports after sub-skill completion.

## Summary

- The **CTF-Sandbox-Orchestrator** acts as the mandatory entry point for all competition tasks in the `reverse-skill` repository.
- It establishes a **sandbox model** (hosts → proxies → processes → containers) before consulting the **router matrix** to delegate to specific sub-skills.
- **Evidence priorities** determine routing decisions, with runtime behavior taking precedence over static analysis or comments.
- The system manages **40+ sub-skills** organized by domain expertise, each referenced via `$competition-*` prefixes.
- Routing is **dynamic and reversible**; the orchestrator can re-route if the investigation path changes or new blockers emerge.

## Frequently Asked Questions

### What is the primary role of the CTF-Sandbox-Orchestrator?

The CTF-Sandbox-Orchestrator serves as the entry-point skill that governs every competition-type task in the `reverse-skill` repository. It models the challenge environment as a sandbox and maintains active orchestration throughout the analysis, only delegating to a specific sub-skill after identifying a dominant evidence type or minimal investigation path.

### How does the orchestrator decide which sub-skill to invoke?

After activating the sandbox model, the orchestrator identifies the dominant blocker or evidence type in the task context. It then consults the [`references/router-matrix.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/references/router-matrix.md) file to map that evidence category to the corresponding `$competition-*` child skill, loading only that specific reference file while keeping others downstream-only.

### What evidence types take priority when routing?

The orchestrator follows a strict hierarchy defined in [`SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/SKILL.md): runtime behavior takes highest priority, followed by traffic, assets, process/container information, persisted state, generated artifacts, source code, and finally comments. This ensures dynamic analysis informs routing decisions before static examination.

### Where are the 40+ sub-skills defined in the repository?

The sub-skills are organized within the `CTF-Sandbox-Orchestrator/competition-*` directories, with their routing logic centralized in [`CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md). Each skill is prefixed with `$competition-` and grouped into families covering web runtime, reverse engineering, cryptographic challenges, cloud/container security, and Windows identity domains.