h-mmer Check for duplicate reports: $ARGUMENTS
- Determine the platform and program from
scope.yamlin the current directory. - Use
bounty-platformsMCP toolsearch_hacktivitywith platform, program, and "$ARGUMENTS" as the query. - Also search local findings:
uv run python3 ../../tools/dedup_findings.py --stats --db findings.json - Read
hacktivity.mdif it exists and grep for related terms. - 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_writeupsMCP tool with " " - 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 strongersame_primitive_different_asset: possible duplicate; explain scope difference and noveltysame_asset_different_primitive: usually unique; prove a different root causeknown_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.