docs(skills): use current OWASP editions (Top 10:2025, API Top 10 2023)

AGENTS.md

@@ -15,6 +15,13 @@ npx skills add usestrix/strix
 - `fix-security-vulnerabilities-with-strix` — remediate findings and re-run Strix to verify
 - `ci-security-scanning-with-strix` — add PR scanning to CI/CD (self-hosted CLI or managed app)
 
+Target-specific workflows built on the same engine:
+
+- `web-app-penetration-testing` — black-box pentest of a live web app or staging site
+- `api-security-testing` — REST/GraphQL APIs and the OWASP API Security Top 10 (BOLA/IDOR, authz)
+- `owasp-top-10-testing` — systematic OWASP Top 10 assessment with honest per-category coverage
+- `find-security-vulnerabilities-in-code` — white-box review of a repo or working tree
+
 **Two ways to run, same engine — pick per situation:**
 
 - **Open-source CLI (self-hosted):** free, fully local, BYO LLM key, needs Docker. Best for local dev loops, air-gapped/offline, and full control.

README.md

@@ -116,7 +116,7 @@ Strix is agent-ready. Give Claude Code, Cursor, Codex, or any [SKILL.md-compatib
 npx skills add usestrix/strix
 ```
 
-This installs four skills: **penetration-testing-with-strix** (run headless scans and read results), **managed-pentesting-with-strix** (drive the managed [app.strix.ai](https://app.strix.ai) platform via REST — no local Docker or LLM key), **fix-security-vulnerabilities-with-strix** (remediate + re-scan to verify), and **ci-security-scanning-with-strix** (PR scanning in CI). Agents can run Strix two ways with the same engine — the open-source CLI locally, or the managed cloud when there's no local infra — and read [`AGENTS.md`](AGENTS.md) for a quick reference, [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) for the CLI docs, and [docs.app.strix.ai](https://docs.app.strix.ai) for the API.
+This installs eight skills: **penetration-testing-with-strix** (run headless scans and read results), **managed-pentesting-with-strix** (drive the managed [app.strix.ai](https://app.strix.ai) platform via REST — no local Docker or LLM key), **fix-security-vulnerabilities-with-strix** (remediate + re-scan to verify), **ci-security-scanning-with-strix** (PR scanning in CI), plus target-specific workflows: **web-app-penetration-testing**, **api-security-testing**, **owasp-top-10-testing**, and **find-security-vulnerabilities-in-code**. Agents can run Strix two ways with the same engine — the open-source CLI locally, or the managed cloud when there's no local infra — and read [`AGENTS.md`](AGENTS.md) for a quick reference, [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) for the CLI docs, and [docs.app.strix.ai](https://docs.app.strix.ai) for the API.
 
 ---
 

docs/advanced/configuration.mdx

@@ -8,7 +8,7 @@ Configure Strix using environment variables or a config file.
 ## LLM Configuration
 
 <ParamField path="STRIX_LLM" type="string" required>
-  Model name in LiteLLM format, such as `openai/gpt-5.4` or `anthropic/claude-sonnet-4-6`.
+  Model name in LiteLLM format (e.g., `openai/gpt-5.4`, `anthropic/claude-sonnet-4-6`).
 </ParamField>
 
 <ParamField path="LLM_API_KEY" type="string">
@@ -20,8 +20,8 @@ Configure Strix using environment variables or a config file.
 </ParamField>
 
 <ParamField path="LLM_EXTRA_HEADERS" type="string">
-  Extra HTTP headers sent on every LLM request as a JSON object, such as
-  `{"X-Feature-Key":"value","X-Tenant":"acme"}`. These headers help OpenAI-compatible
+  Extra HTTP headers sent on every LLM request, as a JSON object (e.g.
+  `{"X-Feature-Key":"value","X-Tenant":"acme"}`). Useful for OpenAI-compatible
   gateways that require attribution or routing headers in addition to the bearer
   token. The bearer token itself still comes from `LLM_API_KEY`. Applies to both
   the LiteLLM and native OpenAI routing paths.
@@ -65,8 +65,8 @@ affecting the agents that do the actual testing.
 
 <ParamField path="DEDUPE_LLM_EXTRA_HEADERS" type="string">
   Optional JSON object of extra HTTP headers sent on every deduplication-model
-  request, such as `{"X-Feature-Key":"value"}`. A dedicated dedupe model never
-  inherits `LLM_EXTRA_HEADERS`. Set this variable when its endpoint needs custom headers.
+  request, e.g. `{"X-Feature-Key":"value"}`. A dedicated dedupe model never
+  inherits `LLM_EXTRA_HEADERS`; set this when its endpoint needs custom headers.
 </ParamField>
 
 <ParamField path="STRIX_DEDUPE_REASONING_EFFORT" type="string">
@@ -81,7 +81,7 @@ affecting the agents that do the actual testing.
 </ParamField>
 
 <ParamField path="POSTMAN_API_KEY" type="string">
-  Postman API key (`PMAK-…`). Enables fetching Postman collections by ID as a target (`postman://<collection-uid>`), and Postman environments (`postman://<collection-uid>?env=<environment-uid>`) to resolve collection variables. Not needed when passing a local collection export file.
+  Postman API key (`PMAK-…`). Enables fetching Postman collections by id as a target (`postman://<collection-uid>`), and Postman environments (`postman://<collection-uid>?env=<environment-uid>`) to resolve collection variables. Not needed when passing a local collection export file.
 </ParamField>
 
 <ParamField path="STRIX_TELEMETRY" default="1" type="string">

docs/advanced/skills.mdx

@@ -3,11 +3,11 @@ title: "Skills"
 description: "Specialized knowledge packages that enhance agent capabilities"
 ---
 
-Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methods.
+Skills are structured knowledge packages that give Strix agents deep expertise in specific vulnerability types, technologies, and testing methodologies.
 
 ## The Idea
 
-LLMs have broad but shallow security knowledge. They know _about_ SQL injection but lack the nuanced techniques that experienced pentesters use, such as parser quirks, bypass methods, validation tricks, and chain attacks.
+LLMs have broad but shallow security knowledge. They know _about_ SQL injection, but lack the nuanced techniques that experienced pentesters use—parser quirks, bypass methods, validation tricks, and chain attacks.
 
 Skills inject this deep, specialized knowledge directly into the agent's context, transforming it from a generalist into a specialist for the task at hand.
 
@@ -25,9 +25,9 @@ create_agent(
 
 The skills are injected into the agent's system prompt, giving it access to:
 
-- **Advanced techniques:** Non-obvious methods beyond standard testing
-- **Working payloads:** Practical examples with variations
-- **Validation methods:** How to confirm findings and avoid false positives
+- **Advanced techniques** — Non-obvious methods beyond standard testing
+- **Working payloads** — Practical examples with variations
+- **Validation methods** — How to confirm findings and avoid false positives
 
 ## Skill Categories
 
@@ -138,7 +138,7 @@ How to confirm findings and avoid false positives.
 
 Community contributions are welcome. Create a `.md` file in the appropriate category with YAML frontmatter (`name` and `description` fields). Good skills include:
 
-1. **Real-world techniques:** Methods that work in practice
-2. **Practical payloads:** Working examples with variations
-3. **Validation steps:** How to confirm without false positives
-4. **Context awareness:** Version/environment-specific behavior
+1. **Real-world techniques** — Methods that work in practice
+2. **Practical payloads** — Working examples with variations
+3. **Validation steps** — How to confirm without false positives
+4. **Context awareness** — Version/environment-specific behavior

docs/cloud/overview.mdx

@@ -24,10 +24,10 @@ Skip the setup. Run Strix in the cloud at [app.strix.ai](https://app.strix.ai).
 
 ## What You Get
 
-- **Penetration test reports:** Validated findings with PoCs
-- **Shareable dashboards:** Collaborate with your team
-- **CI/CD integration:** Block risky changes automatically
-- **Continuous monitoring:** Catch new vulnerabilities quickly
+- **Penetration test reports** — Validated findings with PoCs
+- **Shareable dashboards** — Collaborate with your team
+- **CI/CD integration** — Block risky changes automatically
+- **Continuous monitoring** — Catch new vulnerabilities quickly
 
 ## Getting Started
 

docs/contributing.mdx

@@ -52,20 +52,20 @@ Skills are specialized knowledge packages that enhance agent capabilities. They
 
 1. Choose the right category
 2. Create a `.md` file with YAML frontmatter (`name` and `description` fields)
-3. Include practical examples, such as working payloads, commands, and test cases
+3. Include practical examples—working payloads, commands, test cases
 4. Provide validation methods to confirm findings
-5. Submit a pull request
+5. Submit via PR
 
 ## Contributing Code
 
 ### Pull Request Process
 
-1. **Create an issue first:** Describe the problem or feature
-2. **Fork and branch:** Work from `main`
-3. **Make changes:** Follow existing code style
-4. **Write tests:** Ensure coverage for new features
-5. **Run checks:** `make check-all` should pass
-6. **Submit a pull request:** Link to issue and provide context
+1. **Create an issue first** — Describe the problem or feature
+2. **Fork and branch** — Work from `main`
+3. **Make changes** — Follow existing code style
+4. **Write tests** — Ensure coverage for new features
+5. **Run checks** — `make check-all` should pass
+6. **Submit PR** — Link to issue and provide context
 
 ### Code Style
 
@@ -77,7 +77,7 @@ Skills are specialized knowledge packages that enhance agent capabilities. They
 
 ## Package Builds
 
-Editable installs do not require Go. They run the TUI from source (`go run`).
+Editable installs do not require Go; they run the TUI from source (`go run`).
 
 Wheels are intentionally strict: they always bundle the matching Go sidecar and
 are platform-specific.

docs/index.mdx

@@ -3,7 +3,7 @@ title: "Introduction"
 description: "Open-source AI hackers to secure your apps"
 ---
 
-Strix agents are autonomous and act like real hackers. They run your code dynamically, find vulnerabilities, and validate each vulnerability with a proof of concept. Strix helps developers and security teams that need fast and accurate security testing. Strix does not have the overhead of a manual pentest or the false positives of a static analysis tool.
+Strix are autonomous AI agents that act like real hackers—they run your code dynamically, find vulnerabilities, and validate them with proof-of-concepts. Built for developers and security teams who need fast, accurate security testing without the overhead of manual pentesting or the false positives of static analysis tools.
 
 <Frame>
   <img src="/images/screenshot.png" alt="Strix Demo" />
@@ -26,17 +26,17 @@ Strix agents are autonomous and act like real hackers. They run your code dynami
 
 ## Use Cases
 
-- **Application Security Testing:** Detect and validate critical vulnerabilities in your applications
-- **Rapid Penetration Testing:** Get penetration tests done in hours, not weeks
-- **Bug Bounty Automation:** Automate research and generate PoCs for faster reporting
-- **CI/CD Integration:** Block vulnerabilities before they reach production
+- **Application Security Testing** — Detect and validate critical vulnerabilities in your applications
+- **Rapid Penetration Testing** — Get penetration tests done in hours, not weeks
+- **Bug Bounty Automation** — Automate research and generate PoCs for faster reporting
+- **CI/CD Integration** — Block vulnerabilities before they reach production
 
 ## Key Capabilities
 
-- **Full hacker toolkit:** Browser automation, HTTP proxy, terminal, Python runtime
-- **Real validation:** PoCs, not false positives
-- **Multi-agent orchestration:** Specialized agents collaborate on complex targets
-- **Developer-first CLI:** Interactive TUI or headless mode for automation
+- **Full hacker toolkit** — Browser automation, HTTP proxy, terminal, Python runtime
+- **Real validation** — PoCs, not false positives
+- **Multi-agent orchestration** — Specialized agents collaborate on complex targets
+- **Developer-first CLI** — Interactive TUI or headless mode for automation
 
 ## Security Tools
 
@@ -67,9 +67,9 @@ Strix agents come equipped with a comprehensive toolkit:
 
 Strix uses a graph of specialized agents for comprehensive security testing:
 
-- **Distributed Workflows:** Specialized agents for different attacks and assets
-- **Scalable Testing:** Parallel execution for fast comprehensive coverage
-- **Dynamic Coordination:** Agents collaborate and share discoveries
+- **Distributed Workflows** — Specialized agents for different attacks and assets
+- **Scalable Testing** — Parallel execution for fast comprehensive coverage
+- **Dynamic Coordination** — Agents collaborate and share discoveries
 
 ## Quick Example
 

docs/integrations/coding-agents.mdx

@@ -7,7 +7,7 @@ Strix is built to be driven by AI coding agents. Install the official agent skil
 
 ## Install the Skills
 
-Works with any agent that supports the open [SKILL.md standard](https://agentskills.io), including Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more:
+Works with any agent that supports the open [SKILL.md standard](https://agentskills.io) — Claude Code, Cursor, Codex, Gemini CLI, OpenCode, and dozens more:
 
 ```bash
 npx skills add usestrix/strix
@@ -15,10 +15,14 @@ npx skills add usestrix/strix
 
 | Skill | What your agent learns |
 |-------|------------------------|
-| `penetration-testing-with-strix` | Run headless scans against code, URLs, domains, or IPs with the self-hosted CLI or the managed cloud, apply budget caps, and read the results |
-| `managed-pentesting-with-strix` | Drive the managed [app.strix.ai](https://app.strix.ai) platform over REST. No local Docker or LLM key needed |
+| `penetration-testing-with-strix` | Run headless scans against code, URLs, domains, or IPs — self-hosted CLI or managed cloud — with budget caps, and read the results |
+| `managed-pentesting-with-strix` | Drive the managed [app.strix.ai](https://app.strix.ai) platform over REST — no local Docker or LLM key needed |
 | `fix-security-vulnerabilities-with-strix` | Triage findings, fix root causes, and re-run Strix to verify each fix |
 | `ci-security-scanning-with-strix` | Add PR security scanning to GitHub Actions or any CI (self-hosted CLI or managed app) |
+| `web-app-penetration-testing` | Black-box pentest of a live web app or staging site — scope, credentials, and multi-account access-control testing |
+| `api-security-testing` | Test a REST/GraphQL API against the OWASP API Security Top 10 — schema-driven enumeration, BOLA/IDOR, authz |
+| `owasp-top-10-testing` | Systematic OWASP Top 10 assessment with honest per-category coverage |
+| `find-security-vulnerabilities-in-code` | White-box security review of a repo or working tree, with exploits to confirm findings |
 
 Install a single skill with `npx skills add usestrix/strix --skill penetration-testing-with-strix`, or use one without installing:
 
@@ -26,25 +30,23 @@ Install a single skill with `npx skills add usestrix/strix --skill penetration-t
 npx skills use usestrix/strix@penetration-testing-with-strix | claude
 ```
 
-## Two ways to run: self-hosted or managed
+## Two ways to run — self-hosted or managed
 
-Both use the same engine and produce the same validated findings and SARIF. Agents can pick per situation or combine them.
+Both use the same engine and produce the same validated findings and SARIF, so agents can pick per situation or combine them:
 
-- **Open-source CLI (self-hosted):** Runs locally in a Docker sandbox with your own LLM key. It is free, fully local, and air-gap capable. It suits local development loops and full control.
-- **Managed cloud:** Runs on Strix infrastructure through the [app.strix.ai REST API](https://docs.app.strix.ai). It needs no Docker, LLM key, or local installation. The Enterprise plan adds team dashboards, scheduling, pull request reviews, and downloadable PDF or DOCX reports. It suits sandboxed or CI environments and teams.
-
-Create a managed API token under **Settings → API Access**. The `managed-pentesting-with-strix` skill documents the full flow.
+- **Open-source CLI (self-hosted)** — runs locally in a Docker sandbox with your own LLM key. Free, fully local, air-gap capable. Best for local dev loops and full control.
+- **Managed cloud** — runs on Strix's infrastructure via the [app.strix.ai REST API](https://docs.app.strix.ai). No Docker, no LLM key, no local install; adds team dashboards, scheduling, PR reviews, and downloadable PDF/DOCX reports (Enterprise plan). Best in sandboxed/CI environments and for teams. Create an API token under **Settings → API Access**; the `managed-pentesting-with-strix` skill has the full flow.
 
 ## Agent-Friendly Interfaces
 
 Everything an agent needs is machine-readable:
 
-- **Headless CLI:** `strix -n` runs without the TUI. It exits with `0` for a clean scan, `1` for an error, or `2` for vulnerabilities.
-- **REST API:** The managed platform exposes a documented [OpenAPI](https://docs.app.strix.ai/openapi.json) at `https://app.strix.ai/api/v1`. It supports scans, vulnerabilities, assets, pull request reviews, schedules, and webhooks. The API uses bearer tokens and scopes.
-- **Structured results:** Each self-hosted run writes `vulnerabilities.json`, `vulnerabilities.csv`, and `findings.sarif` in SARIF 2.1.0 format. It also writes per-finding Markdown under `strix_runs/<run-name>/`. The cloud exposes the same data as JSON and provides SARIF export.
-- **Budget controls:** `--max-budget` and `--max-turns` set cost and turn limits.
-- **`AGENTS.md`:** The [repository's agent guide](https://github.com/usestrix/strix/blob/main/AGENTS.md) provides a quick reference.
-- **`llms.txt`:** The index is available at [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt). The full export is available at [docs.strix.ai/llms-full.txt](https://docs.strix.ai/llms-full.txt). Every page is also available as Markdown by appending `.md` to its URL.
+- **Headless CLI** — `strix -n` runs without the TUI and exits with `0` (clean), `1` (error), or `2` (vulnerabilities found).
+- **REST API** — the managed platform exposes a documented [OpenAPI](https://docs.app.strix.ai/openapi.json) at `https://app.strix.ai/api/v1` (scans, vulnerabilities, assets, PR reviews, schedules, webhooks) with bearer tokens and scopes.
+- **Structured results** — every run writes `vulnerabilities.json`, `vulnerabilities.csv`, `findings.sarif` (SARIF 2.1.0), and per-finding Markdown under `strix_runs/<run-name>/`; the cloud exposes the same as JSON plus SARIF export.
+- **Budget controls** — `--max-budget` and `--max-turns` give agents hard cost/time caps.
+- **`AGENTS.md`** — the [repository's agent guide](https://github.com/usestrix/strix/blob/main/AGENTS.md) with a quick reference.
+- **`llms.txt`** — this documentation is indexed at [docs.strix.ai/llms.txt](https://docs.strix.ai/llms.txt) and fully exported at [docs.strix.ai/llms-full.txt](https://docs.strix.ai/llms-full.txt); every page is also available as Markdown by appending `.md` to its URL.
 
 ## Example Prompts
 

docs/integrations/github-actions.mdx

@@ -37,7 +37,7 @@ Add these secrets to your repository:
 
 | Secret | Description |
 |--------|-------------|
-| `STRIX_LLM` | Model name, such as `openai/gpt-5.4` |
+| `STRIX_LLM` | Model name (e.g., `openai/gpt-5.4`) |
 | `LLM_API_KEY` | API key for your LLM provider |
 
 ## Exit Codes
@@ -46,8 +46,8 @@ The workflow fails when vulnerabilities are found:
 
 | Code | Result |
 |------|--------|
-| 0 | Pass. No vulnerabilities found |
-| 2 | Fail. Vulnerabilities found |
+| 0 | Pass — No vulnerabilities |
+| 2 | Fail — Vulnerabilities found |
 
 ## Scan Modes for CI
 
@@ -62,5 +62,5 @@ Use `quick` mode for PRs to keep feedback fast. Schedule `deep` scans nightly.
 </Tip>
 
 <Note>
-For `pull_request` workflows, Strix automatically uses changed-files diff-scope in CI/headless runs. If diff resolution fails, fetch full history with `fetch-depth: 0` or set `--diff-base`.
+For pull_request workflows, Strix automatically uses changed-files diff-scope in CI/headless runs. If diff resolution fails, ensure full history is fetched (`fetch-depth: 0`) or set `--diff-base`.
 </Note>

docs/llm-providers/azure.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Azure OpenAI"
-description: "Configure Strix with OpenAI models through Azure"
+description: "Configure Strix with OpenAI models via Azure"
 ---
 
 ## Setup
@@ -19,7 +19,7 @@ export AZURE_API_VERSION="2025-11-01-preview"
 | `STRIX_LLM` | `azure/<your-deployment-name>` |
 | `AZURE_API_KEY` | Your Azure OpenAI API key |
 | `AZURE_API_BASE` | Your Azure OpenAI endpoint URL |
-| `AZURE_API_VERSION` | API version, such as `2025-11-01-preview` |
+| `AZURE_API_VERSION` | API version (e.g., `2025-11-01-preview`) |
 
 ## Example
 
@@ -33,5 +33,5 @@ export AZURE_API_VERSION="2025-11-01-preview"
 ## Prerequisites
 
 1. Create an Azure OpenAI resource
-2. Deploy a model, such as GPT-5.4
+2. Deploy a model (e.g., GPT-5.4)
 3. Get the endpoint URL and API key from the Azure portal

docs/llm-providers/bedrock.mdx

@@ -1,6 +1,6 @@
 ---
 title: "AWS Bedrock"
-description: "Configure Strix with models through AWS Bedrock"
+description: "Configure Strix with models via AWS Bedrock"
 ---
 
 ## Installation
@@ -17,7 +17,7 @@ pipx install "strix-agent[bedrock]"
 export STRIX_LLM="bedrock/anthropic.claude-4-5-sonnet-20251022-v1:0"
 ```
 
-Strix does not require an API key. Strix uses AWS credentials from the environment.
+No API key required—uses AWS credentials from environment.
 
 ## Authentication
 

docs/llm-providers/local.mdx

@@ -17,7 +17,7 @@ Running Strix with local models allows for completely offline, privacy-first sec
 <Warning>
 **Compatibility Note**: Strix relies on advanced agentic capabilities (tool use, multi-step planning, self-correction). Most local models, especially those under 70B parameters, struggle with these complex tasks.
 
-For critical assessments, use state-of-the-art cloud models such as **Claude 4.5 Sonnet** or **GPT-5**. Use local models only when privacy is the absolute priority.
+For critical assessments, we strongly recommend using state-of-the-art cloud models like **Claude 4.5 Sonnet** or **GPT-5**. Use local models only when privacy is the absolute priority.
 </Warning>
 
 ## Ollama
@@ -40,6 +40,8 @@ For critical assessments, use state-of-the-art cloud models such as **Claude 4.5
 ### Recommended Models
 
 We recommend these models for the best balance of reasoning and tool use:
+
+**Recommended models:**
 - **Qwen3 VL** (`ollama pull qwen3-vl`)
 - **DeepSeek V3.1** (`ollama pull deepseek-v3.1`)
 - **Devstral 2** (`ollama pull devstral-2`)
@@ -57,7 +59,7 @@ export LLM_API_BASE="http://localhost:1234/v1"  # Adjust port as needed
 
 Some OpenAI-compatible gateways require extra HTTP headers (for attribution or
 tenant routing) alongside the bearer token. Set them with `LLM_EXTRA_HEADERS` as
-a JSON object. Strix sends these headers on every request:
+a JSON object — they are sent on every request:
 
 ```bash
 export STRIX_LLM="openai/your-model"
@@ -67,12 +69,12 @@ export LLM_EXTRA_HEADERS='{"X-Feature-Key":"value","X-Tenant":"acme"}'
 ```
 
 For endpoints behind a private CA, point Strix at your certificate bundle with
-the standard `SSL_CERT_FILE=/path/to/ca-bundle.pem`. Do not disable TLS
+the standard `SSL_CERT_FILE=/path/to/ca-bundle.pem` — never disable TLS
 verification against a real endpoint.
 
 ## Tool calling must return structured `tool_calls`
 
-Strix is entirely tool-driven. Every working turn must be a **native** function or tool call. If the inference server returns the call as plain assistant text, Strix never sees a call it can execute. The agent makes no real progress and gives up after its recovery attempts end.
+Strix is entirely tool-driven: every working turn must be a **native** function/tool call. If your inference server returns the tool call as plain assistant text instead of a structured `tool_calls` field, Strix never sees a call it can execute, so the agent makes no real progress — it re-prompts the model for a tool call and gives up once its recovery attempts are exhausted.
 
 This is almost always an **inference-server configuration** problem, not a model or Strix problem. Common symptoms are the model printing a call as text such as:
 
@@ -82,19 +84,19 @@ exec_command(cmd="nmap ...", timeout=180)
 {"action": "exec_command", "params": {"cmd": "nmap ..."}}
 ```
 
-The fix belongs on the inference server. It must be configured to parse the model's tool tokens into structured `tool_calls`. A correctly configured endpoint either returns a structured call or rejects the request outright. It never leaks the call as text.
+The fix belongs on the inference server: it must be configured to parse the model's tool tokens into structured `tool_calls`. A correctly configured endpoint either returns a structured call or rejects the request outright — it never leaks the call as text.
 
 ### Fixes by server
 
 **llama.cpp (`llama-server`)**
-- Run with `--jinja` and a correct tool-use chat template (`--chat-template` or `--chat-template-file` matching the model). Recent builds enable `--jinja` by default. Upgrade if yours does not.
-- For thinking models, align or disable reasoning (`--reasoning-format` or `-rea off`) so it does not break tool-call parsing.
-- A low temperature, such as `--temp 0.2`, improves tool-call reliability.
+- Run with `--jinja` and a correct tool-use chat template (`--chat-template` / `--chat-template-file` matching the model). Recent builds enable `--jinja` by default — **upgrade** if yours doesn't.
+- For thinking models, align or disable reasoning (`--reasoning-format`, `-rea off`) so it doesn't break tool-call parsing.
+- A low temperature (e.g. `--temp 0.2`) improves tool-call reliability.
 
 **Ollama**
-- Use a recent Ollama and a model whose template wires tools. Modern Ollama returns `tools param requires --jinja flag` if the template lacks tool support.
-- For reasoning models such as qwen3, disable the model's **thinking** mode. Thinking left on can push the tool call into `content` instead of the structured `tool_calls` field. Turn it off on the Ollama side with a non-thinking model variant, `think: false` in the model's parameters, or `Modelfile`.
-- Raise **`num_ctx`** to at least 16k to 32k. Strix sends a large system prompt plus many tool schemas. At Ollama's small default context, the tool definitions can be truncated from the prompt. The model can then stop emitting valid calls. A short test prompt can look fine while a real scan fails. Set this explicitly instead of inferring it from a quick check.
+- Use a recent Ollama and a model whose template wires tools. Modern Ollama refuses tools (`tools param requires --jinja flag`) if the template lacks tool support.
+- For reasoning models (e.g. qwen3), disable the model's **thinking** mode — thinking left on frequently pushes the tool call into the text `content` instead of the structured `tool_calls` field. Turn it off on the Ollama side (a non-thinking model variant, or `think: false` in the model's parameters / `Modelfile`).
+- Raise **`num_ctx`** to at least 16k–32k. Strix sends a large system prompt plus many tool schemas; at Ollama's small default context the tool definitions are truncated out of the prompt and the model stops emitting valid calls. A short test prompt can look fine while a real scan fails, so set this explicitly rather than inferring it from a quick check.
 
 **vLLM**
 - Start with `--enable-auto-tool-choice`, a matching `--tool-call-parser` (`hermes`, `qwen3_xml`, or `llama3_json`), and a matching `--reasoning-parser` for reasoning models.

docs/llm-providers/novita.mdx

@@ -3,7 +3,7 @@ title: "Novita AI"
 description: "Configure Strix with Novita AI models"
 ---
 
-[Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models through an OpenAI-compatible API.
+[Novita AI](https://novita.ai) provides fast, cost-efficient inference for open-source models via an OpenAI-compatible API.
 
 ## Setup
 
@@ -29,7 +29,7 @@ export LLM_API_BASE="https://api.novita.ai/openai"
 
 ## Benefits
 
-- **Cost-efficient:** Competitive pricing with per-token billing
-- **OpenAI-compatible:** Drop-in replacement using `LLM_API_BASE`
-- **Large context:** Models support up to 262k token context windows
-- **Function calling:** All listed models support tool/function calling
+- **Cost-efficient** — Competitive pricing with per-token billing
+- **OpenAI-compatible** — Drop-in replacement using `LLM_API_BASE`
+- **Large context** — Models support up to 262k token context windows
+- **Function calling** — All listed models support tool/function calling

docs/llm-providers/openrouter.mdx

@@ -1,6 +1,6 @@
 ---
 title: "OpenRouter"
-description: "Configure Strix with models through OpenRouter"
+description: "Configure Strix with models via OpenRouter"
 ---
 
 [OpenRouter](https://openrouter.ai) provides access to 100+ models from multiple providers through a single API.
@@ -31,7 +31,7 @@ Access any model on OpenRouter using the format `openrouter/<provider>/<model>`:
 
 ## Benefits
 
-- **Single API:** Access models from OpenAI, Anthropic, Google, Meta, and more
-- **Fallback routing:** Automatic failover between providers
-- **Cost tracking:** Monitor usage across all models
-- **Higher rate limits:** OpenRouter handles provider limits for you
+- **Single API** — Access models from OpenAI, Anthropic, Google, Meta, and more
+- **Fallback routing** — Automatic failover between providers
+- **Cost tracking** — Monitor usage across all models
+- **Higher rate limits** — OpenRouter handles provider limits for you

docs/llm-providers/overview.mdx

@@ -44,13 +44,13 @@ See the [Local Models guide](/llm-providers/local) for setup instructions and re
     Access 100+ models through a single API.
   </Card>
   <Card title="Google Vertex AI" href="/llm-providers/vertex">
-    Gemini 3 models through Google Cloud.
+    Gemini 3 models via Google Cloud.
   </Card>
   <Card title="AWS Bedrock" href="/llm-providers/bedrock">
-    Claude and Titan models through AWS.
+    Claude and Titan models via AWS.
   </Card>
   <Card title="Azure OpenAI" href="/llm-providers/azure">
-    GPT-5.4 through Azure.
+    GPT-5.4 via Azure.
   </Card>
   <Card title="Local Models" href="/llm-providers/local">
     Llama 4, Mistral, and self-hosted models.

docs/llm-providers/vertex.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Google Vertex AI"
-description: "Configure Strix with Gemini models through Google Cloud"
+description: "Configure Strix with Gemini models via Google Cloud"
 ---
 
 ## Installation
@@ -17,7 +17,7 @@ pipx install "strix-agent[vertex]"
 export STRIX_LLM="vertex_ai/gemini-3-pro-preview"
 ```
 
-Strix does not require an API key. Strix uses Google Cloud Application Default Credentials.
+No API key required—uses Google Cloud Application Default Credentials.
 
 ## Authentication
 

docs/quickstart.mdx

@@ -6,8 +6,7 @@ description: "Install Strix and run your first security scan"
 ## Prerequisites
 
 - Docker (running)
-- Access to a [supported LLM provider](/llm-providers/overview), such as OpenAI, Anthropic, or Google
-- Most providers require an API key. Vertex and Bedrock use cloud credentials.
+- An LLM API key from any [supported provider](/llm-providers/overview) (OpenAI, Anthropic, Google, etc.)
 
 ## Installation
 
@@ -44,7 +43,7 @@ strix --target ./your-app
 ```
 
 <Note>
-The first run pulls the Docker sandbox image automatically. Strix saves results to `strix_runs/<run-name>`.
+First run pulls the Docker sandbox image automatically. Results are saved to `strix_runs/<run-name>`.
 </Note>
 
 ## Target Types

docs/tools/browser.mdx

@@ -3,7 +3,7 @@ title: "Browser"
 description: "Playwright-powered Chrome for web application testing"
 ---
 
-Strix uses a headless Chrome browser through Playwright to interact with web applications exactly like a real user would.
+Strix uses a headless Chrome browser via Playwright to interact with web applications exactly like a real user would.
 
 ## How It Works
 

docs/tools/overview.mdx

@@ -28,6 +28,6 @@ Strix agents use specialized tools to test your applications like a real penetra
 | -------------- | ---------------------------------------- |
 | Python Runtime | Write and execute custom exploit scripts |
 | File Editor    | Read and modify source code              |
-| Web Search     | Real-time OSINT through Perplexity       |
+| Web Search     | Real-time OSINT via Perplexity           |
 | Notes          | Document findings during the scan        |
 | Reporting      | Generate vulnerability reports with PoCs |

docs/tools/proxy.mdx

@@ -70,9 +70,10 @@ asyncio.run(main())
 | `view_sitemap_entry()` | Inspect one sitemap entry + its related requests |
 | `scope_rules()`        | Manage proxy scope (allowlist/denylist)    |
 
-For one-off arbitrary requests, use shell tools such as `curl`.
-The sandbox routes traffic through Caido with the `HTTP_PROXY` variable.
-Caido then adds each request to `list_requests` for replay through `repeat_request`.
+For one-off arbitrary requests, use shell tooling like `curl` — the
+sandbox's `HTTP_PROXY` env routes the traffic through Caido
+automatically, so it lands in `list_requests` and can be replayed via
+`repeat_request`.
 
 ### Example: Automated IDOR Testing
 
@@ -105,24 +106,24 @@ asyncio.run(main())
 
 ## Human-in-the-Loop
 
-Strix exposes the Caido proxy to your host machine, so you can interact with it alongside the automated scan. When the sandbox starts, the Caido URL is displayed in the TUI sidebar. Click the URL to copy it, then open it in Caido Desktop.
+Strix exposes the Caido proxy to your host machine, so you can interact with it alongside the automated scan. When the sandbox starts, the Caido URL is displayed in the TUI sidebar — click it to copy, then open it in Caido Desktop.
 
 ### Accessing Caido
 
 1. Start a scan as usual
-2. Find the **Caido** URL in the sidebar stats panel, such as `localhost:52341`
+2. Look for the **Caido** URL in the sidebar stats panel (e.g. `localhost:52341`)
 3. Open the URL in Caido Desktop
 4. Click **Continue as guest** to access the instance
 
 ### What You Can Do
 
-- **Inspect traffic:** Browse all HTTP/HTTPS requests the agent is making in real time
-- **Replay requests:** Take any captured request and resend it with your own modifications
-- **Intercept and modify:** Pause requests mid-flight, edit them, then forward
-- **Explore the sitemap:** See the full attack surface the agent has discovered
-- **Manual testing:** Use Caido's tools to test findings the agent reports, or explore areas it has not reached
+- **Inspect traffic** — Browse all HTTP/HTTPS requests the agent is making in real time
+- **Replay requests** — Take any captured request and resend it with your own modifications
+- **Intercept and modify** — Pause requests mid-flight, edit them, then forward
+- **Explore the sitemap** — See the full attack surface the agent has discovered
+- **Manual testing** — Use Caido's tools to test findings the agent reports, or explore areas it hasn't reached
 
-Strix is a collaborative tool, not only a fully automated scanner. The agent handles the heavy lifting while you focus on the interesting parts.
+This turns Strix from a fully automated scanner into a collaborative tool — the agent handles the heavy lifting while you focus on the interesting parts.
 
 ## Scope
 

docs/usage/cli.mdx

@@ -14,14 +14,14 @@ strix (--target <target> | --target-list <path>) [options]
 <ParamField path="--target, -t" type="string">
   Target to test. Accepts URLs, repositories, local directories, domains, IP addresses, API spec files (OpenAPI/Swagger `.json`/`.yaml`, a Postman collection export), or a live Postman collection by id (`postman://<collection-uuid>`). Can be specified multiple times. Fresh runs require at least one target source: `--target` or `--target-list`.
 
-  When the target is an API spec, Strix copies it into the agent workspace and authorizes its declared base URLs as in-scope hosts. Strix also authorizes base URLs that it resolves from a Postman environment. The agent then reads the contract and tests the full declared surface instead of finding endpoints by crawling. Pair the spec with the deployed base URL, such as `--target ./openapi.yaml --target https://api.example.com`, so the agent has a reachable host to attack.
+  When the target is an API spec, Strix copies it into the agent's workspace and authorizes the base URLs it declares (including those resolved from a Postman environment) as in-scope hosts - so the agent reads the contract and tests the full declared surface instead of discovering endpoints by crawling. Pair the spec with the deployed base URL (e.g. `--target ./openapi.yaml --target https://api.example.com`) so the agent has a reachable host to attack.
 
   <Note>
     A local directory is mounted into the sandbox live and **writable**, so the agent edits your real files (`.git` excepted). Commit or stash first.
   </Note>
 
   <Note>
-    Fetching a Postman collection by ID requires `POSTMAN_API_KEY`. Add `?env=<environment-uuid>` to also fetch a Postman environment, which resolves the `{{baseUrl}}` and token variables that the collection references. Use a target such as `postman://<collection-uuid>?env=<environment-uid>`.
+    Fetching a Postman collection by id requires `POSTMAN_API_KEY`. Add `?env=<environment-uuid>` to also pull a Postman environment, which resolves `{{baseUrl}}` / token variables the collection references (e.g. `postman://<collection-uuid>?env=<environment-uid>`).
   </Note>
 </ParamField>
 
@@ -46,7 +46,7 @@ strix (--target <target> | --target-list <path>) [options]
 </ParamField>
 
 <ParamField path="--diff-base" type="string">
-  Target branch or commit to compare against, such as `origin/main`. Defaults to the repository's default branch.
+  Target branch or commit to compare against (e.g., `origin/main`). Defaults to the repository's default branch.
 </ParamField>
 
 <ParamField path="--non-interactive, -n" type="boolean">
@@ -88,8 +88,8 @@ strix (--target <target> | --target-list <path>) [options]
     slightly overshoot the limit by any calls already in flight when the
     threshold is crossed (most relevant with several child agents running
     concurrently).
-  - Cost is a best-effort estimate derived from token usage and model pricing.
-    Providers that do not expose priced usage may under-count.
+  - Cost is a best-effort estimate derived from token usage and model pricing;
+    providers that do not expose priced usage may under-count.
   - For LiteLLM-routed models, Strix enables streaming success callbacks to
     capture provider-reported cost. Message content remains excluded, but
     third-party LiteLLM callbacks configured in the same process can receive
@@ -148,6 +148,6 @@ strix --target-list ./targets.txt
 
 | Code | Meaning |
 |------|---------|
-| 0 | Interactive mode always exits with `0`. In headless mode, `0` means that no vulnerabilities were found. |
-| 1 | A fatal error occurred before or during the scan. Causes include missing environment variables, unavailable Docker, an invalid config file, diff-scope resolution failure, or an unhandled error. |
+| 0 | Scan completed successfully (interactive mode always exits `0`; in headless mode, `0` means no vulnerabilities were found) |
+| 1 | A fatal error occurred before or during the scan (e.g. missing environment variables, Docker unavailable, invalid config file, diff-scope resolution failure, or an unhandled error) |
 | 2 | Vulnerabilities found (headless mode only) |

skills/api-security-testing/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: api-security-testing
+description: Security-test a REST, GraphQL, or gRPC API with Strix — autonomous agents that enumerate endpoints from an OpenAPI/GraphQL schema (or by crawling), then actually exploit the API-specific vulnerability classes in the OWASP API Security Top 10 (2023) — broken object-level authorization (BOLA/IDOR), broken object property level authorization (excessive data exposure and mass assignment), broken function-level authorization, unrestricted resource consumption, SSRF, injection, and auth/token flaws. Every finding comes with a working proof-of-concept request. Use when the user asks to pentest, security-test, audit, or find vulnerabilities in an API, endpoint, or backend service.
+license: Apache-2.0
+metadata:
+  author: usestrix
+  homepage: https://docs.strix.ai
+---
+
+# Security-test an API
+
+APIs fail differently from web UIs: there's no rendered surface to crawl, the interesting bugs are authorization-shaped rather than injection-shaped, and the same endpoint behaves differently per token. This workflow targets those specifics with Strix's autonomous agents, using the current [OWASP API Security Top 10 (2023)](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) as the coverage checklist. For the web-app equivalent, the current edition is the OWASP Top 10:2025 — see **owasp-top-10-testing**.
+
+Install, LLM setup, full CLI flags, and the managed-cloud path are in the **penetration-testing-with-strix** skill. Read it if `strix --version` fails or the target isn't an API.
+
+## 1. Gather what the agents need
+
+APIs are near-impossible to test blind, so collect first:
+
+| Input | Why it matters |
+|---|---|
+| **Schema** — OpenAPI/Swagger URL or file, GraphQL endpoint (introspection), or `.proto` | Turns guesswork into full endpoint enumeration. Biggest single win in coverage. |
+| **Two sets of credentials/tokens**, ideally in different tenants | BOLA/IDOR — API1:2023, still the #1 API risk — can only be *proven* by accessing tenant A's objects with tenant B's token. |
+| **A low-privilege and a high-privilege token** | Required to prove broken function-level authorization (API5:2023 — a `user` calling admin-only routes). |
+| **Example object IDs** | Lets agents test ID tampering immediately instead of hunting for valid identifiers. |
+| **Out-of-scope routes** | Payments, mass notification, destructive admin endpoints. |
+| **Rate limits / WAF** in front of the API | Avoids agents burning budget on throttled requests; mention them so testing adapts. |
+
+Ask the user for anything missing — don't fabricate tokens or scan an API they don't own.
+
+## 2. Run the scan
+
+```bash
+strix -n -t https://api.staging.example.com --max-budget 20 \
+  --instruction "OpenAPI spec: https://api.staging.example.com/openapi.json.
+Tenant A token: <tokenA> (org 1111, user id 11, order id 501).
+Tenant B token: <tokenB> (org 2222, user id 22).
+Admin token: <tokenAdmin>.
+Focus: BOLA across orgs (API1), function-level authz on /admin/* (API5), object property level authz on PATCH /users/{id} — both mass assignment and over-exposed fields in list responses (API3), unrestricted resource consumption (API4).
+Out of scope: POST /billing/*, POST /notifications/broadcast."
+```
+
+- **Add the backend source for depth:** `-t ./services/api -t https://api.staging.example.com`. With code access the agents can reason about authorization checks and object ownership rather than inferring them from responses.
+- **GraphQL:** point at the GraphQL endpoint and say whether introspection is enabled; call out that you want batching/aliasing abuse, depth/complexity limits, and per-field authorization tested.
+- **Internal/private APIs** unreachable from your machine: use the managed platform's network connector — see **managed-pentesting-with-strix**.
+- Use `--instruction-file` when the credential/context block gets long, and keep tokens out of shell history and out of committed files.
+
+## 3. Verify findings
+
+`strix_runs/<run>/penetration_test_report.md` first, then `vulnerabilities/*.md` — each contains the exact request that proved the issue. Replay it (e.g. with `curl`) before reporting; for authorization findings, confirm the response really contains the other tenant's data rather than an empty 200.
+
+`findings.sarif` uploads to GitHub code scanning; `vulnerabilities.json` is the structured index for ticketing.
+
+## 4. Fix, re-test, and keep it tested
+
+Remediate with **fix-security-vulnerabilities-with-strix** (fix the authorization check, not the single endpoint), then re-run against the same target to prove the exploit is dead. Wire it into pull-request CI with **ci-security-scanning-with-strix** so new endpoints get tested as they ship.

skills/find-security-vulnerabilities-in-code/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: find-security-vulnerabilities-in-code
+description: Find security vulnerabilities in a codebase or repository with Strix — a white-box AI security review that reads your source, reasons about the actual data flow and authorization model, then exploits what it finds in a live sandbox so every reported issue has a working proof-of-concept instead of a noisy static-analysis alert. Covers injection, XSS, SSRF, broken access control and IDOR, insecure deserialization, secrets in code, unsafe dependencies, and business-logic flaws. Use when the user asks to security-scan, security-review, or audit their code, repo, or pull request for vulnerabilities.
+license: Apache-2.0
+metadata:
+  author: usestrix
+  homepage: https://docs.strix.ai
+---
+
+# Find security vulnerabilities in code
+
+White-box security review with Strix: the agents read the source to build a model of routes, sinks, and authorization checks, then attempt real exploitation. Findings come with a proof-of-concept, so the output is a short list of proven issues rather than the hundreds of "potential" hits a pattern-matching scanner produces.
+
+Install, LLM setup, all flags, and the managed-cloud path are in the **penetration-testing-with-strix** skill.
+
+## Run it
+
+```bash
+# Local working tree
+strix -n -t ./ --scan-mode standard --max-budget 15
+
+# A GitHub repo directly
+strix -n -t https://github.com/org/app --max-budget 15
+
+# Large monorepo: bind-mount instead of copying in
+strix -n --mount ./huge-monorepo --max-budget 20
+```
+
+Two things sharply improve results:
+
+1. **Add a running instance of the app.** `-t ./ -t http://host.docker.internal:3000` lets the agents confirm exploitability against live behavior instead of reasoning about it statically — this is the difference between "this looks unsafe" and a validated finding. If nothing is running, static-only findings should be described as unconfirmed.
+2. **Scope the review.** Point at the risky subtree and say what matters:
+   ```bash
+   strix -n -t ./services/api --max-budget 15 \
+     --instruction "Focus on the authorization layer in src/auth and every route under src/routes/admin. Multi-tenant app: tenant id comes from the JWT. Flag any query that filters by object id without also filtering by tenant."
+   ```
+   Tenancy model, trust boundaries, and which inputs are attacker-controlled are things the agents can't infer reliably — tell them.
+
+## Reviewing a pull request instead of the whole repo
+
+For diff-scoped review of a branch or PR (and blocking merges on findings), use **ci-security-scanning-with-strix** — it covers diff scoping, PR comments, and SARIF upload to GitHub code scanning. The managed platform can also review PRs directly via API (**managed-pentesting-with-strix**).
+
+## Read the results
+
+In `strix_runs/<run>/`: `penetration_test_report.md` (start here), `vulnerabilities/*.md` (one per finding, with PoC and remediation), `vulnerabilities.json` / `.csv`, `findings.sarif` (upload to code scanning), `run.json`.
+
+Before reporting to the user, open each finding and check the PoC actually demonstrates impact. Report file and line alongside the exploit so the fix is obvious.
+
+Exit `0` means nothing exploitable was proven in what was analyzed — not that the codebase is clean. Check `run.json` status and cost against `--max-budget`, and note which paths went unreviewed if the run was capped.
+
+## Complementary tooling
+
+This is exploit-validated review, not an exhaustive inventory. Keep a dependency scanner (SCA) and secret scanning in place for complete coverage of known-CVE dependencies and committed credentials; use this for the logic, authorization, and injection bugs those tools structurally can't find.
+
+## Fix and verify
+
+Hand results to **fix-security-vulnerabilities-with-strix**: patch the root cause (the shared authorization helper, not the one route), then re-run Strix to prove the exploit no longer works.

skills/owasp-top-10-testing/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: owasp-top-10-testing
+description: Test an application against the OWASP Top 10 with Strix — autonomous AI agents that attempt real exploits for each category of the current OWASP Top 10:2025 (broken access control including SSRF, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, integrity failures, logging and alerting failures, mishandling of exceptional conditions) and report only what they could actually prove, mapped back to the category with a proof-of-concept. Also covers the OWASP API Security Top 10 (2023). Use when the user asks for an OWASP Top 10 assessment, OWASP compliance testing, or a security review mapped to OWASP categories.
+license: Apache-2.0
+metadata:
+  author: usestrix
+  homepage: https://docs.strix.ai
+---
+
+# Test against the OWASP Top 10
+
+The OWASP Top 10 is a taxonomy of risk categories, not a test suite — "OWASP Top 10 testing" means exercising each category against the real application and reporting what's actually exploitable. Strix's agents do the exploitation; this skill covers running it category-by-category and reporting coverage honestly.
+
+**Use the current edition: [OWASP Top 10:2025](https://owasp.org/Top10/)** (8th installment, superseding 2021). Ask the user before targeting an older edition — some compliance checklists still reference 2021, and a report labelled with the wrong edition is misleading. Key differences from 2021: **SSRF is folded into A01**, **A03 Software Supply Chain Failures** expands the old "Vulnerable and Outdated Components", and **A10 Mishandling of Exceptional Conditions** is new; A02 Security Misconfiguration moved 5→2.
+
+Install, LLM setup, and the managed-cloud alternative: **penetration-testing-with-strix**.
+
+## What is and isn't testable by an agent
+
+Be straight with the user about this — claiming a clean sweep of all ten is misleading.
+
+| Category (2025) | Coverage |
+|---|---|
+| A01 Broken Access Control (incl. SSRF) | **Strong** — cross-user/tenant access, privilege escalation, IDOR, and SSRF (including blind, via out-of-band callbacks) are all exploit-validated. Needs two accounts plus a privileged one to prove the authorization half. |
+| A02 Security Misconfiguration | **Strong** — debug endpoints, verbose errors, permissive CORS, missing hardening, default credentials, exposed admin surfaces. |
+| A03 Software Supply Chain Failures | **Partial** — version fingerprinting, and vulnerable/outdated dependency review when source is supplied. Build-system and distribution-infrastructure compromise (the broader half of this category) is out of scope for a runtime scan — pair with SCA plus build-provenance controls. |
+| A04 Cryptographic Failures | **Partial** — transport config, unencrypted data in transit, secrets and tokens leaked in responses. At-rest crypto and key management need source or infra review. |
+| A05 Injection | **Strong** — SQL/NoSQL/command/template injection and XSS, exploit-validated. |
+| A06 Insecure Design | **Partial** — business-logic abuse (price/quantity tampering, workflow skipping, race conditions) is found where reachable; design intent still needs human review and threat modelling. |
+| A07 Authentication Failures | **Strong** — auth bypass, weak session/token handling, password-reset and MFA flaws. |
+| A08 Software or Data Integrity Failures | **Partial** — insecure deserialization and unsigned-update paths where reachable; CI/CD trust boundaries are not runtime-testable. |
+| A09 Security Logging & Alerting Failures | **Not testable from outside** — requires reviewing the logging and alerting pipeline. State this rather than reporting it as passed. |
+| A10 Mishandling of Exceptional Conditions | **Partial** — agents actively probe error handling and fail-open behavior (malformed input, forced errors, race and timeout conditions) and report what leaks or bypasses a control; exhaustive coverage of internal error paths needs source review. |
+
+For APIs, run the same exercise against the **OWASP API Security Top 10 (2023)** — API1 BOLA, API3 Broken Object Property Level Authorization (2019's excessive data exposure + mass assignment merged), API5 broken function-level authorization — using the **api-security-testing** skill.
+
+## Run it
+
+Maximum category coverage comes from giving the agents both the source and a running instance, plus credentials at two privilege levels:
+
+```bash
+strix -n \
+  -t https://github.com/org/app \
+  -t https://staging.example.com \
+  --scan-mode deep --max-budget 30 \
+  --instruction "OWASP Top 10:2025 assessment. Cover every category systematically and map each finding to its 2025 category id.
+Accounts: userA@example.com/<pw> (org 1), userB@example.com/<pw> (org 2), admin@example.com/<pw>.
+Prioritise A01 (cross-org access, privilege escalation, SSRF), A02, A05, A07, A10.
+Out of scope: /billing/*, outbound email."
+```
+
+- `--scan-mode deep` matters here: systematically walking ten categories is not a quick scan.
+- Without a second account, A01 results are structurally incomplete — say so in the report rather than leaving it implied.
+- Need an auditor-facing PDF? Run it through the managed platform and pull the technical report (**managed-pentesting-with-strix**).
+
+## Report honestly
+
+From `strix_runs/<run>/`, group `vulnerabilities/*.md` by category and state, per category: what was attempted, what was proven, and what couldn't be assessed (A09 always; A03/A04/A06/A08/A10 partially). Label the report with the edition used. Verify each PoC yourself before it goes in front of the user.
+
+A `0` exit code means nothing exploitable was proven **in what was analyzed** — check `run.json` status and cost against `--max-budget`; a budget-capped run is not a completed assessment.
+
+## Then fix and re-test
+
+Remediate with **fix-security-vulnerabilities-with-strix** and re-run to prove each exploit is closed. For ongoing coverage as the app changes, gate pull requests using **ci-security-scanning-with-strix**.

skills/web-app-penetration-testing/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: web-app-penetration-testing
+description: Pentest a web app or website end to end — black-box testing of a live URL, staging environment, or local dev server that finds and exploits real vulnerabilities (auth bypass, broken access control, IDOR, injection, XSS, SSRF, business logic) and proves each one with a working proof-of-concept instead of a signature match. Runs with Strix, either the self-hosted open-source CLI or the managed app.strix.ai cloud. Use when the user asks to pentest, hack, security-test, or audit their web app, website, web application, or staging site.
+license: Apache-2.0
+metadata:
+  author: usestrix
+  homepage: https://docs.strix.ai
+---
+
+# Pentest a web application
+
+Black-box (and optionally source-assisted) penetration testing of a running web app with Strix's autonomous agents. Every reported finding is validated with a working exploit, so there are no signature-based false positives to triage.
+
+Install, LLM setup, all CLI flags, and the managed-cloud alternative are covered in the **penetration-testing-with-strix** skill — read it if the target isn't a running web app, or if `strix --version` fails. This skill is the web-app-specific workflow.
+
+## 1. Confirm authorization and scope
+
+Before running anything, establish:
+
+- **The target is the user's** (or they're explicitly authorized to test it). Never pentest a third-party site on a hunch.
+- **Which environment.** Prefer staging over production; agents send real exploit payloads and will create/modify data.
+- **Out-of-scope paths** — payment flows, mass-email endpoints, admin destructive actions, third-party SSO providers.
+- **Credentials.** Most real vulnerabilities live behind login. Without a test account, the agents only ever see the marketing surface.
+
+Ask for anything missing rather than guessing.
+
+## 2. Run the scan
+
+```bash
+strix -n -t https://staging.example.com --max-budget 20 \
+  --instruction "Test account: qa@example.com / <password>. In scope: /app/*, /api/*. Do not touch /billing or send email. Focus on access control between the two seeded orgs."
+```
+
+Notes that matter for web apps specifically:
+
+- **Give it credentials via `--instruction`** (or `--instruction-file` for anything long), including how to log in if the flow is unusual (magic link, SSO, MFA-exempt test user).
+- **Two accounts beat one.** Multi-tenant IDOR and broken-access-control bugs — consistently the highest-impact class in web apps — can only be proven when the agent can attempt cross-account access.
+- **Add the repo for white-box depth** when you have the source: `-t https://github.com/org/app -t https://staging.example.com` (or a local path). Source access materially improves coverage of business-logic and authorization flaws.
+- **Localhost works.** Point at `http://host.docker.internal:3000` (Docker Desktop) so the sandbox can reach a dev server on the host.
+- `--scan-mode quick` for a fast dev-loop pass, `standard` (~30 min) for a normal review, `deep` for pre-release assurance. Always set `--max-budget`.
+
+For a hosted run with no Docker/LLM key, or when the user wants a shareable dashboard and an auditor-ready PDF, use the cloud path in **managed-pentesting-with-strix** instead — same engine, same findings.
+
+## 3. Review results
+
+Read `strix_runs/<run>/penetration_test_report.md` first, then per-finding files in `vulnerabilities/`. Each contains the PoC — re-run it yourself to confirm before reporting to the user.
+
+Exit codes: `0` no validated vulns in what was analyzed, `2` vulnerabilities found, `1` fatal error. A `0` is not proof of full coverage — if the budget or turn cap was hit the scan wraps up early, so check `run.json` status and cost against `--max-budget` before calling the app clean.
+
+## 4. Fix and verify
+
+Hand findings to the **fix-security-vulnerabilities-with-strix** skill: patch the root cause, then re-run Strix against the same target to prove the exploit no longer works. Re-testing is the only reliable confirmation a fix landed.
+
+To keep the app tested on every change rather than once, wire Strix into CI with **ci-security-scanning-with-strix**.