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.

When to Use This Skill

Use this skill when the user:

Has a hunch or a partially-confirmed vulnerability
Tool output flagged something that needs manual validation
Wants to confirm a finding before writing it up
Says “I think there’s an IDOR here”, “this looks like XSS”, “not sure if this is exploitable”

What Does It Check?

In scope:

Any vulnerability class that can be confirmed with a reproducible HTTP request or browser payload
Binary confirmation (YES/NO) via minimal test cases
False positive elimination: caching, rate limiting, session dependency, race conditions
Impact demonstration with evidence (HTTP request + response, screenshot, extracted data)

Out of scope:

Writing the final finding use finding-writer after this skill confirms the vulnerability
Reporting based on tool output alone always requires manual confirmation

How It Works

Step 1: State the HypothesisWrite 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 LoopCreate 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

Step 3: Test Alternate ExplanationsBefore 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 ImpactActually 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: DocumentProduce 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.

Output

A Minimal Reproduction Case document with confirmed impact and evidence, ready for finding-writer.

Known Limitations

No exploit, no finding 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

Metric	Without Skill	With Skill
Turns to complete	2	1
Response tokens	~2,255	~1,315
Total time	55s	26s

Vulnerability Diagnose

Summary

SKILL.md file