How the Trigger Layer in reverse-skill Is Configured: Keywords, Routing, and JSON Rules

The trigger layer in reverse-skill is configured through a bilingual keyword catalogue in RULES.md that defines activation terms, paired with a regex-based routing table in skills/config/routing.json that maps matches to specific skill modules via the master-route script.

The reverse-skill repository implements a decision-tree routing system to direct natural language requests toward specialized reverse-engineering skill modules. At the heart of this system lies the trigger layer, a two-stage filtering mechanism that first identifies relevant requests via keyword matching, then routes them to the appropriate skill document. This configuration relies on tightly coupled human-readable definitions and machine-readable routing rules processed by the master-route orchestration scripts.

Trigger Keywords in RULES.md

The first stage of the trigger layer resides in [RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md), specifically within the "Trigger Keywords (ANY match triggers routing)" section. This bilingual catalogue enumerates every term that can activate the routing engine.

The section contains a plain list of strings and regular expressions covering domains such as APK reverse engineering, binary analysis, and frontend JavaScript security. Matching operates on a case-insensitive basis across both English and Chinese terminology. When the master-route script parses a user request, it scans for the presence of any term from this list to determine if specialized routing should occur.

### Trigger Keywords (ANY match triggers routing) — Bilingual / 中英双语

- APK, Android reverse, decompile, 反编译, smali, jadx, apktool, Frida, Hook
- binary analysis, 二进制分析, IDA, radare2, r2, disassembly, 反汇编, reverse engineering, 逆向工程
- frontend signature, 前端签名, encrypted params, 加密参数, JS reverse, JS 逆向

This list serves as the single source of truth for trigger definitions. All routing decisions originate from matches against these keywords, making RULES.md the authoritative gatekeeper for the entire trigger layer.

Routing Table Configuration in routing.json

Once a trigger keyword match is detected, the system consults [skills/config/routing.json](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) to determine the destination skill module. This JSON file defines the routing table, mapping specific regex patterns to skill document paths through a scoring and priority system.

Each entry in the routes object follows a structured format:

{
  "R1": {
    "label": "APK reverse",
    "skill": "apk-reverse/SKILL.md",
    "keywords": [
      { 
        "must": "\\bapk\\b|smali|jadx|apktool|\\bandroid\\b|android.?reverse|安卓|反编译.?apk|apk.?加固|重打包|root.?detect|root.?检测|证书.?校验|certificate.?pinning|pinning.?绕过|签名.?校验", 
        "note": "android 裸词/root 检测/证书校验/pinning 绕过 均为 APK 分析常见诉求" 
      }
    ]
  }
}

The configuration utilizes several key fields:

• label – Human-readable identifier for the route
• skill – Relative path to the primary skill markdown file
• keywords – Array of objects containing must regex patterns that refine the initial trigger match
• priority – Global array (defined separately in the JSON) that ranks routes when multiple matches occur

Scoring operates on a point-based system where each matching must regex contributes to the route's total score. Routes with higher scores outrank lower-scoring alternatives. When scores tie, the order defined in the priority array determines the winner, with identifiers appearing earlier receiving precedence. If no routes match, the system falls back to R0, the general reverse-engineering skill.

Execution Flow via master-route Scripts

The trigger layer executes through shell and PowerShell scripts located in skills/scripts/. The [master-route.sh](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/master-route.sh) (Linux/macOS) and master-route.ps1 (Windows) scripts implement the actual trigger detection logic.

The execution sequence follows four distinct steps:

1. Keyword Extraction – The script reads RULES.md and extracts the trigger keyword catalogue
2. Initial Matching – It scans the user request against the bilingual keyword list to establish routing candidacy
3. Regex Scoring – For candidate routes, it applies the must regex patterns from routing.json to calculate match scores
4. Priority Resolution – It selects the highest-scoring route, using the priority array to break ties, then opens the corresponding skill document

# Simulate a request containing APK and Frida terminology

bash skills/scripts/master-route.sh --hint "How do I use Frida to hook an APK?"

The script outputs the matched triggers, selected route identifier, and target skill path, providing deterministic routing based solely on the configured rules.

Extending and Modifying the Trigger Layer

Adding support for new reverse-engineering domains requires updating both configuration files and regenerating auxiliary indices.

To add a new trigger domain:

1. Update RULES.md – Append new bilingual keywords to the Trigger Keywords section:

- cloud-native runtime, 云原生运行时, container, 容器, kubernetes, k8s

2. Create Route Entry – Add a new route object to routing.json:

"R42": {
  "label": "Cloud-native reverse",
  "skill": "cloud-native-reverse/SKILL.md",
  "keywords": [
    { "must": "cloud.?native|kubernetes|k8s|docker|容器.?原生|云原生" }
  ]
}

3. Set Priority – Insert the route identifier into the priority array at the desired precedence level:

"priority": [
  "R4", "R1", "R2", "R3", "R30", "R31", "R33", "R5", "R9", "R21",
  "R22", "R6", "R7", "R8", "R34", "R28", "R17", "R16", "R18", "R24",
  "R37", "R23", "R42", "R35", "R25", "R44", "R36", "R29", "R38", "R32",
  "R26", "R27", "R10", "R11", "R12", "R13", "R14", "R15", "R19", "R40",
  "R20", "R39", "R41", "R0"
]

4. Refresh Indices – Run the refresh script to update auxiliary tool mappings:

bash skills/scripts/refresh-tool-index.sh

Modifying existing triggers follows the same pattern: update the regex in routing.json or add synonyms to RULES.md, then refresh the index. Changes take effect immediately for subsequent master-route invocations.

Summary

• The trigger layer operates as a two-stage system: trigger detection via RULES.md keywords followed by skill routing via routing.json regex scoring.
• [RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) contains the bilingual keyword catalogue that activates the routing engine when any term matches.
• [skills/config/routing.json](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/config/routing.json) defines route objects with label, skill paths, keywords regex arrays, and a global priority list for tie-breaking.
• [master-route.sh](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/master-route.sh) and master-route.ps1 execute the trigger logic, scoring matches and selecting the highest-priority skill document.
• The [refresh-tool-index.sh](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/refresh-tool-index.sh) script updates auxiliary indices after configuration changes.

Frequently Asked Questions

How does the trigger layer handle ambiguous requests with multiple keywords?

The trigger layer resolves ambiguity through a scoring mechanism defined in routing.json. Each matching must regex within a route's keywords array contributes to that route's score. The route with the highest score wins. If multiple routes achieve identical scores, the system consults the priority array, where route identifiers appearing earlier in the list take precedence over those appearing later.

Can I modify trigger keywords without changing the routing logic?

Yes. The trigger keywords in [RULES.md](https://github.com/zhaoxuya520/reverse-skill/blob/main/RULES.md) function independently from the routing regexes. Adding synonyms or alternative phrasing to RULES.md will cause the master-route script to consider a request for routing, but the final skill selection still depends on the more specific must regex patterns defined in routing.json. This separation allows broad capture of user intent while maintaining precise routing control.

What happens if a request matches no trigger keywords?

When no trigger keywords from RULES.md are detected, or when no route in routing.json achieves a positive score, the system defaults to route R0. This route typically points to a general reverse-engineering skill document that handles generic requests. The fallback ensures that the system always returns a relevant skill module even when specific terminology is absent from the trigger layer configuration.

Is the trigger layer configuration hot-reloadable, or does it require service restart?

The trigger layer configuration is fully hot-reloadable. The master-route scripts read RULES.md and routing.json at execution time for each request. After modifying either file, you should run [skills/scripts/refresh-tool-index.sh](https://github.com/zhaoxuya520/reverse-skill/blob/main/skills/scripts/refresh-tool-index.sh) to update auxiliary indices, but no service restart is required; subsequent invocations of master-route immediately utilize the updated trigger definitions and routing rules.

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