| name | validate |
| description | Validate a finding through the 7-Question Gate + 4 gates. Kills weak findings FAST. Usage: /validate <finding description> |
Validate finding: $ARGUMENTS
This is the MOST IMPORTANT command. Run it BEFORE writing any report. It takes 30 seconds to kill a bad lead. A report takes 30 minutes.
Step 1: Identify
Read findings.md and brain data. Locate the finding matching "$ARGUMENTS".
Show finding details and ask user to confirm.
Step 2: Run 7-Question Gate
Launch validator agent:
"Validate this finding through the 7-Question Gate and 4-gate checklist: [finding details]. Check rules/hunting.md Rule 19 for the never-submit list AND rules/mistakes.md (REPORTING + METHODOLOGY sections) for lessons agents commonly miss — especially: (a) theoretical vs confirmed exploits, (b) file-path hallucinations, (c) CVSS-version mismatch per platform, (d) status-code asymmetry ≠ proven bug, (e) single-account IDOR ≠ cross-account leak. Output PASS, KILL, DOWNGRADE, or CHAIN REQUIRED with specific reason."
Step 3: Act on Result
If PASS:
- Launch
poc-builder agent to create minimal PoC
- Capture evidence:
uv run python3 ../../tools/capture.py screenshot
- Launch
report-writer agent for platform-ready draft
- Launch
quality-check agent — block if score < 7
- Show: score, draft path, PoC path, suggested title
- Suggest:
/dupcheck <finding> then /submit <finding>
If KILL:
- Record to brain:
uv run python3 ../../tools/brain.py record <target> exhausted "<finding>" "<kill reason>"
- Tell user: "Finding killed at Q[N]: [reason]. Move on."
- Suggest next action:
/hunt <target> or /surface <target>
If DOWNGRADE:
- Tell user what's needed to prove higher impact
- Suggest specific test to run
If CHAIN REQUIRED:
- Tell user what chain is needed
- Suggest:
/chain to build the chain
- Record as partial in brain
Top-Tier Validation Bar
Validation is where mediocre hunters become expensive or elite.
Apply these hard checks before PASS:
- The finding demonstrates a capability, not just an anomaly.
- The affected asset is in scope and policy allows the validation method.
- The PoC is reproducible by another operator in under ten minutes.
- Evidence includes request/response or browser proof and a clear readback marker.
- Severity is based on achieved impact, not potential impact.
- Duplicate and never-submit classes have been considered.
- Chaining has been attempted for low standalone classes.
If one check fails, prefer KILL or DOWNGRADE over "probably valid." Record the missing proof so the hunter can run one precise follow-up instead of re-litigating the whole bug.
