> ## Documentation Index
> Fetch the complete documentation index at: https://community.rifteo.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Vulnerability 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.

<Info>
  **Status:** Stable
  **Version:** 1.0.0
  **Author:** Rifteo
  **Tags:** pentest, security
</Info>

**Installation**

```bash theme={"system"}
rifteo-skills add vuln-diagnose
```

***

## Summary

A suspected vulnerability is not a finding. Build a deterministic reproduction case first if it cannot be reproduced reliably, it cannot be reported.

* Step 1 forces a single-sentence hypothesis statement: the claim that all subsequent steps confirm or disprove
* Step 2 builds the minimal test case reproducible, minimal, unambiguous that gives a binary YES/NO answer
* Step 3 rules out false positives: caching, rate limiting, session dependency, race conditions
* Step 4 demonstrates the worst-case impact with actual evidence: data from another user, cookie exfiltrated, admin action performed
* Step 5 produces a **Minimal Reproduction Case** document ready to pass to `finding-writer`

***

## SKILL.md file

<Accordion title="Discover skill details">
  ### 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.

  #### 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 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

  **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.

  #### 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
</Accordion>

***

## Benchmark Results

Tested on claude-sonnet-4-6 via Claude Code CLI. Same prompt, same model, same target. The only variable is whether the skill is loaded.

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

***

## Related skills

<CardGroup cols={3}>
  <Card title="finding-writer" href="/skills/finding-writer">
    Convert raw pentest notes into structured audit findings ready for reporting
  </Card>

  <Card title="bugbounty-reporter" href="/skills/bugbounty-reporter">
    Converts raw bug bounty findings into a complete, triage-ready report
  </Card>

  <Card title="risk-assessor" href="/skills/risk-assessor">
    Score a vulnerability using likelihood × impact with SLA-bound remediation urgency
  </Card>
</CardGroup>