How the Exclude Clause Prevents False Positives in Reverse-Skill Routing

The exclude clause acts as a negative filter that discards routing matches when user input contains specific unwanted keywords, ensuring broad must patterns do not trigger incorrect skill modules in the reverse-skill framework.

The zhaoxuya520/reverse-skill project relies on a deterministic routing engine defined in skills/config/routing.json to map user intents to specialized skill modules. By combining positive regex patterns (must, mustAll) with negative exclusions, the system achieves high-precision intent classification without routing ambiguity.

Understanding the Two-Step Routing Logic

The routing engine applies a strict two-phase validation process for every incoming phrase. First, it checks whether the input satisfies the positive matching criteria; second, it applies exclusion guards to eliminate false positives.

In skills/config/routing.json, each route entry defines:

• must: A regex pattern that triggers a potential match
• mustAll (optional): An array of regexes where all must match
• exclude (optional): A regex pattern that invalidates the match if found

The engine evaluates these in sequence:

1. Positive scoring — The phrase must match at least one must pattern (and all mustAll patterns if present)
2. Exclusion guard — If the phrase matches any exclude pattern defined for that route, the match is discarded and the engine proceeds to the next candidate

This design allows generic terms like "jailbreak" or "reverse" to exist in multiple routes while ensuring only the contextually appropriate skill receives the task.

Real-World Examples from the Routing Table

The following examples from skills/config/routing.json demonstrate how exclude clauses resolve ambiguity between overlapping domains.

Mobile Reverse Engineering (R2): Distinguishing iOS Jailbreak from LLM Contexts

Route R2 handles iOS jailbreak queries but must avoid capturing LLM-related jailbreak discussions. According to lines 24-27 in routing.json#L24-L27:

{
  "must": "jailbreak",
  "mustAll": ["ios|iphone|ipad|mobile|objection|ipa"],
  "exclude": "模型|提示词|llm|prompt|jailbreak|garak|红队.?ai|ai.?红队"
}

Without the exclude clause, the word "jailbreak" alone would match both iOS security research and AI safety testing contexts. The exclusion pattern removes mentions of model testing, prompt engineering, and red-team AI activities, ensuring the route only fires for genuine mobile device jailbreak intents.

Windows Active Directory (R24): Separating AD Tasks from Full Attack Chains

Route R24 matches Active Directory penetration testing keywords but must exclude complete penetration-testing scenarios that belong to the Attack-Chain skill (R10). Lines 90-92 in routing.json#L90-L92 define:

{
  "must": "域.?渗透|域控",
  "exclude": "完整.?渗透|从外网|打到域控|attack.?chain|full.?pentest"
}

This prevents generic queries about domain controllers ("域控") from being mis-routed to the AD skill when the surrounding context indicates a full-scale attack chain methodology.

CTF Sandbox Orchestrator (R41): Filtering Binary Exploitation Keywords

Route R41 captures general Capture The Flag (CTF) competition mentions but excludes binary exploitation terminology that belongs to the Pwn Chain skill (R17). Lines 11-12 in routing.json#L11-L12 specify:

{
  "must": "\\bctf\\b|awd|靶场|比赛.?题",
  "exclude": "pwn|rop|栈溢出|堆溢出|ret2"
}

The exclude pattern ensures that discussions about "pwn" challenges, ROP chains, or stack overflows route to the specialized binary exploitation skill rather than the general CTF orchestrator.

General Reverse Engineering Catch-All (R0): Prioritizing Specificity

Route R0 serves as the fallback for generic reverse-engineering terms but excludes domain-specific keywords that have dedicated routes. Lines 19-21 in routing.json#L19-L21 demonstrate extensive exclusions:

{
  "must": "reverse|逆向",
  "exclude": "apk|js.?reverse|ios|mobile|\\.net|firmware|malware|安卓|固件|恶意|protocol|ghidra|extension|macos|mach|golang|rust|工控|厚客户端|取证|协议|扩展"
}

Any request containing generic "reverse" terms alongside specific technologies (e.g., "apk reverse", "firmware reverse") is filtered out, allowing more specific routes (R1, R3, etc.) to take precedence while maintaining R0 as a valid fallback for truly generic queries.

Implementation Details in routing.json

The routing logic is implemented as a series of regex evaluations against user input. The exclude clause functions as a final guard clause in the matching algorithm.

Consider the pseudo-code implementation found in the routing engine (skills/scripts/master-route.sh and its PowerShell counterpart):

def matches_route(phrase, route):
    # Phase 1: Positive matching

    if not any(re.search(pat, phrase) for pat in route['must']):
        return False
    
    # Phase 2: All-required matching (optional)

    if 'mustAll' in route and not all(re.search(pat, phrase) for pat in route['mustAll']):
        return False
    
    # Phase 3: Exclusion guard

    if any(re.search(pat, phrase) for pat in route.get('exclude', [])):
        return False
    
    return True

Only when matches_route returns True does the router consider the route as a candidate. This three-phase validation ensures that broad must patterns can coexist with precise contextual requirements.

The routing configuration maintains a single source of truth principle documented in [RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md), while verify-routing-coherence.ps1 validates that exclusions do not create logical contradictions in the routing table.

Summary

• The exclude clause functions as a negative filter that removes false-positive matches after initial must pattern detection
• Two-step validation applies positive regex matching first, followed by exclusion checks to ensure contextual accuracy
• Specificity prioritization allows generic routes like R0 to exist alongside specialized routes without collision, as exclusions prevent generic routes from capturing domain-specific queries
• Real-world separation includes distinguishing iOS jailbreak from LLM contexts (R2), AD tasks from full attack chains (R24), and CTF general queries from binary exploitation (R41)
• Implementation location resides in skills/config/routing.json, validated by verify-routing-coherence.ps1 to maintain routing consistency

Frequently Asked Questions

What file contains the exclude clause definitions in reverse-skill?

The exclude clauses are defined in [skills/config/routing.json](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json), which serves as the central routing table for the entire framework. This file contains the must, mustAll, and exclude regex patterns that determine how user intents map to specific skill modules.

How does the exclude clause interact with must and mustAll patterns?

The routing engine enforces a strict evaluation order: it first checks if the input matches any must pattern (and all mustAll patterns if present), then applies the exclude clause as a final filter. If the input matches an exclusion pattern, the route is discarded entirely, regardless of how well it matched the positive criteria. This ensures that negative constraints always override broad positive matches.

Can a route have multiple exclude patterns or is it limited to one?

While the examples show single regex strings for exclude, the routing engine treats these as standard regular expressions that can contain alternation operators (|) to specify multiple exclusion terms. For instance, the R2 route excludes "模型|提示词|llm|prompt" within a single pattern string, effectively listing multiple forbidden keywords without requiring an array structure.

How is routing coherence validated to prevent exclude clause conflicts?

The repository includes skills/scripts/verify-routing-coherence.ps1, which analyzes the routing table to detect logical contradictions, unreachable routes, or inconsistent exclusion patterns. This validation script ensures that the exclude clauses do not inadvertently block all valid inputs for a route or create ambiguous routing scenarios where no skill can handle a specific query.

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