How reverse-skill Handles False Positives Using Keyword Exclusion Patterns

The reverse-skill routing engine mitigates false positives by evaluating an optional exclude regex pattern that cancels rule matches even when must or mustAll conditions succeed, ensuring precise skill selection.

reverse-skill determines the PRIMARY skill for a given task by scanning user-provided hints against keyword rules defined in the central configuration. The system employs a three-tier regex matching strategy—must, mustAll, and exclude—to route requests accurately while preventing incorrect skill activation through semantic guardrails.

The Three-Tier Filtering Architecture

Each routing rule in skills/config/routing.json contains three optional regex fields that work sequentially to qualify or disqualify candidate skills:

• must: A single regex that must match for the rule to be considered.
• mustAll: An array of regexes where all must match if must already succeeded.
• exclude: A regex that, when matched, cancels the rule even if must/mustAll conditions were satisfied.

This architecture allows generic patterns to coexist with specific exclusions, preventing broad matches from hijacking specialized routing contexts.

Implementation in the Routing Engine

The exclusion logic is implemented in skills/scripts/master-route.ps1 at lines 48-50:

# exclude：命中则本条规则不触发（防误伤，如 越狱/LLM 语境、域控/攻击链）

if ($hit -and $null -ne $kw.exclude -and $t -match $kw.exclude) { $hit = $false }

This conditional check evaluates the $kw.exclude pattern against the lower-cased hint string ($t) immediately after a successful must/mustAll match. If the exclusion pattern matches, the $hit flag is forced to $false, effectively discarding the rule from the scoring matrix.

Workflow: From Match to Exclusion

The routing engine processes each hint through a strict five-step validation pipeline:

1. Normalize the input: Convert the hint ($t) to lowercase for case-insensitive matching.
2. Iterate routes: For each route ID, loop through its keywords array.
3. Evaluate inclusion: Check must and mustAll conditions; set $hit = $true on success.
4. Apply exclusion guard: Test the optional exclude regex; if matched, reset $hit = $false.
5. Score survivors: Only rules that survive the exclusion filter contribute to the PRIMARY route scoring matrix.

This workflow ensures that exclusion patterns act as semantic circuit breakers, preventing false positives from influencing the final routing decision.

Real-World False Positive Scenarios

The exclude field provides critical guardrails against context misclassification in specialized security and reverse-engineering domains.

LLM Jailbreak vs. Mobile Reverse Engineering

When processing hints containing the word "jailbreak," the system must distinguish between LLM security testing and iOS mobile reverse engineering. Route R14 (LLM/Agent security) includes must: "jailbreak", while R2 (Mobile reverse) requires must: "jailbreak" combined with mustAll: ["ios|iphone|ipad|mobile|objection|ipa"].

However, if a user provides the hint "jailbreak Windows," it might incorrectly trigger the generic R0 rule. The R0 rule contains an extensive exclude pattern:

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

This exclusion prevents the general reverse-engineering route from firing on specialized contexts, forcing the router toward more appropriate specialized routes or rejecting the match entirely.

Domain Controller Enumeration vs. Attack Chains

Route R24 (Windows/Active Directory) targets domain controller operations with must: "域.?渗透|域控", but includes a critical exclusion:

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

A hint like "完整渗透域控" (full penetration domain controller) would otherwise match R24, but the exclude pattern removes this false positive. The router then steers the request toward R10 (Attack chain), where the broader full-pentest context belongs.

Scripting Language Collision

The generic R0 route defines must: "reverse|逆向" with an exclusion list that filters terms belonging to specialized routes like apk, js, ios, and mobile. When a hint contains "js reverse," the R3 (JS/frontend reverse) route matches via its specific patterns, while R0 is excluded to prevent double-counting and semantic collision.

Adding Custom Exclusion Patterns

To protect a new route from false positive triggers, add an exclude entry to the relevant rule in skills/config/routing.json:

{
  "must": "cloud",
  "exclude": "container|docker|k8s|escape",
  "note": "Prevent cloud-related hint from hijacking container-escape route"
}

The router now ignores hints containing "cloud" when they also include containerization terminology, ensuring the intended route wins the scoring matrix.

Key Files and Architecture

File	Role
skills/config/routing.json	Central definition of all routes, including must, mustAll, and exclude regexes.
skills/scripts/master-route.ps1	Core routing engine that loads the configuration and applies the exclusion filter.
skills/MASTER-ROUTING.md	Documentation of the routing process and single source of truth principles.
skills/scripts/verify-routing-coherence.ps1	Validation script ensuring the priority list matches the routes defined in the configuration.

Summary

• Three-tier matching: The system uses must, mustAll, and exclude regex fields to qualify routes with surgical precision.
• Guardrail implementation: The exclude pattern in master-route.ps1 (lines 48-50) acts as a circuit breaker to prevent false positive matches.
• Context preservation: Exclusion patterns distinguish between overlapping domains like LLM security vs. mobile reverse engineering, or domain controller operations vs. full attack chains.
• Configuration-driven: All exclusion logic is defined in skills/config/routing.json, allowing fine-grained tuning without modifying the routing engine.

Frequently Asked Questions

How does the exclude field differ from mustAll in reverse-skill routing?

The mustAll field requires additional positive matches to qualify a rule, while exclude acts as a negative filter that disqualifies the rule regardless of previous matches. A rule can satisfy all must and mustAll conditions but still be rejected if the hint matches the exclude regex.

Can a routing rule contain both mustAll and exclude patterns simultaneously?

Yes, according to the routing.json schema, a rule can contain must, mustAll, and exclude fields together. The engine evaluates them sequentially: first must, then mustAll, and finally exclude. This allows for complex logic where a rule requires multiple positive matches but must also avoid specific negative contexts.

What happens if the exclude regex pattern is malformed in routing.json?

As implemented in master-route.ps1, if the exclude field is not null, the script executes $t -match $kw.exclude using PowerShell's regex operator. A malformed pattern would likely throw a runtime regex parsing error or fail to match, potentially breaking the routing logic for that specific rule. The verify-routing-coherence.ps1 script should be used to validate patterns before deployment.

Where should I add new exclusion patterns to prevent false positives?

Add exclusion patterns directly to the specific route definition in skills/config/routing.json. Identify the rule that is being falsely triggered and append the ambiguous terms to its exclude field. After modification, run verify-routing-coherence.ps1 to ensure the configuration remains valid and consistent with the routing priority list.

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