OSINT Tool Deploy Skill

Claude Code plugin/skill: install an OSINT tool from GitHub on any OS and prove it works.

Quick Start

As a plugin (gets updates, one command to install):

/plugin marketplace add soxoj/claude-osint-deploy
/plugin install osint-deploy@osint-deploy-marketplace

As a bare skill (no marketplace, no updates):

git clone https://github.com/soxoj/claude-osint-deploy
cp -r claude-osint-deploy/skills/osint-deploy ~/.claude/skills/        # user-wide
cp -r claude-osint-deploy/skills/osint-deploy .claude/skills/          # or one project

Either way you then say "install sherlock from github and make sure it works", or type /osint-deploy sherlock-project/sherlock.

What it does

You point it at a GitHub repo. It gets that tool running on your machine and then shows you proof that it actually works.

Getting there means answering questions you would otherwise answer by hand:

• What is this repo, really? A CLI, a web server, a desktop app, a browser extension, or just an awesome-list with nothing to install. Each needs a different treatment.
• How should it be installed here? A prebuilt binary if the project ships one, Docker if the dependencies are heavy, an isolated Python environment with the interpreter version the project actually wants — whichever is the least work that still satisfies the project's constraints. On Windows it also decides where to run it: WSL, Docker, or native.
• Does it work? Not "did the install command exit 0" — it runs the project's own test suite, taken from its CI configuration, and the example commands from its README against real targets.
• And if something fails, whose fault is it? A rate-limited API, a missing key, a login you have to do yourself and an actually broken install look identical at first glance. They get told apart and reported separately, so you never chase a bug that isn't yours.

Everything it learns goes into a recipe, so reinstalling the same tool later — or on another machine — is one command.

What's Inside

skills/osint-deploy/
  SKILL.md                      the 7-phase procedure + the traps it exists for
  references/stacks.md          stack decision table, per-OS quirks, bootstrap
  references/verify.md          manifest format, server/auth patterns, failure classes
  references/known-tools.md     the top 10 as actually deployed + per-tool gotchas
  references/troubleshooting.md symptom -> cause -> fix ladder
  scripts/env_probe.py          one call, all stack-decision facts (stdlib only)
  scripts/recon.py              one call, all Phase 1 repo facts incl. CI test commands
  scripts/verify.py             runs a checks manifest, PASS/FAIL/NET/SKIP (stdlib only)
  examples/*.checks.json        5 manifest templates, one per check shape

Verified

Two honest numbers:

• ~65 repositories examined — from GitHub's topic:osint (the top 10 by stars, plus random samples down to rank ~300).
• 50 tools deployed and verified end-to-end — each with a passing check manifest in ~/osint_tools/recipes/.

The rest were correctly classified as not-installable (awesome-lists, a wordlist, a desktop .exe, multi-container platforms) — a "no" is a valid result, not a failure.

The verified set spans: