# How reverse-skill Manages Tool Discovery and Installation: Inside the PowerShell Catalog System

> Discover how reverse-skill manages tool installation with a catalog-driven PowerShell layer. Learn about automated discovery and safe invocation across Windows, Linux, and Kali.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: internals
- Published: 2026-08-26

---

**reverse-skill uses a catalog-driven PowerShell layer in `skills/scripts/lib/ToolDiscovery.ps1` that maintains a static array of tool definitions with ordered fallback resolution chains, enabling automated discovery and safe invocation across Windows, Linux, and Kali environments.**

The zhaoxuya520/reverse-skill repository implements a robust framework for reverse engineering workflows that depends heavily on external binaries, MCP servers, and runtime dependencies. Understanding how reverse-skill tool discovery and installation functions requires examining its declarative PowerShell catalog system, which serves as the single source of truth for locating, verifying, and invoking specialized tools across heterogeneous environments.

## The Catalog-Driven Architecture

The foundation of reverse-skill's tooling management rests on two declarative sources: a static PowerShell catalog for executables and a JSON manifest for external service dependencies.

### The Tool Catalog (Get-ReverseToolCatalog)

Located in `skills/scripts/lib/ToolDiscovery.ps1` at lines 45-1125, the `Get-ReverseToolCatalog` function returns a static array of **PSCustomObject** entries. Each entry defines the tool's identity, associated skill domain, version detection strategy, and an ordered list of resolution fallbacks.

```powershell
[pscustomobject]@{
    Name = 'jadx'
    Skill = 'apk-reverse'
    Purpose = 'Java 反编译'
    FixedVersion = 'v0.5.0'
    VersionArgs = @()
    Fallbacks = @(
        [pscustomobject]@{ Type = 'command'; Value = 'jadx' },
        [pscustomobject]@{ Type = 'path'; Value = (Join-Path $userProfile 'Tools\jadx\bin\jadx.bat') }
    )
}

```

The catalog functions as the immutable source of truth; adding support for new tools requires only extending this array without modifying downstream discovery logic.

### Bootstrap Manifest for External Services

Tools requiring MCP servers, npm packages, or network services are defined separately in **[`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json)**, accessed via `Get-ReverseBootstrapManifestPath` and parsed by `Get-ReverseBootstrapCatalog`. This separation allows the framework to extend platform capabilities without touching PowerShell code, supporting dynamic registration of Claude/Codex MCP servers and auto-installable runtime dependencies.

## The Discovery Resolution Process

The discovery engine implements a layered resolution strategy through `Resolve-ReverseToolSpec` (lines 974-1069 in ToolDiscovery.ps1), which transforms catalog entries into executable specifications.

### Fallback Resolution Chain

When locating a tool, the system evaluates fallback entries sequentially until one succeeds:

- **Command fallback**: Executes `Get-Command` to verify presence in system `$PATH`
- **Path fallback**: Verifies file existence, injects the containing directory into process `$PATH` via `Add-ReverseProcessPath`, and marks the file as executable
- **Java-Jar fallback**: Resolves the `java` command first, then constructs a wrapper argument array `['-jar', $jarPath]`

If no candidate resolves, the function returns a specification with `Available = $false`, allowing the framework to gracefully handle missing dependencies.

### Capability State Evaluation

`Get-ReverseCapabilityState` (lines 1061-1149) merges catalog data with bootstrap requirements to determine operational readiness. It evaluates **MCP registration status** via `Get-ClaudeMcpServerNames` and `Get-CodexMcpServerNames`, **service reachability** through `Test-ReverseTcpPort` and `Test-ReverseMcpHttp`, and **runtime availability** for npm-based tools via `npx` detection.

The resulting state object reports whether the tool is ready for immediate use, eligible for automatic installation, and where to find its documentation.

### Version Detection and Safe Invocation

`Get-ReverseToolVersion` (lines 1094-1115) executes the resolved tool with its declared `VersionArgs` (unless `FixedVersion` is hardcoded), extracting the first meaningful output line. For execution, `Invoke-ReverseTool` (lines 1119-1142) guarantees correct command construction—automatically prepending `java -jar` for JAR-based tools or path prefixes for resolved fallbacks.

## Managing Tool Inventory

The framework provides utilities for monitoring and extending the tool ecosystem without core code changes.

### Generating Tool Reports

`Get-ReverseToolReport` (lines 1150-1173) aggregates catalog entries with live capability states, producing structured output for inventory management:

```powershell
Get-ReverseToolReport | Format-Table Name, Skill, Available, Ready, Version, DocsUrl

```

This produces diagnostic tables showing exactly which tools are present, functional, and correctly versioned across the environment.

### Adding Custom Tools

Extending the catalog requires only editing `Get-ReverseToolCatalog`. For example, adding GDB support:

```powershell
[pscustomobject]@{
    Name = 'gdb'
    Skill = 'native-reverse'
    Purpose = 'GNU 调试器'
    FixedVersion = ''
    VersionArgs = @('--version')
    Fallbacks = @(
        [pscustomobject]@{ Type = 'command'; Value = 'gdb' },
        [pscustomobject]@{ Type = 'path'; Value = (Join-Path $userProfile 'Tools\gdb\bin\gdb.exe') }
    )
}

```

Running `Get-ReverseToolReport` immediately reflects the new entry without restarting the framework.

### Runtime Invocation

After resolution, tools execute through the safe wrapper:

```powershell

# Debug the resolution chain

$spec = Resolve-ReverseToolSpec -Name 'adb'
$spec.Command  # Returns 'adb' or full resolved path

# Execute with guaranteed correct argument prefixing

Invoke-ReverseTool -Name 'adb' -Arguments @('devices')

```

## Cross-Platform Discovery Implementation

While Windows relies on `skills/scripts/lib/ToolDiscovery.ps1`, Linux and Kali environments utilize **[`kali/scripts/lib/tool-discovery.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/kali/scripts/lib/tool-discovery.sh)**, which mirrors the PowerShell catalog structure for Bash-based resolution. The `skills/scripts/lib/BootstrapSupplyChain.ps1` module handles automatic installation for tools marked `canAutoInstall` in the bootstrap manifest, ensuring consistent availability across Windows Subsystem for Linux, native Linux, and dedicated Kali installations.

## Summary

- reverse-skill implements centralized tool discovery through a static PowerShell catalog in `skills/scripts/lib/ToolDiscovery.ps1` that defines executables, resolution fallbacks, and metadata
- The `Resolve-ReverseToolSpec` function walks ordered fallback chains (command, path, java-jar) to locate executables across variable system configurations without requiring standard installation paths
- Capability state evaluation in `Get-ReverseCapabilityState` integrates MCP server registration, network reachability, and runtime availability into a unified readiness report
- Tools can be added by extending `Get-ReverseToolCatalog` without modifying discovery logic, while [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) handles external service dependencies separately from executable discovery
- Cross-platform support is achieved through parallel PowerShell and Bash implementations, with `BootstrapSupplyChain.ps1` providing automated installation for eligible tools marked in the manifest

## Frequently Asked Questions

### How does reverse-skill handle tools that aren't in the system PATH?

The framework uses **fallback resolution chains** defined in each catalog entry. If `Get-Command` fails to locate a tool in `$PATH`, the system checks explicit file paths, adds their directories to the process environment via `Add-ReverseProcessPath`, or constructs Java JAR wrappers. This allows tools to reside in user directories or custom installation prefixes while remaining discoverable by the framework.

### Can reverse-skill automatically install missing tools?

Yes, through the integration of `skills/scripts/lib/BootstrapSupplyChain.ps1` and entries in [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json). When `Get-ReverseCapabilityState` identifies a tool marked with `canAutoInstall`, the supply chain module can retrieve and configure the dependency without manual intervention, particularly for MCP servers and npm-based utilities.

### How do I add a proprietary or internal tool to reverse-skill's discovery system?

Edit the `Get-ReverseToolCatalog` function in `skills/scripts/lib/ToolDiscovery.ps1` to include a new **PSCustomObject** with the tool's name, associated skill, version arguments, and an ordered list of fallback strategies. The discovery logic requires no changes—the existing `Resolve-ReverseToolSpec` engine will immediately recognize and resolve the new entry on the next execution of `Get-ReverseToolReport`.

### Does reverse-skill support tool discovery on Linux and macOS?

Yes. While Windows uses the PowerShell implementation in `skills/scripts/lib/ToolDiscovery.ps1`, Linux and Kali environments use **[`kali/scripts/lib/tool-discovery.sh`](https://github.com/zhaoxuya520/reverse-skill/blob/main/kali/scripts/lib/tool-discovery.sh)**, which implements equivalent catalog-based discovery in Bash. Both systems share the same bootstrap manifest format, ensuring consistent capability evaluation and reporting across operating systems.