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

> Understand the typical skill module structure in reverse-skill. Learn about its components: entry documentation, operational contracts, automation scripts, and task-specific guidance.

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

---

**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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/SKILL.md) and enforced by the routing system in [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md). While specialized domains add their own artifacts, the foundational pattern remains uniform.

### Required Core Components

- **[`README.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/README.md)** – Entry point that declares the module's purpose, supported target types, and quick-start commands.
- **[`routing-entry.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/routing-entry.md)** – Specific mapping of this skill into the global routing matrix (who should enter here, with what inputs).
- **[`scope-contract.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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/`:

```powershell

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/tool-index.md)** (local) – Subset of global [`skills/tool-index.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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/`)

```bash
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**:

```python

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/decompilation-pipeline.md)** – Step-by-step guide from binary to readable pseudocode.

### Radare2 Reverse (`skills/radare2/`)

CLI-centric variant with Bash-heavy automation:

```bash

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/scope-template.md) | Defines engagement boundaries before any ACT step |
| [`evidence-pipeline.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/evidence-pipeline.md) | How findings propagate from skill execution to reporting |
| [`role-map.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/role-map.md) | Human or AI agent responsibilities at each phase |
| [`timeline-template.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/timeline-template.md) | Structured tracking of task progression |
| [`identity-definitions.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/tool-index.md).

```powershell

# 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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/README.md), [`routing-entry.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/README.md) for purpose declaration, [`routing-entry.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/routing-entry.md) for matrix integration, and at least one executable script or documented procedure. The [`skills/SKILL.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/refresh-tool-index.sh) script also verifies that declared tool dependencies resolve on the local system.