# Vuln Diagnose

> Builds deterministic, reproducible proof-of-concepts to validate suspected or partially-confirmed vulnerabilities (e.g., XSS, IDOR) and eliminate false positives. Triggered when tool outputs flag potential issues, or when manual confirmation of exploitability is required before documenting a finding.

- Skill: `rifteo/vuln-diagnose` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add rifteo/vuln-diagnose`
- Raw SKILL.md: https://api.skillmd.com/api/skills/rifteo/vuln-diagnose/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: Rifteo (https://skillmd.com/u/rifteo)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/rifteo/vuln-diagnose

---


# Vulnerability Diagnose

A suspected vulnerability is not a finding. Before writing anything, build a deterministic reproduction case. If you cannot reproduce it reliably, you cannot report it.

Inspired by the principle: *a fast, deterministic, agent-runnable pass/fail signal is a superpower.*

## Process

### Step 1 — State the Hypothesis

Write one sentence: "I believe [vulnerability type] exists at [endpoint/component] because [observed behaviour]."

This is the claim. Everything that follows either confirms or disproves it.

### Step 2 — Build the Feedback Loop

Create the minimal test case that produces a binary YES/NO answer:
- An HTTP request that succeeds when it shouldn't
- A payload that executes when it shouldn't
- A response that contains data it shouldn't

The test must be:
- **Reproducible** — same result every time
- **Minimal** — only the essential input, no noise
- **Unambiguous** — pass is clearly different from fail

If you can't build this test case, the hypothesis is not testable yet. Stop and gather more information.

### Step 3 — Test Alternate Explanations

Before confirming, rule out:
- Caching (replay the request — is the result fresh?)
- Rate limiting (does it fail on the 5th attempt?)
- Session dependency (does it work with a fresh session?)
- Race conditions (does it fail on a second run?)

### Step 4 — Confirm the Impact

Actually demonstrate the worst-case impact:
- For data access: retrieve data belonging to another user
- For XSS: execute `alert(document.domain)` or exfiltrate a cookie
- For SQLi: extract a row from a table not intended to be accessible
- For privilege escalation: perform an admin action with a user token

A confirmed impact requires evidence (HTTP request + response, screenshot, extracted data).

### Step 5 — Document

Produce a **Minimal Reproduction Case**:

```
Vulnerability: [type]
Endpoint: [METHOD] [URL]
Precondition: [e.g., logged in as user A]

Request:
[exact HTTP request]

Response:
[relevant snippet proving the issue]

Confirmed impact: [what was demonstrated]
Reproducible: YES / NO (notes if flaky)
```

Then pass this to `finding-writer` to produce the full finding.

## Rules

- No exploit, no finding — Shannon's rule. If you cannot demonstrate impact, downgrade to "suspected" and label it clearly
- Never report a finding based on tool output alone without manual confirmation
- If the test is flaky (fails intermittently), investigate root cause before reporting
- One hypothesis per session — do not stack unconfirmed vulnerabilities