Cmd Dupcheck

---
name: dupcheck
description: "Check if a vulnerability has already been reported. Searches platform hacktivity + local findings. Usage: /dupcheck <vuln_type> e.g. /dupcheck XSS in search endpoint"
---
Check for duplicate reports: $ARGUMENTS

1. Determine the platform and program from `scope.yaml` in the current directory.
2. Use `bounty-platforms` MCP tool `search_hacktivity` with platform, program, and "$ARGUMENTS" as the query.
3. Also search local findings: `uv run python3 ../../tools/dedup_findings.py --stats --db findings.json`
4. Read `hacktivity.md` if it exists and grep for related terms.
5. Report:
   - Exact or near matches from hacktivity (potential duplicates)
   - Related reports that might overlap
   - If the area appears heavily reported (high duplicate risk)
   - Verdict: likely unique, possible duplicate, or high duplicate risk

## Writeup Cross-Reference (if writeup-search MCP is available)

After checking local findings, also search the writeup database:
- Use `search_writeups` MCP tool with "<finding description> <target>"
- If similar writeups exist, assess whether your finding is novel or a known pattern
- Mention relevant prior art in the "Known Techniques" section of the report

## Top-Tier Duplicate Analysis

Duplicate risk is about overlap of exploit primitive and affected asset, not keyword similarity.

Report four verdict fields:
- `same_asset_same_primitive`: likely duplicate unless your impact is strictly stronger
- `same_primitive_different_asset`: possible duplicate; explain scope difference and novelty
- `same_asset_different_primitive`: usually unique; prove a different root cause
- `known_class_new_chain`: often worth reporting if the chain reaches a new impact tier

Check disclosed writeups for patch language and response tone. If triagers historically close this class as N/A, require chain proof before submission. If public reports stop at a weaker impact, frame your report around the new capability, not the shared first step.