What Is the Role of RULES.md in reverse‑skill? The Complete Authority on AI Agent Behavior

RULES.md serves as the single source of truth that orchestrates routing, authorization, tool management, and quality control for the entire reverse‑skill framework, mandating a specific 14‑step behavior chain that every AI agent must execute before, during, and after any security or reverse‑engineering task.

The reverse‑skill repository provides a deterministic framework for security research and reverse‑engineering automation. At its center sits RULES.md, the authoritative document that defines every mandatory step an AI agent or client must follow to ensure secure, reproducible workflows. Understanding the role of RULES.md in reverse‑skill is critical for developers building compliant automation tools or integrating this framework into CI/CD pipelines.

Core Responsibilities of RULES.md

RULES.md performs four distinct governance functions that collectively enforce a deterministic execution model across the repository.

Authoritative Routing Gatekeeper

The file establishes strict routing hierarchy by declaring that skills/config/routing.json is the sole authoritative routing table, while alternative files like skills/routing.md remain strictly advisory. According to the source code at lines 3‑19, after reading RULES.md, the agent must immediately execute the hot‑path: master‑route → case‑init → primary SKILL.md. This routing decision is not optional; the agent must proceed directly to execution rather than merely acknowledging the rules.

Mandatory Scope Enforcement and Authorization

Before any ACT step can execute, RULES.md mandates an authorization gate implemented in case‑init. The case‑init script must produce a scope.md file containing auth.status=granted (or an authorized offline sample) as specified in lines 20‑24. Critically, the framework explicitly forbids bypassing this gate; even when using ‑Force or --force flags, the authorization requirement remains enforced (lines 48‑53). This ensures that no tool execution occurs without proper scope validation.

Tool Index Coordination and Bootstrapping

Every agent must consult skills/tool-index.md for concrete tool paths before invoking any utility. Lines 30‑38 of RULES.md require agents to bootstrap missing tools using platform‑native scripts prior to proceeding with the task. This coordination prevents execution failures from missing dependencies and standardizes the tool discovery process across different operating environments.

The Canonical 14‑Step Behavior Chain

Section Canonical Behavior Chain (lines 51‑66) enumerates the exact 14‑step process that all downstream scripts, tests, and documentation must reference. This chain serves as the functional specification against which verification scripts measure compliance. The verify‑routing‑coherence.ps1 script uses this canonical definition to ensure repository‑wide consistency, checking that every component adheres to the prescribed execution order.

Compliance Mechanisms in RULES.md

Beyond defining behavior, RULES.md implements active deterrents against procedural shortcuts.

The Excuse‑Rebuttal Table

To prevent agents from skipping mandatory steps, RULES.md embeds a baked‑in excuse‑rebuttal table (lines 12‑18). This table forces agents to reject common rationalizations such as "I can skip this step" and instead follow every item in the procedural checklist. The table acts as a behavioral guardrail during the planning phase.

Self‑Audit and Completion Checklist

Before declaring any task complete, agents must perform a self‑audit against the checklist embedded at lines 70‑81. This final verification ensures that all preceding steps—including routing validation, scope authorization, and tool verification—have been satisfied. The checklist provides a deterministic end‑state criterion that prevents premature task termination.

Implementing the RULES.md Workflow

The following examples demonstrate how to execute the mandatory behavior chain defined in RULES.md.

Execute the hot‑path entry point as required by the routing rules:

# Windows: Launch the master route as mandated by RULES.md hot-path

powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/master-route.ps1 -Hint "reverse_engineering_task"

# Linux/macOS/Kali: Launch the master route

bash skills/scripts/master-route.sh --hint "reverse_engineering_task"

After master‑route completes, execute the authorization gate:

# Run case-init to generate scope.md with auth.status validation

powershell -File skills/scripts/case-init.ps1

If tools are missing, bootstrap them according to RULES.md requirements:

# Bootstrap missing reverse engineering tools

bash skills/scripts/bootstrap-reverse.sh jadx

# Update the tool index as required by RULES.md coordination rules

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

Validate repository compliance against the canonical chain:

# Verify routing coherence matches RULES.md canonical behavior chain

powershell -NoProfile -ExecutionPolicy Bypass -File skills/scripts/verify-routing-coherence.ps1

Key Files Referenced by RULES.md

The following files implement the architecture prescribed in RULES.md:

• skills/config/routing.json — The sole authoritative routing table that RULES.md designates as the hot‑path source.
• skills/scripts/master-route.ps1 — Entry script implementing the first step of the mandatory behavior chain.
• skills/scripts/case-init.ps1 — Implements the authorization gate that produces scope.md with auth.status=granted.
• skills/tool-index.md — Holds concrete tool paths that agents must read before tool invocation.
• skills/SKILL.md — Primary skill document opened after the scope gate, as dictated by the canonical chain.
• skills/scripts/verify-routing-coherence.ps1 — CI verification script that validates repository compliance against the 14‑step canonical chain defined in RULES.md.

Summary

• RULES.md serves as the single source of truth for the reverse‑skill framework's entire behavior chain.
• It enforces a strict routing hierarchy where only skills/config/routing.json carries authority, directing agents through the hot‑path (master‑route → case‑init → SKILL.md).
• The document mandates authorization gates that cannot be bypassed by force flags, requiring auth.status=granted in scope.md before any ACT step.
• It requires tool index coordination, forcing agents to consult tool-index.md and bootstrap missing dependencies.
• The canonical 14‑step behavior chain (lines 51‑66) provides the deterministic specification used by verification scripts.
• Excuse‑rebuttal tables and self‑audit checklists prevent procedural shortcuts and ensure completion quality.

Frequently Asked Questions

What happens if an agent skips the authorization gate defined in RULES.md?

Skipping the authorization gate violates the mandatory behavior chain. RULES.md explicitly states that ‑Force or --force flags never bypass the auth.status=granted requirement in scope.md. Agents must execute skills/scripts/case-init.ps1 and obtain valid authorization before proceeding to any ACT step; failure to do so results in a non‑compliant workflow state.

How does RULES.md handle missing reverse‑engineering tools?

The file obliges agents to read skills/tool-index.md to locate concrete tool paths. If a required tool is absent, agents must run platform‑native bootstrap scripts (such as skills/scripts/bootstrap-reverse.sh) to install dependencies before continuing. This ensures that tool execution never fails due to missing binaries.

Why is routing.json considered authoritative while routing.md is only advisory?

RULES.md establishes this hierarchy at lines 3‑19 to prevent routing ambiguity. Only skills/config/routing.json contains the validated hot‑path definitions that the master‑route scripts consume. Alternative routing files like skills/routing.md serve documentation purposes but do not influence execution flow, ensuring deterministic agent behavior across different environments.

Can the canonical 14‑step behavior chain be modified or extended?

While the chain is codified in RULES.md at lines 51‑66, modifications would require updating both the governing document and all dependent verification scripts (such as verify‑routing‑coherence.ps1). The repository treats this chain as the immutable specification for compliance testing; any changes must propagate through the entire tooling ecosystem to maintain coherence.

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