# How `bootstrap-reverse.ps1` Automates Tool Availability Checking in the Reverse-Skill Framework

> Discover how bootstrap-reverse.ps1 automates tool availability in the reverse-skill framework. Learn about its three-phase automation for seamless execution and dependency checks.

- Repository: [ZhaoXu/reverse-skill](https://github.com/zhaoxuya520/reverse-skill)
- Tags: how-to-guide
- Published: 2026-08-18

---

**`bootstrap-reverse.ps1` guarantees every required tool is present before execution through a three-phase automation system: dependency resolution functions, capability-specific bootstrappers, and orchestrated result reporting.**

The `bootstrap-reverse.ps1` script in the [zhaoxuya520/reverse-skill](https://github.com/zhaoxuya520/reverse-skill) repository eliminates manual setup friction for reverse engineering workflows. It interrogates the system, installs missing runtimes and binaries, and registers MCP servers—ensuring downstream skills can rely on declared capabilities without intervention.

## Three-Phase Tool Availability Automation

The script implements a coordinated pipeline that transforms capability requirements into verified, executable tools on disk.

### Phase 1: Dependency Resolution Functions

Small helper functions interrogate the system and trigger installations when components are absent.

**`Get-BootstrapDependency`** reads [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) to resolve the canonical package name and version for a given capability. Located at lines 28-37 in `skills/scripts/bootstrap-reverse.ps1`, it provides the mapping layer between abstract capability names and concrete installable artifacts.

**Runtime installers** handle language-specific environments:

- **`Ensure-WingetPackage`** – Installs via Windows Package Manager
- **`Ensure-NodeRuntime`** – Locates `node` with `Get-FirstCommandPath`, falls back to `winget install OpenJS.NodeJS.22`
- **`Ensure-PythonRuntime`** – Validates `python` availability
- **`Ensure-JavaRuntime`** – Ensures JDK presence

```powershell

# From Ensure-NodeRuntime (lines 47-53)

if (-not (Get-FirstCommandPath -Names @('node'))) {
    Ensure-WingetPackage -Id 'OpenJS.NodeJS.22' -Label 'Node.js 22'
}

```

`Get-FirstCommandPath` is the core discovery mechanism—defined in `skills/scripts/lib/ToolDiscovery.ps1`, it searches `$env:PATH` for candidate executable names and returns the first match.

### Phase 2: Capability-Specific Bootstrappers

`Ensure-Capability` (lines 58-110) maps each capability to a **bootstrap kind** and dispatches to specialized installers:

| Bootstrap Kind | Handler Function | Implementation Details |
|---------------|------------------|------------------------|
| `github-release-zip` | `Ensure-GitHubZipInstall` | Download release archive, verify SHA-256, extract to `$definition.installDir` |
| `git-clone` | `Ensure-GitClone` | Clone repository to local path |
| `npm-global` | `Ensure-NpmGlobalPackage` | `npm install -g`, execute post-install hooks |
| `pip-package` | `Ensure-PipPackage` | `python -m pip install` with version pinning |
| `go-install` | `Ensure-GoInstall` | `go install` with Docker fallback |

**GitHub release extraction** demonstrates integrity verification:

```powershell

# From Ensure-Capability case 'github-release-zip' (lines 58-66)

$definition = Get-ReverseBootstrapDefinition -Name 'radare2'
Ensure-GitHubZipInstall -Definition $definition `
    -TargetPath $definition.installDir `
    -VerifyName $definition.verifyCommand

```

**Go install with Docker fallback** handles edge cases where compilation fails:

```powershell

# From Ensure-Capability case 'go-install' (lines 100-110)

if ($definition.fallbackKind -eq 'docker-image') {
    $docker = Get-FirstCommandPath -Names @('docker')
    if ($docker) {
        $serverDefinition = @{
            type = 'stdio'
            command = 'docker'
            args = @('run','--rm','-i',$definition.dockerImage) + @($definition.mcpArgs)
        }
        Ensure-McpServer -ServerName $definition.mcpNames[0] -ServerDefinition $serverDefinition
    }
}

```

### Phase 3: Orchestration and Result Reporting

The main execution block coordinates dependency expansion and sequential installation.

**`Expand-CapabilityDependencies`** (lines 26-34) performs **topological sorting** of capability requirements, ensuring that foundational tools install before dependent ones. It reads the dependency graph from [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) and returns an ordered list.

The orchestration loop processes each capability and handles failures gracefully:

```powershell

# Main execution block (lines 62-69)

$expandedCapabilities = Expand-CapabilityDependencies -Names $Capability
foreach ($name in $expandedCapabilities) {
    $definition = Get-ReverseBootstrapDefinition -Name $name
    Ensure-Capability -Name $name
}

```

**Failure handling** emits structured warnings when auto-installation is impossible. At lines 71-92, the script generates "manual-required" messages with documentation URLs, allowing users to resolve complex dependencies interactively.

**Post-installation refresh** regenerates the tool index unless suppressed:

```powershell

# From finalization block (lines 115-124)

if (-not $SkipRefresh) {
    & "$PSScriptRoot/refresh-tool-index.ps1"
}

# Output JSON summary and exit with appropriate code

```

## Supporting Infrastructure

The automation relies on coordinated modules across the repository:

- **`skills/scripts/lib/ToolDiscovery.ps1`** – `Get-FirstCommandPath`, `Resolve-ReverseToolSpec`
- **`skills/scripts/lib/BootstrapSupplyChain.ps1`** – [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json) schema, `Get-ReverseBootstrapDefinition`
- **`skills/scripts/refresh-tool-index.ps1`** – Tool index regeneration after installation
- **`skills/scripts/test-bootstrap-supply-chain.ps1`** – Unit tests validating bootstrap logic

## Summary

`bootstrap-reverse.ps1` automates tool availability checking through:

- **System interrogation** via `Get-FirstCommandPath` to detect existing executables
- **Runtime installation** through `winget` and OS-specific package managers
- **Binary acquisition** from GitHub releases with SHA-256 verification
- **Dependency expansion** with topological ordering of capability requirements
- **Graceful degradation** to Docker containers when native builds fail
- **MCP server registration** for tools like **Anything Analyzer** and **IDA Pro**
- **Structured reporting** with JSON output and non-zero exit codes on failure

## Frequently Asked Questions

### What happens if a tool cannot be automatically installed?

The script emits a "manual-required" warning containing the capability name, required version, and documentation URL. Execution continues for other capabilities, and the final JSON summary indicates which tools need manual intervention. The exit code reflects partial success when any capability fails auto-installation.

### How does the script handle circular dependencies in capabilities?

`Expand-CapabilityDependencies` implements cycle detection during topological sort. If a circular reference is detected in [`bootstrap-manifest.json`](https://github.com/zhaoxuya520/reverse-skill/blob/main/bootstrap-manifest.json), the function throws a terminating error before any installation begins, preventing infinite loops or undefined install order.

### Can I skip the tool index refresh after bootstrap?

Yes. Supply the `-SkipRefresh` switch parameter when invoking `bootstrap-reverse.ps1`. This is useful when chaining multiple bootstrap operations or when the caller will manually trigger `refresh-tool-index.ps1` after a batch of installations completes.

### Is the bootstrap process limited to Windows?

While `bootstrap-reverse.ps1` is written in PowerShell and uses `winget` as the primary package manager, the architecture supports cross-platform operation. Runtime installers like `Ensure-PythonRuntime` and `Ensure-NodeRuntime` check for existing executables first, and the Docker fallback mechanism provides platform-agnostic execution for Go-based tools.