CTF-Sandbox-Orchestrator Architecture Explained: A Deep Dive into the Reverse-Skill Routing System

The CTF-Sandbox-Orchestrator is a lightweight, evidence-driven orchestration layer that enforces sandbox assumptions and routes to domain-specific child skills based on dominant evidence observed during security competitions.

In the zhaoxuya520/reverse-skill repository, this orchestrator serves as the mandatory entry point for all Capture The Flag (CTF) workflows. Rather than executing procedural code, it operates through declarative natural-language directives that AI-agent frameworks interpret to maintain disciplined investigative scope.

Core Components of the CTF-Sandbox-Orchestrator Architecture

The orchestrator's architecture consists of six interconnected components, each implemented as markdown files with specific structural conventions.

Orchestrator Skill Definition

The master configuration resides in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md. This file declares:

• Skill metadata: name, description, and default behavioral assumptions
• Child skill inventory: complete list of invocable downstream skills ($competition-* tokens)
• Evidence priority hierarchy: ordered trust levels from live runtime → captured traffic → served assets
• Routing directives: natural-language rules governing when and how to re-route

The skill definition establishes the sandbox model as the foundational assumption—that all user-provided artifacts belong to an isolated, bounded environment.

Router Matrix

The decision engine lives in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md. This is a lookup table mapping dominant surfaces to concrete skill tokens:

Dominant Surface	Child Skill Token
web/API	$competition-web-runtime
reverse/binary	$competition-reverse-pwn
crypto/stego/mobile	$competition-crypto-mobile
AI-agent/cloud/containers	$competition-agent-cloud
Windows identity/AD	$competition-identity-windows

The matrix is consulted only after sandbox activation and initial evidence classification, preventing premature specialization.

Domain-Specific Reference Files

Each child skill has a dedicated reference file providing:

• Ladders: step-by-step investigative procedures
• Evidence-to-keep lists: what data must be preserved
• Pitfall warnings: common distractions or false paths

Key reference files include:

• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/web-api.md — web and API challenge guidance
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reverse-native.md — reverse engineering and native exploitation
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/crypto-mobile.md — cryptography and mobile security
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/agent-cloud.md — cloud and AI-agent challenges
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/identity-windows.md — Active Directory and Windows identity
• CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reporting.md — evidence packaging and report generation

The orchestrator loads only the reference matching the selected child skill, minimizing cognitive load.

Evidence Priority List

Defined in the same SKILL.md file, this ordered hierarchy resolves conflicts when evidence sources disagree:

1. Live runtime behavior
2. Captured network traffic
3. Static served assets
4. Documentation and metadata

Higher-priority sources override lower ones during routing decisions.

Implicit Routing Logic

Unlike traditional orchestrators that execute code, this architecture encodes routing in natural-language directives. As documented in the "Router Role" and "Re-Route Rules" sections of SKILL.md, these directives enforce:

• Single active skill: only one child skill at a time
• Evidence-gated transitions: re-routing occurs only when dominant blocker changes
• Return-to-orchestrator protocol: any path divergence forces re-evaluation from the top

CTF-Sandbox-Orchestrator Workflow: Six Stages

The orchestrator progresses through a deterministic sequence:

1. Enter the sandbox — Automatic invocation for any CTF-style prompt; sandbox assumptions are locked in.

2. Build minimal node map — Identify immediate hosts, containers, processes, and files without deep analysis.

3. Trace one minimal path — Execute a single request, open one file, or trigger one crash to reveal a decisive branching point.

4. Select domain via router matrix — Map the observed blocker to a child skill token using router-matrix.md.

5. Load domain-specific reference — Pull only the matching ladder and checklist (e.g., web-api.md for web challenges).

6. Iterate or re-route — If evidence shifts domains, return to stage 1 and re-evaluate.

This workflow ensures evidence-first routing—domains are selected based on concrete observations, not premature hypotheses.

Architectural Guarantees of the CTF-Sandbox-Orchestrator

The design provides five structural invariants:

• Single entry point: All competition work must flow through ctf-sandbox-orchestrator; direct skill entry is prohibited.

• Domain isolation: Child skills are downstream-only; they cannot self-invoke without orchestrator-mediated routing.

• Evidence-first routing: The router matrix activates only after observable evidence is recorded, preventing speculative domain switches.

• Minimal loading: Reference files load selectively based on current routing, keeping memory and attention focused.

• Re-routing safety: "Re-Route Rules" in SKILL.md force orchestrator-level re-evaluation whenever investigative paths diverge, preserving sandbox consistency.

CTF-Sandbox-Orchestrator in Practice: Declarative Examples

These YAML-structured declarations illustrate how AI-agent frameworks interact with the orchestrator. They are not executable scripts but represent the interpreted logical flow:

# Stage 1: Starting the sandbox

- skill: ctf-sandbox-orchestrator
  action: start
  notes: |
    Assume all supplied binaries and endpoints belong to the sandbox.

# Evidence declaration and routing

- evidence:
    type: http
    url: /admin/secret
    method: GET
    response: 404
- decision: dominant-surface = "web"
- route: $competition-web-runtime   # resolved via router-matrix.md

# Re-routing when evidence shifts domains

- evidence:
    type: binary
    file: challenge.bin
    behavior: crash at offset 0x3f2a
- decision: dominant-surface = "reverse"
- route: $competition-reverse-pwn

Both examples demonstrate the declare-evidence → decide-domain → route pattern enforced throughout the architecture.

Summary

• CTF-Sandbox-Orchestrator is the mandatory entry point for all CTF workflows in zhaoxuya520/reverse-skill.

• Architecture centers on six components: skill definition (SKILL.md), router matrix, domain references, evidence priorities, implicit routing logic, and re-routing safeguards.

• Evidence-first routing selects child skills only after concrete observations, using router-matrix.md for domain mapping.

• Natural-language directives replace procedural code, allowing AI-agent frameworks to interpret routing rules declaratively.

• Domain isolation and re-routing safety ensure sandbox assumptions remain consistent across complex, multi-domain investigations.

• Key files are located in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/ with references under references/.

Frequently Asked Questions

How does the CTF-Sandbox-Orchestrator differ from traditional workflow orchestrators?

Traditional orchestrators execute procedural code to route between tasks. The CTF-Sandbox-Orchestrator encodes routing logic in natural-language directives within SKILL.md that AI-agent frameworks interpret. This design prioritizes transparency and auditability over execution speed, making investigative decisions inspectable and modifiable without code changes.

Can child skills be invoked directly without going through the orchestrator?

No. The architecture explicitly prohibits direct child skill invocation. All skills prefixed with $competition-* are downstream-only and require the orchestrator to first establish sandbox assumptions and select the appropriate domain. This invariant is enforced by the routing directives in SKILL.md and validated by compliant AI-agent implementations.

What triggers a re-route in the CTF-Sandbox-Orchestrator?

Re-routing occurs when the dominant evidence source changes categories—for example, when investigation shifts from a web API endpoint to a binary crash, or from cryptographic patterns to cloud infrastructure. The "Re-Route Rules" in SKILL.md require returning control to the orchestrator top-level, which then re-evaluates router-matrix.md and loads the appropriate domain reference.

Why are reference files loaded selectively rather than all at once?

Minimal loading reduces memory footprint and maintains analyst focus. Each reference file (e.g., web-api.md, reverse-native.md) contains domain-specific ladders and pitfalls that would create noise if loaded simultaneously. By pulling only the matching reference after routing, the orchestrator keeps the active working set tightly scoped to the current investigative domain.

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