Armur-Ai/Pentest-Swarm-AI

Newcomers keep asking "which model should I use?" Let's answer it in one page — no Go required, just clear writing. Task: write docs/models.md — a "which model?" matrix — and link it from the README's LLM Providers section. What to cover A comparison table across the providers we support, with honest trade-offs: Claude — best quality, zero setup; may refuse some offensive-security prompts OpenAI-compatible (Together AI / DeepSeek / Groq) — cheaper, great for iteration OrcaRouter — one endpoint, many frontier models Gemini Ollama / LM Studio — 100% local, free, private; needs a GPU; lower scores Security-tuned open models (e.g. Pentest-R1) — purpose-built for offensive security. Pentest Swarm is the harness for these — bring the model, we give it hands. Suggested columns: quality · cost · privacy · offensive-prompt refusal · setup effort · best-for. Acceptance docs/models.md exists with the table + a short "our recommendation" paragraph Linked from the README

feroxbuster is a fast, recursive content-discovery tool (an alternative to gobuster/ffuf). Discovered paths become endpoints on the blackboard for the classifier and exploit agents to work. Why this is a great first issue: same small adapter pattern as the rest; a clean way to learn the codebase. What to do Copy internal/tools/nikto.go as your template: FeroxbusterTool struct + NewFeroxbusterTool() + Name() → "feroxbuster" IsAvailable() → IsCommandAvailable("feroxbuster") Run(ctx, target, opts) — scope-guard, run with --json --output <tmpfile> (feroxbuster emits JSON lines), parse each into a finding (one per discovered path with status + size; info/low). Expose wordlist, threads, depth options. Register in internal/tools/coordinator.go Dockerfile install line Tests mirroring internal/tools/nikto_test.go Tick it in IMPLEMENTATION_PLAN.md Acceptance go build ./..., go vet ./..., go test ./internal/tools/... green; visible in pentestswarm doctor. Questions welcome in Disco

wafw00f detects and fingerprints Web Application Firewalls. Knowing a WAF is in front of a target changes how the swarm should probe it — a useful signal on the blackboard. Why this is a great first issue: it follows the same ~30-line adapter pattern as every other tool; no swarm internals required. What to do Copy internal/tools/nikto.go as your template: Wafw00fTool struct + NewWafw00fTool() + Name() → "wafw00f" IsAvailable() → IsCommandAvailable("wafw00f") Run(ctx, target, opts) — scope-guard, run with -f json -o <tmpfile>, parse into []map[string]any (one finding: WAF detected + vendor, or "no WAF detected"; info severity) Register in internal/tools/coordinator.go Dockerfile install line (pip: wafw00f) Tests mirroring internal/tools/nikto_test.go Tick it in IMPLEMENTATION_PLAN.md Acceptance go build ./..., go vet ./..., go test ./internal/tools/... green; visible in pentestswarm doctor. Stuck? Discord. 🐝

whatweb fingerprints web technologies — CMS, frameworks, servers, JS libraries, analytics. It's high-signal recon: the classifier agent can correlate discovered versions against CVEs. Why this is a great first issue: every tool adapter follows one small, consistent pattern (~30 lines of real logic + a parser + tests). You don't touch the swarm internals. What to do Copy internal/tools/nikto.go as your template and adapt it: WhatWebTool struct + NewWhatWebTool() + Name() → "whatweb" IsAvailable() → IsCommandAvailable("whatweb") Run(ctx, target, opts) — scope-guard with getScopeFromContext, run with --log-json=<tmpfile>, parse the JSON into []map[string]any findings (one per detected technology; info/low severity — whatweb doesn't rate risk) Register NewWhatWebTool() in internal/tools/coordinator.go Add the install line to the Dockerfile Unit tests mirroring internal/tools/nikto_test.go (Name, IsAvailable, parse-with-findings, parse-empty, parse-malformed) Tick the adap