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

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: 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). 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):

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 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:

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.

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 rather than failing silently.
• The architecture is documented in 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. 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 procedures.

Where is the routing logic implemented in the codebase?

The core logic resides in skills/routing.md, which defines the three-axis tables and recovery protocol. Entry-point selection occurs in skills/MASTER-ROUTING.md, while the architectural flow is visualized in docs/ARCHITECTURE.md (line 43). The executable implementation appears in scripts/master-route.ps1.

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