What Is the Structure of a Typical Skill Module in reverse-skill?

A typical skill module in reverse-skill is a self-contained directory under skills/ that implements a concrete workflow for a specific target, technique, or tool—containing entry documentation, operational contracts, automation scripts, and task-specific guidance.

The reverse-skill repository functions as a skill-router that directs security tasks to the most appropriate workflow. Each skill module follows a consistent internal structure, enabling both human operators and AI agents to navigate from routing decision to execution without ambiguity.

Anatomy of a Skill Module Structure

Every skill module in reverse-skill adheres to a standardized layout defined in skills/SKILL.md and enforced by the routing system in skills/MASTER-ROUTING.md. While specialized domains add their own artifacts, the foundational pattern remains uniform.

Required Core Components

• README.md – Entry point that declares the module's purpose, supported target types, and quick-start commands.
• routing-entry.md – Specific mapping of this skill into the global routing matrix (who should enter here, with what inputs).
• scope-contract.md – Operational boundaries defining what this skill handles and excludes.
• workitems/ – Templates for discrete tasks: reconnaissance, exploitation, reporting.

Automation Layer

Most modules include executable scripts under scripts/:

# Example: Initialize an APK reverse-engineering session

powershell -File skills/apk-reverse/scripts/init-session.ps1 -Target "suspicious-app.apk"

These scripts consume the ops contracts from skills/ops/ to ensure consistent workspace initialization, evidence handling, and timeline tracking.

Tool Integration Artifacts

• tool-index.md (local) – Subset of global skills/tool-index.md relevant to this domain.
• references/ – Curated links, cheat sheets, and external documentation.
• plugins/ or mcp/ – Model Context Protocol configurations for AI-assisted workflows (notably in ida-reverse/, radare2/).

Skill Module Examples by Domain

The repository demonstrates this structure across diverse security disciplines:

APK / Android Reverse (skills/apk-reverse/)

skills/apk-reverse/
├── README.md                 # Purpose: decompile, unpack, re-sign, Frida hook

├── routing-entry.md          # Trigger: file extension .apk, user intent "decompile"

├── scope-contract.md         # Limits: Android-only, no iOS binary analysis

├── scripts/
│   ├── decompile-apk.ps1     # apktool + jadx wrapper

│   ├── resign-apk.ps1        # Key management for modified APKs

│   └── frida-hook-template.js
├── workitems/
│   ├── recon-manifest.md     # Extract and analyze AndroidManifest.xml

│   ├── static-analysis.md    # Source code review checklist

│   └── dynamic-instrumentation.md
└── references/
    ├── smali-cheat-sheet.md
    └── frida-android-snippets.md

Mobile iOS Reverse (skills/mobile-reverse/)

Extends the base pattern with IPA-specific handling:

• Class-dump integration – Automated extraction of Objective-C headers.
• Hopper scripts – Batch decompilation and symbol recovery.
• Frida iOS templates – Jailbreak-required instrumentation patterns.

Binary / IDA Reverse (skills/ida-reverse/)

This module showcases MCP workflow integration:

# From skills/ida-reverse/mcp/ida_mcp_bridge.py

# Bridges IDA Pro's decompiler output to the skill-router's evidence pipeline

def export_function_graph(ea, output_path):
    """
    Generates JSON representation of IDA's function graph
    for downstream attack-chain analysis.
    """
    # Implementation consumes idautils, outputs structured evidence

Key differentiators:

• mcp/ subdirectory – Model Context Protocol servers that expose IDA functionality to AI agents.
• plugins/ – IDC/IDAPython scripts for automated annotation.
• decompilation-pipeline.md – Step-by-step guide from binary to readable pseudocode.

Radare2 Reverse (skills/radare2/)

CLI-centric variant with Bash-heavy automation:

# skills/radare2/scripts/r2-batch-analyze.sh

#!/bin/bash

# Batch analysis script referenced in routing matrix for headless environments

r2 -A -q -c 'aaa; afl; pdf @@ sym.*' "$1" > analysis.txt

JS / Frontend Reverse (skills/js-reverse/)

Specialized for encrypted/obfuscated browser-based logic:

• Capture workflows – Proxy configuration for traffic interception.
• Deobfuscation pipelines – AST manipulation using Babel or custom transforms.
• Reconstruction templates – Rebuilding minified code into maintainable structure.

The CTF-Sandbox Orchestrator: Module Aggregation

The CTF-Sandbox-Orchestrator/ directory demonstrates how individual skill modules compose into larger systems. It aggregates >40 sub-skills across:

• Cryptography challenges
• Web exploitation
• Reverse-engineering binaries
• Forensics

Each sub-skill maintains the standard module structure while the orchestrator adds:

• Competition-specific routing – Challenge category → appropriate skill module.
• Time-bound scope contracts – CTF-specific deadlines and flag submission hooks.
• Unified scoring integration – Evidence-to-points pipeline.

Operational Contracts: The Glue Between Modules

The skills/ops/ directory provides cross-module standardization:

Contract File	Purpose Across All Modules
scope-template.md	Defines engagement boundaries before any ACT step
evidence-pipeline.md	How findings propagate from skill execution to reporting
role-map.md	Human or AI agent responsibilities at each phase
timeline-template.md	Structured tracking of task progression
identity-definitions.md	Attribution and authentication requirements

When skills/scripts/case-init.ps1 creates a new workspace, it copies these templates into work/<case>/ops/, ensuring every skill module operates within consistent operational constraints.

Routing Integration: How Modules Are Selected

The routing system evaluates three inputs to select a skill module, as defined in skills/routing.md:

1. Target type – File format, platform, or system under analysis.
2. User intent – High-level goal (decompile, exploit, harden).
3. Available toolchain – Locally installed tools per skills/tool-index.md.

# skills/scripts/master-route.ps1 implements this logic

# Example execution path for APK analysis request:

# Input: "decompile this apk and look for hidden URLs"

# 1. Parse target type → .apk extension detected

# 2. Match intent "decompile" → routing matrix entry for apk-reverse

# 3. Verify tools → apktool, jadx present in tool-index.md

# Output: Entry path = skills/apk-reverse/README.md

Summary

A typical skill module in reverse-skill combines:

• Standardized entry points (README.md, routing-entry.md) for routing system integration.
• Operational contracts from skills/ops/ ensuring consistent scope and evidence handling.
• Automation scripts (PowerShell/Bash) that implement workflow steps.
• Domain-specific artifacts – tool configurations, reference materials, and AI/MLCP bridges where applicable.
• Structured workitems that decompose complex tasks into trackable units.

This architecture enables reverse-skill to function as a universal router across reverse-engineering, penetration testing, and CTF workflows while maintaining predictability and auditability.

Frequently Asked Questions

What defines the minimum viable skill module?

A minimum viable skill module requires README.md for purpose declaration, routing-entry.md for matrix integration, and at least one executable script or documented procedure. The skills/SKILL.md file defines this baseline, though production modules typically include full ops contract integration.

How does the routing system handle overlapping capabilities?

When multiple modules could satisfy a request, skills/routing.md specifies precedence rules: specificity wins (APK-reverse beats generic reverse-engineering for .apk files), followed by toolchain availability checks against skills/tool-index.md. The master-route.ps1 script logs its decision path for transparency.

Can skill modules depend on or invoke other modules?

Yes—complex workflows like attack-chain/ explicitly reference other modules. The dependency is declared in the module's routing-entry.md under upstream-requirements, and skills/scripts/ includes helpers for cross-module workspace sharing and evidence passing.

How are new skill modules validated before integration?

The RULES.md guardrail requires that any new module include: routing matrix entry, scope contract, and successful execution of skills/scripts/case-init.ps1 using the module's templates. The refresh-tool-index.sh script also verifies that declared tool dependencies resolve on the local system.

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