If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/hahwul/WebHackersWeapons shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2w ago
• 6 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 64% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live hahwul/WebHackersWeapons repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hahwul/WebHackersWeapons.

What it runs against: a local clone of hahwul/WebHackersWeapons — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in hahwul/WebHackersWeapons | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 45 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of hahwul/WebHackersWeapons. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/hahwul/WebHackersWeapons.git
#   cd WebHackersWeapons
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of hahwul/WebHackersWeapons and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hahwul/WebHackersWeapons(\\.git)?\\b" \\
  && ok "origin remote is hahwul/WebHackersWeapons" \\
  || miss "origin remote is not hahwul/WebHackersWeapons (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 45 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~15d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/hahwul/WebHackersWeapons"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

WebHackersWeapons is a curated directory of offensive security tools organized by language (Ruby, Python, Go, JavaScript, etc.) and vulnerability tags (XSS, CORS, subdomain enumeration, etc.). It serves as a searchable index and landing page for web hacking utilities—proxies, fuzzers, scanners, recon tools—rather than a toolkit library itself. The repo is a meta-collection of links with YAML-driven categorization in /categorize/langs/ and /categorize/tags/ directories. Flat hierarchical structure: /categorize/langs/ contains 14+ markdown files (Ruby.md, Python.md, Go.md, etc.), each listing tools by language; /categorize/tags/ contains 50+ markdown files (xss.md, asn.md, crawler.md, etc.) for cross-cutting vulnerability/capability tags. Main README links to both taxonomies. .github/workflows/ automates labeling and YAML validation. No src/, lib/, or code directories—purely documentation.

Security researchers, bug bounty hunters, and penetration testers who need a unified reference for finding specialized web hacking tools. They use this to quickly locate the right tool for a specific vulnerability class (e.g., blind XSS detection, cloud asset discovery, or CSP analysis) or preferred language/framework.

The repo is actively maintained (evident from CI/CD pipelines in .github/workflows/ including cd.yml, labeler.yml, and yaml-lint.yml) and follows a structured governance model (CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md present). However, this is a curated list project, not a production software library—it has no dependencies, tests, or releases; it's a living documentation project with community contributions.

No technical risk (no runtime dependencies or code execution). The main risk is curation decay: external tools linked from entries may become unmaintained, move URLs, or introduce vulnerabilities. Single maintainer (hahwul) is a risk for PR review speed. No FUNDING mechanism specified beyond GitHub Sponsors (.github/FUNDING.yml present), so sustainability is unclear.

Active maintenance of GitHub Actions workflows (yaml-lint.yml ensures config quality). The labeler.yml automation tags PRs. Based on file structure, the focus is growing the categorization (expanding tags/, langs/) and accepting community tool submissions. No specific milestones visible, but the presence of CONTRIBUTING.md and recent workflow configs suggests ongoing PR reviews.

Clone and browse locally: git clone https://github.com/hahwul/WebHackersWeapons.git && cd WebHackersWeapons && cat README.md. No build or install step—view markdown files directly in your editor or GitHub web UI. Optional: set up a local markdown viewer or use GitHub's native preview.

Daily commands: No runtime or server—this is a static documentation repo. To view: open /README.md in any markdown renderer, or browse at https://github.com/hahwul/WebHackersWeapons on GitHub. To validate changes locally, run YAML lint if you modify .github/ configs: yamllint -c .yamllint.yml .github/.

• README.md: Main entry point; defines the taxonomy structure and links to all categorization files
• categorize/langs/Ruby.md: Primary language category (11,802 bytes indicate this is the largest curated list); template for other language files
• categorize/tags/xss.md: Example tag file; demonstrates cross-cutting categorization by vulnerability type across languages
• .github/workflows/yaml-lint.yml: CI validation ensuring all YAML config remains valid; critical for repo reliability
• CONTRIBUTING.md: Defines submission guidelines for tools and tags; essential for maintainers and contributors
• .github/labeler.yml: Automation that categorizes PRs; reduces manual triage overhead

1. Adding a tool: Edit the relevant file in /categorize/langs/ (e.g., Python.md for a Python tool) or /categorize/tags/ (e.g., xss.md for XSS-detection tools). Follow the existing markdown format (name, link, description). 2. Creating a new tag: Add /categorize/tags/newtag.md following the template of existing tag files. 3. Updating README: Edit main README.md for major changes. Always run yamllint before committing to pass CI.

No environment variables, build tools, or external services required. YAML lint config (.yamllint.yml) is strict—ensure markdown frontmatter or embedded YAML in PRs passes validation. No code linting or spell-check automation is visible, so typos may slip through. The dual-taxonomy (langs + tags) can cause consistency issues if a tool is added to one but not cross-referenced in the other—no automation enforces this. Large Ruby.md file (11,802 bytes) may become unwieldy; no guidance on when to split categories.

• Taxonomy-driven Tool Discovery — WebHackersWeapons uses dual-axis categorization (language + vulnerability tag) to help users navigate 100+ tools; understanding this pattern is key to contributing effectively and using the repo at scale
• OWASP Top 10 Vulnerability Classes — Many tag files (xss.md, cors.md, 403.md, cache-vuln.md) map directly to OWASP categories; familiarity with these is essential to understand which tools target which flaws
• Reconnaissance & Asset Discovery — Several tag categories (asset-discovery.md, subdomains.md, dns.md, asn.md) cluster recon tools; understanding the attack surface mapping phase helps users select tools in sequence
• Man-in-the-Middle (MITM) Proxies — Multiple tools tagged with 'mitmproxy' (Burp Suite, Caido, ZAP) are core to web hacking workflows; the repo has a dedicated section for proxy addons that extend these
• Cloud Security & Infrastructure Scanning — Tags like 'cloud.md', 'aws.md', 'container-security.md' reflect modern attack surface; tools here target cloud-native applications rather than traditional web servers
• Fuzzing & Payload Generation — Several tool types (Fuzzer, param-discovery.md) rely on fuzzing; understanding payload mutation and coverage helps users choose between wordlist-based and generative fuzzers
• GitHub Actions Automation — CI workflows (yaml-lint.yml, labeler.yml, cd.yml) automate repo maintenance; understanding how to extend these is useful for maintaining a similar curated project or contributing robustly

• hahwul/MobileHackersWeapons — Sister project in the same family; applies identical taxonomy structure to mobile security tools (Android/iOS), showing the organization pattern's scalability
• danielmiessler/SecLists — Complementary curated list of security-specific wordlists, payloads, and patterns; used alongside WebHackersWeapons in many penetration testing workflows
• swisskyrepo/PayloadsAllTheThings — Curated techniques and payloads for common web vulnerabilities (SQLi, XSS, XXE); pairs well with WebHackersWeapons tools for exploitation
• projectdiscovery/nuclei — Template-driven vulnerability scanner that automates many discoveries; tools from WebHackersWeapons often feed data into Nuclei for validation
• OWASP/OWASP-Testing-Guide — Foundational methodology for web security testing; provides context for why many tools in WebHackersWeapons exist and how to apply them

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add automated tool validation workflow in CI/CD

The repo contains extensive categorized tool listings across 50+ tags and 20+ languages, but there's no CI workflow to validate that tool links are still active and metadata is consistent. This prevents link rot and ensures quality. A workflow similar to yaml-lint.yml could check for broken URLs, missing descriptions, and tag consistency.

• [ ] Create .github/workflows/tool-validation.yml that runs on PRs
• [ ] Write a validation script (Python or Node) that parses categorize/tags/.md and categorize/langs/.md files
• [ ] Validate that all tool URLs are reachable (with timeout/retry logic)
• [ ] Ensure each tool entry has required fields (name, description, language tags)
• [ ] Add the workflow status badge to README.md

Create AGENTS.md content scaffolding and indexing system

AGENTS.md exists in the file structure but is empty/sparse. Given the repo's focus on hacker tools and existing SECURITY.md and CONTRIBUTING.md, this file should document security agents/scanners and integrations. This would provide value to users looking for automated security tool chains.

• [ ] Analyze existing categorize/tags/ to identify security automation tools (dependency-scanning, fuzz, code-analysis, etc.)
• [ ] Create AGENTS.md with sections for: agent types, integration examples, and recommended tool chains
• [ ] Cross-reference tools from categorize/langs/ and categorize/tags/ directories in AGENTS.md
• [ ] Add a script to auto-generate an index in AGENTS.md from categorized tools

Add comprehensive tagging consistency and coverage report

The repo has 50+ tag files but no way to track which tools are missing tags, which tags are underutilized, or how tag coverage varies by language. This helps contributors understand where gaps exist and ensures consistent categorization across the collection.

• [ ] Create a Python/Node script in root or scripts/ directory that generates tag coverage statistics
• [ ] Script should output: tools missing tags, orphaned tags (< 2 tools), language-to-tag distribution matrix
• [ ] Add a docs/TAG_COVERAGE_REPORT.md file that is auto-generated and committed weekly via GitHub Actions
• [ ] Update CONTRIBUTING.md to reference tag guidelines and point contributors to coverage gaps
• [ ] Optional: Add a GitHub Issue template suggesting priority tag additions based on the report

• Add missing tags documentation: scan /categorize/tags/ for files that exist but lack tool descriptions or examples (e.g., check if blind-xss.md has recommended tools). Add 3–5 tools per empty tag with descriptions.
• Create a tool submission template: add a standard markdown snippet (e.g., # Tool Name\n- **Link**: \n- **Language**: \n- **Tags**: \n- **Description**:) to CONTRIBUTING.md to reduce inconsistent formatting in PRs.
• Audit and de-duplicate tools across language and tag files: write a script or manual check to find tools listed in Ruby.md that should also appear in relevant tag files (e.g., a Ruby XSS scanner in Ruby.md should be in tags/xss.md); report findings and propose cross-references.

This repository is a curated collection/documentation project with minimal security risk from its own code. The main security gaps are: (1) incomplete vulnerability disclosure policy in SECURITY.md, (2) lack of visible dependency management files for security scanning, and (3) inability to assess GitHub Actions workflow security. The project demonstrates basic security hygiene with contributing guidelines and code of conduct, but would benefit from a complete security policy, automated dependency scanning, and documented tool vetting procedures.

• Medium · Incomplete Security Policy — SECURITY.md. The SECURITY.md file contains a template security policy with placeholder text. The 'Reporting a Vulnerability' section uses generic instructions ('Use this section to tell people...') instead of providing specific security contact information or vulnerability disclosure process. Fix: Replace template text with actual security contact information (e.g., security@domain.com), define expected response timeframe, and establish clear vulnerability disclosure guidelines.
• Low · Missing Dependency Information — Repository root. No package manager files (package.json, requirements.txt, Gemfile, go.mod, etc.) were provided for analysis. This prevents assessment of third-party dependency vulnerabilities. Fix: Provide complete dependency files for all languages used in the project. Implement automated dependency scanning using tools like Dependabot, Snyk, or OWASP Dependency-Check in CI/CD pipeline.
• Low · Limited GitHub Actions Security Configuration — .github/workflows/. The repository uses GitHub Actions workflows (.github/workflows/) but without visibility into their content, it's unclear if they implement security best practices such as branch protection, code signing, or secret management. Fix: Implement branch protection rules, require code reviews, use GitHub secrets for sensitive data, pin action versions, and audit workflow permissions.
• Low · Documentation Repository Type — Repository structure. This appears to be a documentation/catalog repository (curated list of tools) rather than executable code. However, linked external tools may have security implications if recommended without proper vetting. Fix: Implement a vetting process for included tools, document security considerations for each tool, and maintain a changelog of tool updates with security advisories.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.