MASTER-ROUTING.md vs routing.md: Understanding the Fast Ladder and Full Matrix Routing Difference

In the zhaoxuya520/reverse-skill repository, MASTER-ROUTING.md provides a deterministic fast ladder for primary skill selection, while routing.md serves as a comprehensive three-axis disambiguation matrix for ambiguous cases.

The routing architecture in this reverse-engineering skill repository employs two complementary documents to determine which module handles a given task. Understanding the difference between the fast ladder (MASTER-ROUTING.md) and the full matrix (routing.md) is essential for both automated routing scripts and manual skill selection workflows.

MASTER-ROUTING.md: The Fast Ladder Primary Path

The skills/MASTER-ROUTING.md file implements a minimal, deterministic lookup mechanism designed for speed and automation.

Purpose and Execution Contract

This document defines the primary routing path that every request must traverse before analysis begins. It consumes the ordered priority list from config/routing.json (entries R0 through R41) and executes a short execution contract. The scope is intentionally minimal—only the priority list and execution rules—making it ideal for machine parsing by the routing scripts.

When scripts/master-route.sh (Linux/macOS/Kali) or scripts/master-route.ps1 (Windows) invokes the fast ladder, the system performs a direct lookup against the priority ordering. If a match is found, the selected skill's SKILL.md opens immediately without further disambiguation.

Automated Fast-Track Implementation

The fast ladder operates through the following command interfaces:

# Linux/macOS/Kali - Direct primary routing

bash skills/scripts/master-route.sh --hint "Analyze this Android APK"

# Windows - Direct primary routing

powershell -File skills\scripts\master-route.ps1 -Hint "Reverse a JavaScript payload"

These scripts read config/routing.json, match the highest-priority rule, and return a single PRIMARY path such as apk-reverse/, js-reverse/, or ctf-sandbox/. The flow follows: RULES.md → MASTER-ROUTING.md → PRIMARY SKILL.md.

routing.md: The Full Matrix Disambiguation System

When the fast ladder encounters ambiguity, the system falls back to skills/routing.md, which functions as a disambiguation matrix rather than a deterministic lookup.

Three-Axis Analysis Framework

Unlike the one-dimensional priority list, the full matrix presents three intersecting axes: target type ↔ user intent ↔ toolchain. This structure addresses scenarios where user phrasing maps to multiple skills, keywords overlap between categories, or the primary lookup lacks a specific entry.

The document contains detailed tables for each axis, normalization rules, and explicit sections covering "by target type," "by user intent," and "by toolchain." When the fast lookup cannot resolve a clear primary skill—such as with mixed intent or missing priority entries—the matrix guides analysts to correct skills or suggests creating new ones.

Fallback Execution Flow

The full matrix occupies the secondary position in the routing hierarchy: RULES.md → MASTER-ROUTING.md → (if ambiguous) routing.md → PRIMARY SKILL.md.

Consider this ambiguity resolution example:

# Script detects ambiguity in OLLVM deobfuscation request

bash skills/scripts/master-route.sh --hint "I need to deobfuscate OLLVM"

# Falls back to routing.md advice

# Suggests: reverse-engineering/references/ollvm-deobfuscation.md

For manual consultation, analysts can query the matrix directly:

# Open matrix for manual lookup

cat skills/routing.md | less

# Programmatically extract candidates by skill type

grep -i "js-reverse" -n skills/routing.md

Key Differences Between Fast Ladder and Full Matrix

These routing documents differ across five critical dimensions:

• Scope: MASTER-ROUTING.md contains only the priority list (R0…R41) and execution contract, while routing.md includes comprehensive tables, normalization rules, and three-axis views.
• Output: The fast ladder returns exactly one PRIMARY path; the matrix may return multiple candidates, fallback suggestions, or guidance on combining skills through Path Crossing.
• Automation: master-route.sh and master-route.ps1 read the fast ladder automatically, whereas the matrix requires manual consultation or explicit fallback triggers.
• Maintenance: Update config/routing.json and MASTER-ROUTING.md for priority changes; update routing.md manually when adding new skills or refining axis definitions.
• Dependencies: The fast ladder references ops/scope-contract.md as a mandatory pre-ACT gate and expects tools listed in tool-index.md to be available.

Summary

• MASTER-ROUTING.md provides a deterministic, automated fast ladder using the R0…R41 priority list from config/routing.json for unambiguous primary skill selection.
• routing.md offers a comprehensive full matrix with three-axis disambiguation (target type, user intent, toolchain) for handling ambiguous or complex routing scenarios.
• The routing flow prioritizes the fast path via scripts/master-route.sh or master-route.ps1, falling back to the matrix only when necessary.
• Both documents reference supporting files including ops/scope-contract.md and tool-index.md to ensure proper execution context.

Frequently Asked Questions

When should I use routing.md instead of MASTER-ROUTING.md?

Consult routing.md when master-route.sh returns ambiguous results, when your task involves overlapping skill domains (such as mobile analysis intersecting with cryptography), or when you need to understand the relationship between target types, user intents, and toolchains. The fast ladder handles 80% of standard queries automatically; reserve the full matrix for edge cases and complex multi-skill scenarios.

How does the master-route.sh script decide between fast ladder and full matrix?

The script first attempts to match the user's hint against the ordered priority list in config/routing.json as defined in MASTER-ROUTING.md. If the match confidence falls below threshold—detected through keyword collisions, missing entries, or mixed intent indicators—the script automatically consults the disambiguation logic in routing.md before returning a final recommendation.

What happens if both routing documents return conflicting results?

The repository architecture treats MASTER-ROUTING.md as authoritative for primary selection. The full matrix serves an advisory role for disambiguation. If conflicts arise during automated routing, the system logs the ambiguity and defaults to the primary path from the fast ladder while flagging the alternate suggestion from routing.md for manual review.

How do I update the routing priority in the fast ladder?

Modify config/routing.json to adjust the R0 through R41 priority ordering, then update the execution contract in skills/MASTER-ROUTING.md to reflect any changes to the routing logic. The skills/routing.md file requires separate manual updates to its three-axis tables when introducing new skill categories that affect the disambiguation matrix.

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