report

name	report
description	Generate submission-ready reports for all confirmed findings. Runs dedup, PoC builder, quality check, and report writer. Usage: /report bounty or /report pentest

Generate reports for confirmed findings. Format: $ARGUMENTS (default: bounty)

This runs the full reporting pipeline. Run this AFTER /pipeline and /validate.

Step 1: Dedup and Inventory

Run uv run python3 ../../tools/dedup_findings.py --scan-dir scans/ --db findings.json --stats Read findings.md and brain effective techniques. Show the user a numbered list of confirmed findings.

Step 2: For EACH confirmed finding (one at a time):

2a: Check if PoC exists

Look in poc/ directory. If no PoC for this finding, launch poc-builder agent: "Create PoC for: [finding details]. You MUST write files to poc//. Create reproduce.sh and poc.html (if client-side). Do NOT just output to terminal — write the actual files."

2b: Check if evidence exists

Look in evidence/ directory. If no screenshots/recordings exist:

• Do NOT claim screenshots exist if they haven't been taken
• Do NOT hallucinate file paths — verify files exist with ls before referencing them
• Tell the user: "No evidence captured yet. Run /evidence screenshot to capture, or note 'evidence pending' in the report."

2c: Determine CVSS version

Read scope.yaml to check the platform: field.

• If platform: hackerone → use CVSS 3.1 (HackerOne does not support CVSS 4.0)
• All other platforms → use CVSS 4.0

2d: Draft the report

Launch report-writer agent: "Write a bug bounty report for: [finding details]. Format: $ARGUMENTS. Platform: [platform from scope.yaml]. CVSS version: [3.1 if hackerone, 4.0 otherwise]. CRITICAL INSTRUCTIONS:

1. You MUST write the report to reports/drafts/.md using the Write tool. Do NOT just output to terminal.
2. Use the CVSS version specified above. HackerOne requires CVSS 3.1. All other platforms use CVSS 4.0.
3. Title formula: [Vuln] in [Component] Enables [Impact].
4. Only reference PoC files and screenshots that ACTUALLY EXIST on disk — verify with ls before citing.
5. Include PoC at [path] and evidence at [path] ONLY if those files exist.
6. NEVER hardcode the researcher username, email, password, or token. If you need to embed the reporter identity (e.g., in a sample signup or PoC), write the env-var symbol like ${HACKERONE_EMAIL_ALIAS} (HackerOne), ${BUGCROWD_EMAIL_ALIAS} (Bugcrowd), ${INTIGRITI_EMAIL_ALIAS} (Intigriti), or ${YESWEHACK_EMAIL} (YesWeHack). Substitution happens at submit time. See rules/identities.md for the full table."

2e: Quality check

Launch quality-check agent on the draft. If score < 7, show issues and ask user if they want to fix and re-check.

Step 3: Summary

After all findings are processed, show:

Reports generated:
  1. [title] — score: X/10 — reports/drafts/finding-1.md
  2. [title] — score: X/10 — reports/drafts/finding-2.md
  ...

Ready for submission:
  /dupcheck <finding> — check for duplicates
  /submit <finding>   — submit to platform

Step 4: Sync

Run uv run python3 ../../tools/global_brain.py sync-from-local Run uv run python3 ../../tools/statusline.py

Top-Tier Report Standard

A report is ready when a tired triager can reproduce and justify it without guessing.

Hard requirements:

• title states vuln, component, and proven impact
• summary explains the business risk in two sentences
• steps use exact accounts, URLs, headers, payloads, and expected markers
• impact section maps the primitive to customer, tenant, financial, admin, secret, or execution consequence
• evidence paths exist and are referenced accurately
• CVSS version follows platform rules and vector matches final proven impact
• duplicate risk and known prior art are addressed when relevant
• remediation names the broken control, not just "validate input"

If any confirmed finding lacks PoC or evidence, stop report generation for that finding and send it back to /validate or /chain.