Reverse-Skill Claude Code: Tool Routing Checks (2026)

This guide helps security researchers and agent developers deploy reverse-skill for authorized reverse engineering work. It covers installation, skill discovery, routing tests, dependency checks, permissions, failure recovery, and audit evidence.

Fit: Suitable for authorized APK, binary, JavaScript, and lab-sample analysis when routing is tested before execution. Not suitable for unattended work against unknown or third-party targets.

Core decision: Restrict the case boundary and tool permissions first. Then install reverse-skill and test it with known-answer samples for description matching, tool detection, execution planning, and failure fallback. Automatic tool selection is a routing aid, not a replacement for authorization or human review.

This guide is for security researchers analyzing owned or explicitly authorized samples, developers maintaining Claude Code Skills, and teams preparing an isolated remote environment with traceable tool changes.

Last updated August 10, 2026. Facts were checked against the current reverse-skill repository, its published Skill files, and the current Claude Code Skills, permissions, hooks, and CLI documentation. (reverse-skill repository, Claude Code Skills documentation)

What reverse-skill actually changes in Claude Code

Claude Code can load a SKILL.md file and use its description to decide when the Skill is relevant. Skills may exist at enterprise, personal, project, or plugin scope. Project Skills are stored under .claude/skills/<skill-name>/SKILL.md, while personal Skills use ~/.claude/skills/<skill-name>/SKILL.md. The directory name also affects the command used for direct invocation.

reverse-skill adds a more structured routing layer for security analysis. Its repository describes a flow that moves from task classification to routing rules, case scope, scenario-specific Skills, tool checks, evidence capture, and reporting. The repository lists separate entry points for APK analysis, mobile analysis, binary work, JavaScript analysis, malware analysis, packet work, and other security scenarios. (reverse-skill routing overview)

That distinction matters. Claude Code decides whether the Skill should load. reverse-skill helps decide which analysis path should be considered after loading. Neither layer proves that a target is authorized.

A useful mental model is route first, execute second. A successful installation report is not the end of the deployment. It is only the point where validation begins. The published project instructions direct an agent to inspect its routing and tool-index files before treating the package as ready. (project setup instructions)

Installation should start with an isolated case directory

Do not begin by giving the agent a broad home directory, shared credential store, or unrestricted network access. Create a workspace for one authorized case, place the repository there, and keep samples and evidence under separate paths.

A conservative installation sequence looks like this:

1. Create the case boundary.

Use a dedicated directory for the sample, the router repository, temporary files, and evidence. Record the case identifier, owner, authorization source, permitted target, and network policy in a plain-text scope file.

1. Clone the repository.

Use the installation command documented by the project:

```bash git clone https://github.com/zhaoxuya520/reverse-skill.git cd reverse-skill ```

Inspect README.md, README_AI.md, RULES.md, skills/SKILL.md, and skills/routing.md before allowing the agent to run scripts. The repository says that actual support depends on the current README and Skill files, so do not rely on an old tutorial or a copied prompt.

1. Check the runtime before changing it.

The repository lists Java or a JDK for Android tooling, Node.js for its JavaScript and MCP toolchain, Python for Frida-related helpers, and a compatible coding agent. Its current README specifies Node.js 22.12 or later for that toolchain. Treat these as project prerequisites, not as a reason to install everything automatically.

1. Refresh the tool index.

On Linux or macOS, run the documented shell script:

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

On Windows, use the documented PowerShell script:

```powershell powershell -File skills/scripts/refresh-tool-index.ps1 ```

Then read skills/tool-index.md. Confirm the executable path, version output, and a harmless help command for each tool. A file that merely exists is not enough. A broken runtime, missing library, or permission error can still make the tool unusable.

1. Expose the Skill at the correct Claude Code scope.

If the project is meant to use the Skill only for one repository, keep it under that project’s .claude/skills/ directory. If several projects need it, use the personal scope only after reviewing the contents. Claude Code watches known Skill directories for changes, but a newly created top-level Skills directory may require a session restart. (Skill discovery rules)

1. Run a direct invocation test.

Direct invocation separates discovery problems from routing problems. Invoke the Skill by its directory-derived command or ask Claude Code to list the available Skills. If direct invocation works but natural-language triggering fails, focus on the description and task wording rather than the filesystem.

For teams using a remote Mac node, keep the case directory and access model documented before installation. Review the provider's platform support and access procedures alongside the project’s own environment requirements. The ZekVPS service overview can help establish the service context, but platform support still does not replace a permission review.

The scores are our deployment judgment, not a benchmark. For security research, project scope is usually the strongest default because it limits accidental activation and keeps the configuration close to the evidence.

Why automatic discovery fails

Most “reverse-skill is installed but does nothing” reports fall into three different categories. Treating them as one problem wastes time.

Directory and scope problems

Claude Code expects a Skill directory with SKILL.md as its entrypoint. A misplaced file, wrong capitalization, nested directory that has not been discovered yet, or an untrusted project configuration can prevent loading. Skills in parent directories may load at startup. Skills in nested directories may become available only after Claude reads or edits files in that subdirectory.

Check these items in order:

find .claude -maxdepth 4 -name SKILL.md -print
pwd
git rev-parse --show-toplevel

Then verify:

• The directory name is stable and descriptive.
• SKILL.md is directly inside the Skill directory.
• YAML frontmatter is valid.
• The description says what task should trigger the Skill.
• The session starts in the expected project root.
• The Skill is not only inside a nested path that the session has not touched.
• A project-level rule has not disabled or hidden the Skill.

Naming conflicts

A same-name Skill can exist at more than one scope. Claude Code applies precedence rules across managed, personal, project, and plugin locations. A plugin Skill uses a namespace, but local Skills can still confuse testing if the operator invokes an unqualified name.

Use a unique directory name and test the exact path. Do not assume that /reverse means the repository’s main controller. The command name comes from the Skill layout, and nested variants may be directory-qualified. (Skill command and naming reference)

Description mismatch

A description such as “analyzes security tasks” is too broad. It can match APK work, binary triage, packet analysis, code review, or an unrelated secure-coding request. Broad wording increases false positives and makes routing results hard to explain.

A better description names the task boundary:

---
name: reverse-skill
description: Use for authorized analysis of an APK, ELF, PE, shared library, or frontend JavaScript sample when the user asks to classify the artifact, inspect available analysis tools, or produce a repeatable evidence plan. Do not invoke for unknown targets or live third-party systems.
---

Keep the first sentence specific. Claude Code truncates the combined description and optional when_to_use text at 1,536 characters in the Skill listing, so put the strongest trigger and the authorization boundary first. (Skill frontmatter reference)

How to test Claude Code Skills without touching a real target

Use known-answer samples. Good test inputs include a self-built APK, an open-source binary compiled locally, a small JavaScript bundle created for the lab, or a clearly authorized training sample. The expected answer should be written before the test begins.

Run four separate checks:

1. Discovery check: Does Claude Code see the Skill and identify its path?
2. Classification check: Does it classify the sample as APK, ELF, PE, JavaScript, PCAP, or another supported category?
3. Tool check: Does it report available, missing, and unusable tools before execution?
4. Plan check: Does it explain the selected workflow and request approval at the correct point?

A routing test should produce evidence such as:

case_id: lab-apk-001
authorization: local sample built by the team
artifact_type: APK
expected_route: static mobile analysis
expected_first_action: inspect metadata and tool availability
network_profile: disabled
approval_required_before: extraction, execution, dynamic instrumentation

Do not judge the router only by whether it names a familiar tool. The important question is whether it refuses to guess when the sample type, authorization, or tool state is uncertain.

This table is the core decision tool for deployment. If one row fails, do not move to production-like samples. Fix the description, route rule, permission policy, or tool environment first.

Tool routing can be wrong even when the Skill triggers

A triggered Skill proves only that the description matched. It does not prove that the selected method is correct.

For example, a mobile package may require static inspection first, while a local native library may need binary identification and symbol review. A frontend JavaScript sample may need source-map and call-chain analysis rather than an Android workflow. The published routing matrix separates these scenarios, which is why we should test boundary cases instead of sending every prompt through one generic security path.

Use prompts with narrow intent:

• “Classify this self-built APK and report the first safe inspection step.”
• “Inspect this locally compiled ELF without executing it.”
• “Identify whether this JavaScript bundle contains a source map.”
• “The sample is corrupted. Explain the fallback path and stop before modifying it.”

Avoid prompts that mix multiple goals, such as “analyze this target, find weaknesses, bypass protections, and test the endpoint.” That wording makes it difficult to identify which route was selected and where authorization should be checked.

Keep a human confirmation point after classification. The agent should present:

• Artifact type and confidence.
• Selected route and why it fits.
• Required tools and their versions.
• Files it will read or write.
• Network requirements.
• Commands that need approval.
• Expected failure conditions.

A useful routing score can be assigned during review:

A deployment that scores below the team’s agreed threshold should remain in the lab. The table is intentionally qualitative. It measures control quality, not analytical capability.

Missing tools and unsafe dependency changes

The tool index is a snapshot, not a guarantee. A remote machine may have the executable but lack the correct runtime, shared library, Java package, environment variable, or license access.

Ask the Agent to produce a preflight report before installation:

tool
expected purpose
detected path
version
help command status
input/output directory
network requirement
install source
change approval

Then decide whether to install, switch methods, or stop. Do not allow automatic installation to become an implicit permission grant.

Remote environments add hidden costs:

• Temporary packages can change another project’s behavior.
• Global Node or Python changes can break pinned workflows.
• Downloaded dependencies create a supply-chain review task.
• A tool may write caches outside the case directory.
• Network access used for installation can remain available during analysis.
• License-based tools may expose credentials through environment variables or configuration files.

Use a case-local virtual environment where practical. Record package names, versions, commands, timestamps, and the person who approved the change. If the environment cannot preserve that record, use a clean disposable node or revert to a tool already approved by the team.

For Claude Code itself, begin with normal permission prompts or plan mode. The CLI supports explicit allow and deny tool lists, permission modes, verbose output, and structured JSON output for scripted workflows. Avoid bypassing permission prompts in an analysis environment. (Claude Code CLI reference)

Reminder: Tool routing is not authorization. A Skill can recommend a method, but only the case owner can confirm that the sample and action are within scope.

Permission boundaries and audit records

The minimum permission design should separate four areas:

1. Readable evidence: The authorized sample and supporting notes.
2. Writable workspace: Temporary extraction and generated reports.
3. Protected data: Credentials, unrelated repositories, SSH keys, cloud configuration, and personal files.
4. Network targets: Prefer no network during static analysis unless the authorization explicitly includes a controlled endpoint.

Claude Code permissions support allow, ask, and deny rules. Rules are evaluated with deny taking precedence, and managed settings cannot be overridden by lower-level settings or command-line allowances. (Permission rules)

A conservative policy should:

• Allow reads only inside the case directory.
• Ask before shell execution.
• Deny access to credential paths.
• Deny destructive commands and broad recursive deletion.
• Deny outbound network access unless the test plan names the destination.
• Require approval for dynamic execution or instrumentation.
• Keep generated evidence outside the source sample directory.
• Review workspace trust before applying project allow rules.

Add hooks when manual review alone is not enough. A PreToolUse hook can inspect a proposed command and block it with exit code 2. A ConfigChange hook can record modifications to settings or Skill files. Claude Code’s hook documentation states that exit code 2 blocks a pending tool call, while other nonzero codes are generally non-blocking for most events. (Claude Code hooks documentation)

At minimum, retain:

• Case scope and authorization reference.
• Initial prompt and routing result.
• Skill version or commit identifier.
• Tool index before and after dependency changes.
• Permission settings.
• Human approval or rejection.
• Commands and arguments.
• Standard output and error output.
• Hashes or identifiers for input samples.
• Failure and fallback decisions.
• Final report and reviewer name.

Do not store secrets in transcripts. Redact tokens, private keys, session cookies, and unrelated personal data before long-term retention.

FAQ: Installation, routing, permissions, and fallback

How do I install reverse-skill in Claude Code?

Clone the repository into an isolated workspace, inspect its README and SKILL.md files, then refresh the local tool index for your operating system. Confirm that the Skill directory is visible to Claude Code before testing automatic invocation. Keep the repository and analysis samples inside a dedicated project directory rather than installing into a shared home folder.

How does Claude Code choose a reverse engineering tool?

Claude Code uses the Skill description and loaded instructions to decide whether a Skill is relevant. reverse-skill then provides routing files and scenario-specific guidance. The result is only a proposed method. The Agent still needs to inspect the sample, confirm available tools, explain its choice, and wait for approval before running sensitive commands.

What should I check when a Skill does not trigger automatically?

Check the SKILL.md location, directory name, frontmatter, description, project scope, and whether the session can see the directory. Then test with a narrow prompt that matches the description. Also look for a same-name Skill at another scope or a description that is too broad to distinguish APK, binary, JavaScript, and packet-analysis tasks.

How can I limit permissions for a reverse engineering Agent?

Start in plan or default permission mode, allow read-only access to the sample directory, and deny unrelated paths, credential files, destructive shell commands, and unnecessary network access. Require approval before tool execution. Add a PreToolUse or ConfigChange hook when policy enforcement is needed.

A five-minute preflight before enabling repeated runs

Before the first real authorized case, run this short acceptance sequence:

1. Confirm the sample owner and written authorization.
2. Record the repository revision and current SKILL.md.
3. Verify the Skill path and direct invocation.
4. Run the tool-index refresh script.
5. Check every required executable with a version or help command.
6. Start Claude Code in plan or default permission mode.
7. Submit one known-answer sample.
8. Compare the selected route with the expected route.
9. Test an unknown format and a corrupted file.
10. Verify that the agent stops before unauthorized network activity.
11. Review the transcript, command history, outputs, and approval record.
12. Revoke temporary permissions and preserve the final evidence bundle.

The deployment is ready only when the Agent can do four things consistently:

• Refuse an out-of-scope task.
• Explain why it selected a method.
• Record missing tools and failed commands.
• Pause for human takeover before sensitive execution.

If it can route correctly but cannot prove what it did, it is not ready for a repeatable security workflow.

Is a remote Mac environment a better fit?

A local Linux or Windows machine may be the right choice when the team already has approved tooling, stable images, and strong endpoint controls. A remote Mac environment can make sense when the case includes Apple-specific files, macOS-only tooling, a disposable development workspace, or a need to keep analysis separate from a daily workstation.

The current setup still has real weaknesses if it runs on a shared laptop or an improvised remote host: permissions are often broader than the case requires, dependency changes are hard to reproduce, and logs may remain scattered across terminal history, temporary folders, and Agent transcripts. A remote environment does not solve those issues automatically. It becomes useful only when the workspace, access path, retention policy, and approval workflow are defined first.

We recommend reviewing ZekVPS’s remote Mac environment options before deciding whether a temporary Mac workspace fits the case. For a short authorized test, renting an isolated environment can be easier to reset and document than modifying a production workstation. It is still not the best option for long-running heavy workloads that require fixed hardware ownership, physical interfaces, or permanent local storage.

The practical choice is simple: establish scope and permissions first, then use reverse-skill as a measurable routing component. If the environment cannot show what the Agent saw, what it selected, what it ran, and where a human approved it, postpone deployment rather than adding more tools.