uphiago/recon-skills: A Markdown Skill Pack for External Web Reconnaissance

What recon-skills actually ships, and who it is written for

This repository is a library of written procedures, not a program. The README describes "a curated pack of security skills for external reconnaissance, web applications, APIs, authentication, vulnerability validation, attack-path analysis, and reporting." Each skill, according to the README, "owns a focused objective and documents the prerequisites, procedure, pitfalls, verification criteria, and related techniques needed for that objective." So the deliverable is prose plus commands, organised per objective.

The intended reader is someone already running an external web assessment: a penetration tester, a bug bounty hunter, or a red teamer who owns the tooling and the scope. The README states the pack is "primarily focused on external web security" and lists the coverage as subdomain, DNS, port, HTTP and technology discovery; route, parameter, JavaScript, source-map and API mapping; authentication, authorization, session, OAuth, SAML and MFA testing; web vulnerability and framework-specific validation; cloud, identity, container and exposed-infrastructure pivots; and evidence review with reporting.

The README carries a scope warning near the top: "These skills are for authorized security testing only. Only test targets you own or have explicit written permission to test." That is the boundary the project draws around itself, and it is repeated in the framing rather than buried in a licence file.

One thing the README states outright is that the catalog is uneven. "Older skills are being migrated incrementally to the complete quality baseline." That sentence matters more than it looks: it means some skills are written to the full template and others are not, and the repository does not claim otherwise.

How the catalog is organised and how a skill is consumed

The layout is six directories, each with a stated purpose. The README prints the tree:

recon-skills/
|-- auth/       Authentication and SSO testing
|-- chains/     Multi-step attack-path analysis
|-- infra/      Infrastructure-focused techniques
|-- meta/       Engagement planning and cross-skill workflows
|-- recon/      Discovery, enumeration, and focused validation
`-- redteam/    Vulnerability-class and platform playbooks

The README says each skill is a `SKILL.md` file, and that "skills can be followed manually or loaded as task context by an automation system." That second option is the interesting one. A directory of Markdown files with a fixed internal structure is a format an agent or orchestration layer can read; it is not a plugin API, and there is no runtime in this repository that executes anything. The README does not document a schema beyond the objective, prerequisites, procedure, pitfalls and verification criteria it says each skill contains.

Consumption is deliberately flat. You clone, you search, you read. The README's own example does exactly that, and the entry-point table then names specific skills for specific phases: `meta/recon-playbook` for the end-to-end workflow and escalation gates, `recon/subdomain-enumeration` for passive and active discovery, `recon/js-secrets-extraction` for client-side bundles, `chains/cross-attack-chains` for evidence-based attack-path construction, `redteam/triage-validation` for validating a finding before it is reported, and `redteam/evidence-hygiene` for reproducible and redacted capture.

The README's guidance on sequencing is explicit: start with `redteam/web2-recon`, `recon/subdomain-enumeration`, `recon/web-enumeration` and `redteam/bb-methodology` for a broad external web assessment, then "add vulnerability or platform skills only when discovery produces a relevant signal." That is signal-driven escalation rather than running the whole catalog. The `hunt-*` skills are described as covering individual vulnerability classes and platform surfaces, so they are the leaf nodes you reach once something is worth pursuing.

Cloning the pack and running the catalog validator

There is no package to install. The README's install step is a clone plus a search, and it assumes standard Linux tooling.

git clone https://github.com/uphiago/recon-skills.git
cd recon-skills

find . -name SKILL.md -print | sort
rg -n "SSRF|OAuth|GraphQL|Kubernetes" --glob 'SKILL.md'

The `find` lists every skill file in the tree; the `rg` call searches inside those files for the vulnerability classes or platforms you care about. Expect a sorted list of paths from the first command and matching lines with file and line numbers from the second. If `rg` is not present on your system, that second command fails and you would need an alternative grep invocation, which the README does not provide.

The README then tells you to set a writable output location before running any example:

export OUTPUT_DIR="${OUTPUT_DIR:-./output}"
mkdir -p "$OUTPUT_DIR"

Skills write persistent artifacts beneath `${OUTPUT_DIR:-./output}` unless a skill documents another input, so this variable is the pack's one piece of shared configuration. Set it once per engagement and keep the directory with your engagement notes.

Finally, the repository ships its own checker:

python3 scripts/validate_skills.py

The README states that "structural errors fail the command" while "existing style debt is reported separately as warnings so it can be improved incrementally." That split is deliberate and it tells you how to read the output: a non-zero exit means a skill is structurally broken, while a clean exit with warnings means the skill works but has not yet been migrated to the full baseline. Run it after cloning to see the current state of the catalog before you trust any individual file.

The migration debt is a real limitation, not a footnote

The single biggest caveat is the one the README volunteers: older skills are being migrated incrementally to the quality baseline in STYLE.md. The validator enforces structure and warns about style, which means the catalog can pass the structural check while a substantial portion of its skills still fall short of the documented baseline. If you pick a skill at random, you may get the full template with prerequisites, pitfalls and verification criteria, or you may get something thinner.

The practical consequence is that you cannot treat the pack as uniform. The README's own entry-point table is effectively a curated shortlist of skills the project considers high-signal, and that shortlist is a better starting point than browsing the tree. The `find` output will show you everything; it will not tell you which files have been migrated.

A second limitation is that nothing here is executable. There is no CLI, no library, no scan command. The README says commands "assume standard Linux tooling unless a skill states otherwise," and that "tool availability, scope, network policy, concurrency, credentials, and isolation remain the operator's responsibility." Read that sentence as the project declining to solve dependency management, rate limiting, credential handling or sandboxing for you. If you need a tool that discovers assets on its own and normalises the results, this is the wrong repository.

A third is audience mismatch. The `hunt-*` skills are organised by vulnerability class and platform, which means the pack is most useful to someone who already knows how to confirm a finding and needs a repeatable procedure plus a place to record evidence. A beginner looking for guided practice will find the prerequisites assume a working environment the README does not build for them.

Where recon-skills differs from an automated recon framework

The obvious alternative is an automated reconnaissance framework such as ProjectDiscovery's recon tooling, which chains subdomain enumeration, probing and vulnerability templates into a pipeline that runs and produces output on its own. The difference in approach is fundamental rather than incremental. An automated framework encodes the procedure in code: you point it at a domain, it runs the stages, and you get artefacts. recon-skills encodes the procedure in Markdown: you read the stage, decide whether it applies, and run the commands yourself.

That trade-off cuts both ways. Automation wins on repetition and coverage, and it produces consistent output across engagements. The skill pack wins on judgement and on the parts of an assessment that resist scripting: deciding whether a CORS misconfiguration is actually exploitable, validating a finding before it goes into a report, and constructing an attack path from evidence. The README's table reflects that emphasis, with entries like `redteam/triage-validation` for "finding validation before reporting" and `redteam/evidence-hygiene` for "reproducible and redacted evidence capture." Those are review steps, not discovery steps.

The two are not mutually exclusive, and the README hints at the intended relationship by saying skills can be "loaded as task context by an automation system." A framework runs the discovery; the skill file supplies the reasoning and the verification criteria for what the framework surfaced. If you already run an automated pipeline, this pack sits downstream of it rather than replacing it.

The licensing comparison is simpler: recon-skills is MIT, which permits commercial use and modification with the licence and copyright notice retained. Automated frameworks vary, and some carry usage restrictions on the hosted components even when the CLI is permissive. The README does not discuss third-party licence terms, so check any tool a skill tells you to invoke separately.

Maintenance, upgrades and licence terms

The repository is not archived, and the last push was on 2026-09-01. No releases were retrieved, so there is no versioned artefact to pin and no changelog entry to cite beyond the presence of CHANGELOG.md at the top level. Upgrading means pulling the branch and re-running the validator, because the content is the product.

That has a practical consequence for anyone embedding these skills in a workflow. Because there are no tagged releases, there is nothing to pin to. A `git pull` can change the procedure inside a skill you have already built around, and the only signal that something changed is the diff. If you need reproducibility, record the commit hash you cloned rather than relying on a version number.

Maintenance cost is mostly review time. The README states that structural errors fail `python3 scripts/validate_skills.py` while style debt is reported as warnings, so the validator gives you a fast structural check but not a guarantee of quality. Contributing is governed by AGENTS.md, the quality baseline lives in STYLE.md, and SOUL.md holds the operating principles. Those three files, not the README, define what a migrated skill looks like.

The licence is MIT, stated in the README and present as LICENSE at the top level. That permits use, modification and redistribution, including commercially, provided the copyright notice and permission notice are kept. It says nothing about the tools the skills invoke, and it offers no warranty, which for security testing is worth being clear about: the README's authorised-testing-only notice is an instruction, not a licence term, and it does not transfer liability to the project. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt recon-skills if you already run your own tooling and want a written, reviewable procedure for each phase of an external web assessment, or if you are feeding task context to an automation system that reads SKILL.md files. Do not adopt it if you expect a runnable scanner: cloning the repository gives you Markdown, a validator script and a directory tree, and every command inside a skill is an instruction you execute yourself. Before relying on it, run python3 scripts/validate_skills.py to see which skills pass the structural baseline, check STYLE.md to understand what the warnings mean, and read one hunt-* skill end to end to confirm its procedure matches your scope and tooling.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. uphiago/recon-skills on GitHub