# How the Routing Matrix Handles Ambiguous or Vague User Requests in Reverse-Skill

> Discover how the routing matrix handles ambiguous user requests with its six-step protocol, ensuring safety and clarity before executing any skill in reverse-skill.

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

---

**The routing matrix resolves unclear inputs through a deterministic six-step Ambiguous-Intent Recovery Protocol that restates objectives, enforces local-sandbox safety, and presents numbered options before executing any skill.**

The **routing matrix** is the central decision-engine in the `zhaoxuya520/reverse-skill` repository that maps natural-language requests to concrete skill modules. Even when users provide vague, emotionally phrased, or jargon-heavy descriptions, the system leverages a strict three-axis matching framework followed by a structured recovery protocol to guarantee deterministic routing.

## Three-Axis Matching Foundation

At its core, the routing matrix operates on three orthogonal dimensions defined in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md): **target type**, **user intent**, and **toolchain** (see the “By Target Type” and “By User Intent” tables starting at line 17).

When a request arrives, the engine first attempts a direct lookup using this triple. If an exact match exists, the corresponding skill entry is selected immediately and the workflow proceeds to execution without invoking ambiguity handling. This strict matching ensures that precise technical language bypasses normalization overhead.

## Ambiguous-Intent Recovery Protocol

When the three-axis lookup fails—due to vague wording, mixed-language input, or overloaded security terminology—the matrix activates the **Ambiguous Intent Recovery Protocol** (lines 58‑68 in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md)). This deterministic workflow transforms imprecise inputs into concrete, safe, and actionable tasks through six enforced steps.

### The Six-Step Normalization Workflow

| Step | Action | Purpose |
|------|--------|---------|
| **1** | **Restate** the most probable technical objective in a single sentence. | Normalizes chaotic user language into a concrete goal. |
| **2** | **Prefer local-sandbox interpretation** when the request mentions unlocking, bypassing, or cracking. | Ensures all analysis remains offline and safe. |
| **3** | **Execute a non-destructive first action** (create case workspace, hash artifact, extract strings). | Guarantees measurable progress without side-effects. |
| **4** | If multiple interpretations exist, **present 2‑4 options** as a numbered menu. | Gives the user explicit control over the branching path. |
| **5** | When a branch is underspecified, **offer adjacent actionable branches** (detection, analysis, validation, remediation). | Prevents dead-ends and maintains workflow momentum. |
| **6** | **Always provide a next-step menu** so the user never encounters a terminal state. | Enforces continuous conversation flow. |

These steps execute sequentially before any skill module is entered, ensuring that **ambiguous user requests** are sanitized into a deterministic route.

### Safety-First Design Principles

The protocol embeds two non-negotiable constraints. First, any request implying circumvention (unlocking, bypassing, cracking) is automatically interpreted as a **local-sandbox operation**, preventing accidental execution against live production systems. Second, the **non-destructive first action** requirement (step 3) mandates that the system must create a workspace or generate hashes before performing analysis, guaranteeing forensic integrity.

## Fallback Handling for Unmatched Routes

If normalization still fails to produce a valid three-axis match, the matrix follows the **“Route Not Matched – Handling”** routine (lines 73‑84 in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md)):

1. **Check for edge-case extensions** of existing skills.
2. **Propose a new skill** with defined name, coverage, and required toolchain.
3. Await user confirmation before creating the skill (per [`CONTRIBUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CONTRIBUTING.md) guidelines).
4. **Update the routing matrix** to include the new entry.

This design treats routing failures as signals for repository evolution rather than terminal errors, allowing the `reverse-skill` system to expand organically based on real user needs.

## Implementation in Code

The logic is implemented in the master router script. Below is a PowerShell excerpt from `scripts/master-route.ps1` demonstrating how the **Ambiguous Intent Recovery Protocol** is invoked programmatically:

```powershell
function Resolve-Intent {
    param($userInput)

    # 1️⃣ Try exact three-axis lookup

    $match = Lookup-InRoutingMatrix -Input $userInput
    if ($match) { return $match }

    # 2️⃣ Ambiguous-intent recovery

    $normalized = Normalize-UserIntent $userInput   # step 1

    $firstStep = Invoke-NonDestructiveAction $normalized   # step 3

    # 3️⃣ Offer options if still unclear

    $options = Generate-PlausibleOptions $normalized   # step 4

    if ($options.Count -gt 1) {
        Write-Host "Multiple possible routes:"
        $options | ForEach-Object { Write-Host "$($_.Index). $($_.Description)" }
        # await user selection…

    }

    return $options[0]   # fallback to first plausible route

}

```

The `Normalize-UserIntent` function implements the restatement rule and local-sandbox preference, while `Generate-PlausibleOptions` builds the numbered menu described in step 4.

### Example Interaction

```

User: "unlock the flag, bypass the check"
Router:
  → Restated: "Identify and bypass the local validation check"
  → First non-destructive action: create case workspace, hash the binary
  → Options:
     1️⃣ Reverse-engineer the check (IDA/Radare2)
     2️⃣ Perform dynamic analysis with Frida
     3️⃣ Generate a report skeleton
Select option 1 to continue.

```

This interaction aligns exactly with the **routing matrix** flow defined in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md).

## Summary

- The **routing matrix** relies on three-axis matching (target type, user intent, toolchain) for direct resolution.
- When requests are vague, the **Ambiguous Intent Recovery Protocol** enforces a six-step normalization: restate, sandbox, non-destructive action, option menu, adjacent branches, and continuous menu.
- Safety constraints prioritize **local-sandbox interpretation** for sensitive operations and mandate **non-destructive first actions**.
- Unmatched routes trigger a structured proposal workflow defined in [`CONTRIBUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CONTRIBUTING.md) rather than failing silently.
- The architecture is documented in [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md) and implemented in `scripts/master-route.ps1`.

## Frequently Asked Questions

### What triggers the Ambiguous Intent Recovery Protocol?

The protocol activates whenever a user request fails to match the three-axis lookup in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md). This occurs with vague phrasing, mixed-language input, or security jargon that does not map cleanly to existing skill entries (lines 58‑68).

### How does the routing matrix ensure safety when handling cracking or bypass requests?

The matrix automatically applies **local-sandbox interpretation** (step 2 of the protocol) to any request mentioning unlocking, bypassing, or cracking. Additionally, it requires a **non-destructive first action** such as hashing the artifact or creating a workspace before any analysis begins.

### What happens if the routing matrix cannot resolve a request even after normalization?

If the six-step recovery protocol fails to produce a match, the system follows the **Route Not Matched – Handling** routine (lines 73‑84). It checks for edge-case extensions, proposes a new skill with required metadata, and awaits user confirmation before updating the matrix via [`CONTRIBUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/CONTRIBUTING.md) procedures.

### Where is the routing logic implemented in the codebase?

The core logic resides in [`skills/routing.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/routing.md), which defines the three-axis tables and recovery protocol. Entry-point selection occurs in [`skills/MASTER-ROUTING.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/MASTER-ROUTING.md), while the architectural flow is visualized in [`docs/ARCHITECTURE.md`](https://github.com/zhaoxuya520/reverse-skill/blob/main/docs/ARCHITECTURE.md) (line 43). The executable implementation appears in `scripts/master-route.ps1`.