Understanding the `must` and `exclude` Parameters in reverse-skill Routing Rules

The must and exclude parameters in reverse-skill are regex-based filters that determine routing eligibility: must requires a pattern to exist in the user prompt, while exclude vetoes the match if specific terms appear, enabling precise request classification.

The reverse-skill repository implements a priority-based routing system that directs incoming requests to specialized skill handlers using a single JSON configuration file. These two parameters form the primary mechanism for defining route boundaries and preventing classification conflicts between overlapping domains.

How must and exclude Control Route Matching

Each route in skills/config/routing.json contains a keywords array where individual rules specify match conditions. The router evaluates these rules sequentially to determine which skill should handle a given request.

The must Parameter

The must field contains a case-insensitive regular expression that must match the user prompt for the rule to activate. If this pattern is not found, the router immediately rejects the rule and proceeds to the next candidate.

According to the source configuration in skills/config/routing.json, this parameter typically anchors core domain concepts. For example, route R2 (Mobile reverse engineering) uses "must": "越狱" to identify iOS jailbreaking requests, while R24 (Windows/AD) employs a complex pattern matching Active Directory tools like bloodhound, kerberoast, and mimikatz at lines 90-92.

The exclude Parameter

The exclude field defines a veto pattern—a regular expression that, if matched, disqualifies the rule even when must succeeds. This prevents false positives where domain terminology overlaps.

In the R2 configuration at lines 24-27, the rule excludes terms like 模型, prompt, and jailbreak to ensure that LLM-related jailbreak discussions route to the appropriate AI safety skill (R14) rather than mobile reverse engineering. Similarly, R24 excludes 完整.?渗透 and 打到域控 to distinguish comprehensive penetration tests from specific Active Directory attacks.

Combined Logic Flow

A rule satisfies matching criteria only when:

1. The must regex finds a match in the prompt
2. The exclude regex (if present) finds no matches

This boolean AND relationship provides fine-grained control without requiring complex single-regex constructions.

Routing Configuration Structure

The authoritative routing definitions reside in skills/config/routing.json. Each route object contains:

• Route ID: Numeric identifier (R0, R2, R24, etc.)
• keywords: Array of rule objects containing must, exclude, and optional fields
• mustAll: Optional array requiring all listed patterns to match simultaneously
• note: Documentation string explaining the routing logic

The fallback route R0 (General reverse engineering) at lines 218-221 demonstrates defensive exclusion, listing extensive excluded terms (apk, ios, malware, protocol) to defer to more specialized routes when specific domain indicators appear.

Concrete Implementation Examples

Example 1: Mobile Reverse Engineering (R2)

Located at lines 24-27 in skills/config/routing.json:

{
  "must": "越狱",
  "exclude": "模型|提示词|llm|prompt|jailbreak|garak|红队.?ai|ai.?红队",
  "note": "越狱 裸词分给 iOS 侧；LLM/模型上下文归 R14"
}

This routes iOS jailbreak queries to mobile specialists while diverting AI safety discussions to the appropriate handler via exclusion patterns.

Example 2: Windows Active Directory (R24)

Found at lines 90-92:

{
  "must": "active.?directory|\\bad\\b.?cs|bloodhound|kerberoast|as-?rep|certipy|ntlm.?relay|dc.?sync|kerberos.?攻击|ad.?证书|impacket|mimikatz|secretsdump",
  "exclude": "完整.?渗透|从外网|打到域控|attack.?chain|full.?pentest",
  "note": "完整渗透/打到域控 归 R10 攻击链"
}

This captures AD-specific tooling while excluding comprehensive penetration test scenarios that belong to the attack chain route (R10).

Example 3: CTF Sandbox Orchestrator (R41)

At lines 111-112:

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

Routes generic CTF infrastructure requests while excluding binary exploitation terms that should trigger specialized pwn-chain skills.

Evaluation Logic Implementation

The router implements the matching logic using case-insensitive regex searches. The following Python-style pseudocode illustrates the evaluation flow as implemented in the validation scripts:

import re

def matches_rule(prompt: str, rule: dict) -> bool:
    # 1. must: at least one match required

    if not re.search(rule["must"], prompt, flags=re.I):
        return False
    
    # 2. exclude: must NOT match

    if "exclude" in rule and re.search(rule["exclude"], prompt, flags=re.I):
        return False
    
    # 3. mustAll: every pattern must be present (optional)

    if "mustAll" in rule:
        for pattern in rule["mustAll"]:
            if not re.search(pattern, prompt, flags=re.I):
                return False
    
    return True

# Example usage with R2 rule

r2_rule = {
    "must": "越狱",
    "exclude": "模型|提示词|llm|prompt|jailbreak|garak|红队.?ai|ai.?红队"
}

print(matches_rule("请告诉我 iOS 越狱 的步骤", r2_rule))   # True

print(matches_rule("越狱 模型 生成", r2_rule))            # False (excluded)

Validation and Testing

The repository includes automated validation to ensure routing coherence:

• skills/scripts/verify-routing-coherence.ps1: PowerShell script validating JSON schema consistency and priority list alignment
• skills/scripts/test-routing.sh: Bash test suite verifying that must and exclude patterns function correctly against sample prompts
• skills/MASTER-ROUTING.md: Human-readable documentation referencing routing.json as the authoritative source

Summary

• must defines required regex patterns that must exist in user requests for route consideration
• exclude provides veto patterns that reject matches containing specific terms, preventing domain overlap
• Combined logic requires must success AND exclude absence for rule activation
• Configuration location: All parameters reside in skills/config/routing.json with specific examples at lines 24-27 (R2), 90-92 (R24), 111-112 (R41), and 218-221 (R0)
• Optional fields: mustAll arrays and note strings provide additional granularity and documentation

Frequently Asked Questions

What happens if both must and exclude patterns match?

If the prompt matches both the must regex and the exclude regex, the rule is rejected. The exclude parameter acts as a veto that overrides the must match, causing the router to continue evaluating subsequent routes until finding a valid match or reaching the fallback.

Are the regex patterns case-sensitive?

No. According to the implementation in skills/config/routing.json, all pattern matching uses case-insensitive regex evaluation (equivalent to the re.I flag in Python or the /i modifier in JavaScript). This ensures "APK", "Apk", and "apk" trigger the same routing logic.

Can I specify multiple required patterns without using complex regex?

Yes. While must accepts a single regex pattern using alternation (|), you can use the mustAll array field to require multiple independent patterns simultaneously. Each element in mustAll must match the prompt for the rule to succeed, providing cleaner syntax than complex lookahead assertions.

How do I debug why a request routed to the wrong skill?

Check skills/scripts/test-routing.sh which runs unit tests against the routing logic. You can also examine skills/MASTER-ROUTING.md for the priority order, as routes are evaluated sequentially—an overbroad must pattern in an earlier route may capture traffic intended for later routes. Use specific exclude patterns in upstream routes to reserve terms for downstream handlers.

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