After discovering a potential vulnerability or exploit - Before submitting any finding to a report or bounty platform - When verifying that a remediation or patch is effective - When cross-checking automated scanner results - User says "verify", "confirm", "validate.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
After discovering a potential vulnerability or exploit - Before submitting any finding to a report or bounty platform - When verifying that a remediation or patch is effective - When cross-checking automated scanner results - User says "verify", "confirm", "validate.
Compile verified evidence into a structured report:
## Verification Report: [Finding ID]### Summary-**Finding:** [Description]
-**Verdict:** [CONFIRMED / NOT CONFIRMED / PARTIALLY CONFIRMED]
-**Confidence:** [High / Medium / Low]
-**Severity:** [Critical / High / Medium / Low / Info]
### Evidence Chain1. Pre-condition baseline: [timestamp] — [state]
2. Execution: [timestamp] — [exact command] → [output]
3. Post-condition: [timestamp] — [observed change]
4. Independent confirmation: [method] → [result]
5. False positive analysis: [results]
### Impact Assessment- [What an attacker could actually achieve]
- [Prerequisites for exploitation]
- [Scope of affected systems]
### Reproduction Steps1. [Step 1 with exact command]
2. [Step 2]
3. [Expected vs actual result]
Verification by Finding Type
SQL Injection
Phase 2: Execute original payload (e.g., ' OR 1=1--)
Phase 4: Confirm with DIFFERENT payload (e.g., ' UNION SELECT NULL--)
Phase 5: Check — is error-based or blind? Is WAF interfering?
XSS
Phase 2: Execute original payload (e.g., <script>alert(1)</script>)
Phase 4: Confirm with different vector (e.g., <img src=x onerror=alert(1)>)
Phase 5: Check — does it only fire in specific browser/context?
Authentication Bypass
Phase 2: Execute bypass technique
Phase 4: Confirm with different session/account
Phase 5: Check — is this a configuration issue vs a code flaw?
Network Vulnerability
Phase 2: Run original nmap/nessus finding
Phase 4: Manual netcat/telnet confirmation
Phase 5: Check — is the service actually vulnerable or just version-matched?
Remediation Verification
Phase 2: Attempt the ORIGINAL exploit after patch
Phase 4: Try variant attacks on the same vector
Phase 5: Check — is the fix complete or partial?
Phase 6: Document: PATCHED / PARTIALLY PATCHED / NOT PATCHED
Integration with Other Skills
Skill
How Verification Loop Applies
security-bounty-hunter
Every bounty submission requires Phase 6 report
vulnerability-assessment
Scanner results pass through Phase 5 false positive elimination
terminal-ops
Verification uses terminal-ops evidence protocol
web-sqli / web-xss
Every injection finding requires independent confirmation
network-pentest
Network findings verified with secondary tool
deep-research
CVE claims verified before acting on them
Decision Matrix
Verification Result
Action
CONFIRMED (High confidence)
Include in report, proceed to exploitation or remediation
CONFIRMED (Medium confidence)
Include with caveats, recommend manual verification
PARTIALLY CONFIRMED
Document what works and what doesn't, adjust severity
NOT CONFIRMED
Do NOT include in report, investigate why the original finding appeared
INCONCLUSIVE
Flag for manual review, document all evidence collected
Detection Methods
Verification Loop Audit
Verification coverage: What % of findings are independently verified.
False positive rate: <5% of verified findings are false positives.
Re-test rate: Verified findings re-tested after fix.
SIEM Detection Rules
Custom tracking: Verification status in finding lifecycle.
Defense Evasion Techniques
Verification Bypass
Provide PoC videos: Hard to verify independently; reduced scrutiny.
Provide partial reproduction: Some conditions for reproduction not documented.