# How reverse-skill Handles False Positives Using Keyword Exclusion Patterns

> Discover how reverse-skill uses keyword exclusion patterns to effectively handle false positives, ensuring accurate rule matches and precise skill selection. Learn more!

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

---

**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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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:

```powershell

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

```json
"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:

```json
"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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json):

```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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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`](https://github.com/zhaoxuya520/reverse-skill/blob/main/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.