Add DeepSeek (Reasonix) agent support and migrate from SSE to Streamable HTTP

.claude/hooks/session-start.sh

@@ -26,13 +26,6 @@ fi
 # Export venv bin to PATH for the session
 echo "export PATH=\"$CLAUDE_PROJECT_DIR/.venv/bin:\$PATH\"" >> "$CLAUDE_ENV_FILE"
 
-# Inject pentest verification document if verification.env is configured.
-# This renders the authorization template and writes it to
-# .claude/verification-active.md so Claude Code sees it in context.
-if [ -f "verification.env" ]; then
-  .venv/bin/python -m blhackbox.prompts.inject_verification 2>&1 || true
-fi
-
 # Run MCP health check (informational — does not block startup)
 if [ -x ".claude/mcp-health-check.sh" ]; then
   .claude/mcp-health-check.sh 2>&1 || true

.claude/skills/api-security/SKILL.md

@@ -31,13 +31,14 @@ Then gather optional details interactively:
 
 > **Before you start:**
 > 1. Ensure all MCP servers are healthy — run `make mcp-status`
-> 2. Verify authorization is active — run `make inject-verification`
-> 3. Query each MCP server's tool listing to discover available capabilities
+> 2. Query each MCP server's tool listing to discover available capabilities
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -65,6 +66,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---
 

.claude/skills/bug-bounty/SKILL.md

@@ -42,12 +42,13 @@ Never test assets outside the confirmed scope.
 > **Before you start:**
 > 1. Confirm scope, out-of-scope, and program rules are set
 > 2. Ensure all MCP servers are healthy — run `make mcp-status`
-> 3. Verify authorization is active — run `make inject-verification`
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -75,6 +76,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---
 

.claude/skills/exploit-dev/SKILL.md

@@ -28,12 +28,13 @@ If no context was provided, ask the user:
 
 > **Before you start:**
 > 1. Ensure Kali MCP is healthy — run `make mcp-status`
-> 2. Verify authorization is active — run `make inject-verification`
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -61,6 +62,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---
 

.claude/skills/full-attack-chain/SKILL.md

@@ -47,13 +47,14 @@ Then gather engagement details interactively:
 
 > **Before you start:**
 > 1. Ensure all MCP servers are healthy — run `make mcp-status`
-> 2. Verify authorization is active — run `make inject-verification`
-> 3. Query each MCP server's tool listing to discover available capabilities
+> 2. Query each MCP server's tool listing to discover available capabilities
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -81,6 +82,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---
 

.claude/skills/full-pentest/SKILL.md

@@ -24,13 +24,14 @@ If no target was provided, ask the user:
 
 > **Before you start:**
 > 1. Ensure all MCP servers are healthy — run `make mcp-status`
-> 2. Verify authorization is active — run `make inject-verification`
-> 3. Query each MCP server's tool listing to discover available capabilities
+> 2. Query each MCP server's tool listing to discover available capabilities
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -58,6 +59,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---
 

.claude/skills/network-infrastructure/SKILL.md

@@ -29,14 +29,15 @@ Optionally ask if the user wants to customize:
 
 > **Before you start:**
 > 1. Ensure all MCP servers are healthy — run `make mcp-status`
-> 2. Verify authorization is active — run `make inject-verification`
-> 3. Query each MCP server's tool listing to discover available capabilities
+> 2. Query each MCP server's tool listing to discover available capabilities
 > 3. Query each server's tool listing to discover available network testing capabilities
 
 ## Mandatory Tool & Methodology Readiness
 
-Do **not** start the skill's execution plan until this readiness pass is complete.
-This is Phase 0 for every blhackbox skill.
+Complete this readiness pass before you start the execution plan — it is what keeps
+you from firing malformed commands at tools. This is Phase 0 for every blhackbox skill.
+Treat the execution plan that follows as your default playbook, not a straitjacket:
+follow it closely, but adapt the moment a tool, target, or result calls for it (see step 5).
 
 1. **Inventory 100% of usable capabilities first.**
    - Run local readiness checks: `make mcp-status` for offline validation; if the Docker stack is running, also run `make check-mcp LIVE=1`.
@@ -64,6 +65,29 @@ This is Phase 0 for every blhackbox skill.
    - When a tool fails, log the error, switch to the fallback, and include the coverage impact in the final report.
    - Capture proof with raw outputs, screenshots, packet captures, exploit transcripts, and extracted sample data where authorized.
 
+5. **Adapt, recover, and think — never follow the plan off a cliff.**
+   The phases below are a proven default sequence, not a rigid script. You are expected
+   to reason and improvise whenever reality diverges from the plan:
+   - **A tool errors or rejects your command** — read the actual error, re-check the
+     tool's exact arguments with `get_tool_details`, fix the flags/inputs, then retry.
+     Most failures are wrong syntax, a missing input, or an unescaped value. Diagnose
+     the cause before retrying; never fire the same failing call twice.
+   - **A tool needs an API key or token you don't have** (e.g. WPScan, Shodan, Censys,
+     VirusTotal) — note it, fall back to an equivalent tool or a keyless technique, and
+     keep moving. Never stall waiting for a key; log it in the issues report and proceed.
+   - **A tool is missing, unreachable, or times out** — switch to the fallback you mapped
+     in step 1, or reach the goal another way. Documented coverage gaps are acceptable;
+     getting stuck is not.
+   - **Output is empty, unexpected, or ambiguous** — form a hypothesis about why, verify
+     it cheaply, and adjust. Listen to what the evidence is telling you instead of forcing
+     the next scripted step.
+   - **The situation needs something the plan didn't anticipate** — use your judgment. Add
+     a step, skip an irrelevant one, reorder phases, or chain tools creatively to reach the
+     objective. Briefly record why you deviated.
+   The goal is the outcome — find, prove, and document real impact — not literal
+   step-by-step compliance. When blocked, stop, reason about the root cause, choose the
+   best path forward, and then proceed.
+
 
 ---