How the CTF-Sandbox-Orchestrator Manages 40+ Sub-Skills in the reverse-skill Repository

The CTF-Sandbox-Orchestrator acts as a single master skill that dynamically routes challenges to over 40 specialized sub-skills based on dominant runtime evidence, using a router matrix and placeholder-based registry system.

The reverse-skill repository implements a hierarchical skill architecture for CTF and security competitions. At its core sits the CTF-Sandbox-Orchestrator, which eliminates manual skill selection by automatically dispatching tasks to domain-specific modules. This article examines the orchestrator's routing engine, sub-skill registry, and evidence-first workflow.

Central Orchestration Architecture

The orchestrator serves as the default entrypoint for every competition category in the repository. Its definition resides in CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md, where it assumes all presented artifacts belong to a unified sandbox environment.

Upon activation, the orchestrator constructs a minimal node map representing the sandbox topology:

host → proxy → process/container → persistence layer → worker

This abstraction allows the orchestrator to treat diverse challenge types—web exploits, reverse engineering, DFIR, crypto, mobile, AI agents, cloud containers, Active Directory, Windows hosts, and identity systems—through a consistent operational model.

The Router Matrix Decision Engine

Rather than prompting users to select child skills, the orchestrator consults the Router Matrix at CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md. This file encodes three core routing rules:

• Default Rule: Remain in sandbox mode until decisive evidence narrows the problem space
• Stay in Sandbox: Applied when tasks remain ambiguous across domains or involve multiple surfaces without a clear dominant blocker
• Route by Dominant Surface: Select the child skill whose $competition-* placeholder matches the primary evidence type

The matrix maps over 40 placeholders to concrete directories. Each placeholder follows the pattern $competition-<name> and corresponds to a subdirectory under CTF-Sandbox-Orchestrator/.

Sub-Skill Registry and Placeholder System

The master SKILL.md (lines 69-110) maintains a hard-coded list mapping all placeholders to their directories. This registry includes:

Placeholder	Target Directory
$competition-web-runtime	competition-web-runtime/
$competition-reverse-pwn	competition-reverse-pwn/
$competition-crypto-mobile	competition-crypto-mobile/
$competition-identity-windows	competition-identity-windows/
$competition-agent-cloud	competition-agent-cloud/
(continues for 40+ entries)

Each sub-skill operates as downstream-only—only the orchestrator can implicitly load them. This design prevents accidental domain jumps and enforces a consistent entry model across all competition workflows.

Dynamic Loading Workflow in Practice

The orchestrator executes a five-step evidence-driven pipeline:

1. Detect dominant evidence — Examines the first observable artifact (HTTP request, binary, JWT claim, etc.)
2. Select narrowest child skill — Resolves the matching $competition-* placeholder via router matrix rules
3. Load child skill — Internally imports the sub-skill's SKILL.md and reference files
4. Execute child workflow — Sub-skill runs its playbook while orchestrator monitors for context changes
5. Re-route if needed — Returns to sandbox level when dominant evidence no longer matches current skill

The router matrix specifies explicit Re-Route Rules for handling situations where a challenge's nature shifts mid-analysis—common in multi-stage CTF problems.

Evidence-First Philosophy

Both orchestrator and sub-skills prioritize live runtime behavior as the highest evidence tier. Static sources—source code, comments, documentation—serve only as fallback references. This ensures all routing decisions ground in observable, reproducible data rather than assumptions.

Reference files supporting this approach include:

• web-api.md — Web runtime and API analysis patterns
• reverse-native.md — Binary triage and exploit primitive identification
• crypto-mobile.md — Encoding chains, cryptographic boundaries, steganography
• agent-cloud.md — AI agent behavior, cloud infrastructure, container forensics
• identity-windows.md — Windows host artifacts and identity system traces

Extensibility for New Competition Domains

Adding a sub-skill requires three steps:

1. Create CTF-Sandbox-Orchestrator/competition-<name>/ with SKILL.md and reference files
2. Append $competition-<name> to the placeholder list in the master SKILL.md
3. Update router-matrix.md with domain-specific routing rules

Because the orchestrator evaluates the matrix at runtime, new sub-skills become immediately available without modifying higher-level code.

Code Examples: Routing and Loading

# Simplified routing logic from master SKILL.md

if dominant_surface == "web runtime":
    child = "$competition-web-runtime"
elif dominant_surface == "reverse pwn":
    child = "$competition-reverse-pwn"
elif dominant_surface == "crypto mobile":
    child = "$competition-crypto-mobile"

# ... 40+ cases ...

load_child_skill(child)  # Internal import of child SKILL.md

# Placeholder registry excerpt from SKILL.md lines 69-110

- $competition-web-runtime    -> competition-web-runtime/
- $competition-reverse-pwn    -> competition-reverse-pwn/
- $competition-crypto-mobile  -> competition-crypto-mobile/
- $competition-identity-windows -> competition-identity-windows/
- $competition-agent-cloud     -> competition-agent-cloud/

# (total >40 entries)

### Route By Dominant Surface (router-matrix.md)

| Evidence Pattern | Target Placeholder |
|------------------|-------------------|
| General site, API, auth, session | $competition-web-runtime |
| Binary triage, exploit primitives | $competition-reverse-pwn |
| Encoding chain, crypto boundary | $competition-crypto-mobile |
| AI agent behavior, cloud runtime | $competition-agent-cloud |
| Windows host artifacts, identity | $competition-identity-windows |

Key Implementation Files

Path	Purpose
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/SKILL.md	Master orchestrator definition and placeholder registry
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/router-matrix.md	Decision rules for evidence-to-skill mapping
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/web-api.md	Web and API challenge reference
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/reverse-native.md	Native binary and pwn reference
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/crypto-mobile.md	Cryptography and mobile reference
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/agent-cloud.md	AI agent and cloud reference
CTF-Sandbox-Orchestrator/ctf-sandbox-orchestrator/references/identity-windows.md	Identity and Windows host reference
CTF-Sandbox-Orchestrator/competition-*/SKILL.md	Individual sub-skill implementations (40+ files)

Summary

• The CTF-Sandbox-Orchestrator provides a unified entrypoint for all competition challenge types in reverse-skill
• Router matrix rules eliminate manual skill selection by matching dominant evidence to $competition-* placeholders
• Hard-coded registry in SKILL.md lines 69-110 tracks over 40 downstream-only sub-skills
• Five-step workflow detects evidence, selects skills, loads modules, executes playbooks, and re-routes when context changes
• Evidence-first priority ensures routing decisions rely on live runtime behavior rather than static assumptions
• Three-step extension process enables rapid addition of new competition domains without architecture changes

Frequently Asked Questions

How does the orchestrator decide which sub-skill to activate?

The orchestrator examines the first observable artifact in a challenge—such as an HTTP request, binary file, or JWT claim—and matches it against the Router Matrix in router-matrix.md. The matrix maps dominant evidence patterns to specific $competition-* placeholders. When a clear dominant surface emerges, the orchestrator resolves the placeholder to its corresponding directory and loads that sub-skill's SKILL.md.

Can users manually invoke a specific sub-skill instead of using automatic routing?

No. The sub-skills are designed as downstream-only components. Only the master orchestrator can implicitly load them through its internal load_child_skill() mechanism. This restriction prevents users from accidentally jumping between domains and maintains consistent workflow assumptions about the sandbox environment.

What happens if a challenge involves multiple domains or changes nature mid-analysis?

The orchestrator applies Re-Route Rules defined in the router matrix. If the current sub-skill stops matching the dominant blocker, execution returns to the sandbox level. The orchestrator then re-evaluates available evidence and may select a different sub-skill. This handles multi-stage CTF problems where initial web exploitation leads to binary reverse engineering, for example.

How many sub-skills does the current implementation support?

The repository maintains over 40 distinct sub-skills, each registered via a $competition-* placeholder in the master SKILL.md (lines 69-110). The placeholder list includes domains such as web-runtime, reverse-pwn, crypto-mobile, agent-cloud, identity-windows, and numerous others covering the full spectrum of CTF competition categories.

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