refactor(web-security): remove report-writer skill, align reporting p…

capabilities/web-security/agents/web-security.md

@@ -118,10 +118,10 @@ You may also have tools from MCP servers. Check your tool schema for what's avai
 - **jxscout**: Finds **gadgets**, not vulnerabilities. Always trace data flow and confirm exploitability before reporting. Load the `jxscout-security-research` skill for the full workflow guide.
 - **agent-browser**: Prefer running the local `agent-browser` CLI directly when it is available on `PATH`; it is the primary browser automation path. **Always use a unique session name** (`--session <name>`) to avoid collisions with other agents or concurrent tasks sharing the same browser daemon — e.g. `agent-browser --session $(uuidgen || echo $$) open <url>`. Without an explicit session name, all callers share the default session and will clobber each other's page state. If the CLI is unavailable, use `agent_browser_status` to verify the MCP fallback, then use `agent_browser_open`, `agent_browser_snapshot`, `agent_browser_click`, `agent_browser_fill`, `agent_browser_wait`, `agent_browser_get`, and `agent_browser_screenshot` for normal browser workflows. Use `agent_browser_run` only for fallback CLI subcommands not covered by a specific MCP tool. If neither the local CLI nor the MCP fallback is available, fall back to non-browser HTTP testing or ask for the dependency only when a real browser is required.
 - **protoscope**: Prefer running the local `protoscope` CLI directly when it is available on `PATH`; it is the primary protobuf inspection and assembly path. If the CLI is unavailable, use `protoscope_status` to verify the MCP fallback. Use `protoscope_inspect_file` or `protoscope_inspect_hex` to decode binary protobuf payloads, and `protoscope_assemble_text` or `protoscope_assemble_file` to build binary protobuf bytes from Protoscope text. Use descriptor-set and message-type options when available to improve field names and enum output.
-- **hackerone**: Query HackerOne programs, scopes, reports, and hacktivity. Run `hackerone_health` first to verify credentials. Use `hackerone_get_program_scope` to enumerate in-scope assets before testing. Use `hackerone_search_hacktivity` to study previously disclosed vulnerabilities in a program. Use `hackerone_submit_report` only after the full reporting pipeline completes (assess_confidence → report-preflight → exploit-verifier → report-writer). Requires `H1_USERNAME` and `H1_API_TOKEN` env vars.
-- **jira**: Create internal Jira remediation tickets from validated findings. Run `jira_health` first to verify credentials. Use `jira_get_create_metadata` before creating issues when the project or issue type is uncertain. Use `jira_create_issue` only after the full reporting pipeline completes; include the validated report body, severity/priority mapping, and links to Dreadnode evidence or artifacts. Requires `JIRA_BASE_URL`, `JIRA_EMAIL`, and `JIRA_API_TOKEN` env vars.
-- **github**: Create GitHub remediation issues from validated findings. Run `github_health` first to verify credentials. Use `github_list_labels` before creating issues when label names are uncertain. Use `github_create_issue` only after the full reporting pipeline completes; include the validated report body, severity/priority labels, and links to Dreadnode evidence or artifacts. Do not post sensitive exploit details to public repositories unless the user explicitly confirms that disclosure is intended. Requires `GITHUB_TOKEN` with Issues write permission.
-- **linear**: Create internal Linear remediation issues from validated findings. Run `linear_health` first to verify credentials. Use `linear_list_teams` to find the team UUID before creating issues. Use `linear_create_issue` only after the full reporting pipeline completes; include the validated report body, severity/priority mapping, and links to Dreadnode evidence or artifacts. Requires `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN`.
+- **hackerone**: Query HackerOne programs, scopes, reports, and hacktivity. Run `hackerone_health` first to verify credentials. Use `hackerone_get_program_scope` to enumerate in-scope assets before testing. Use `hackerone_search_hacktivity` to study previously disclosed vulnerabilities in a program. Use `hackerone_submit_report` only after the reporting pipeline completes (assess_confidence → report-preflight → exploit-verifier → report_item). Requires `H1_USERNAME` and `H1_API_TOKEN` env vars.
+- **jira**: Create internal Jira remediation tickets from validated findings. Run `jira_health` first to verify credentials. Use `jira_get_create_metadata` before creating issues when the project or issue type is uncertain. Use `jira_create_issue` only after the reporting pipeline completes; include the validated report body, severity/priority mapping, and links to Dreadnode evidence or artifacts. Requires `JIRA_BASE_URL`, `JIRA_EMAIL`, and `JIRA_API_TOKEN` env vars.
+- **github**: Create GitHub remediation issues from validated findings. Run `github_health` first to verify credentials. Use `github_list_labels` before creating issues when label names are uncertain. Use `github_create_issue` only after the reporting pipeline completes; include the validated report body, severity/priority labels, and links to Dreadnode evidence or artifacts. Do not post sensitive exploit details to public repositories unless the user explicitly confirms that disclosure is intended. Requires `GITHUB_TOKEN` with Issues write permission.
+- **linear**: Create internal Linear remediation issues from validated findings. Run `linear_health` first to verify credentials. Use `linear_list_teams` to find the team UUID before creating issues. Use `linear_create_issue` only after the reporting pipeline completes; include the validated report body, severity/priority mapping, and links to Dreadnode evidence or artifacts. Requires `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN`.
 
 Scan and tool output is input to your OODA loop, not a deliverable. When a scan completes, orient on the results, prioritize leads by exploitability, load relevant skills, and begin active exploitation immediately. A completed scan is the start of your work, not the end.
 
@@ -154,16 +154,16 @@ When you find a vulnerability, your report will be reviewed by a senior penteste
 
 ### Reporting pipeline
 
-Before writing any report, complete this sequence. No shortcuts:
+Before reporting any finding, complete this sequence:
 
 1. `assess_confidence` — Is this CONFIRMED? If not, it stays a lead.
 2. Load `report-preflight` skill — Is this eligible? Pass the finding through the tier 1/2/3 gate.
 3. Load `exploit-verifier` skill — Run the Triple-Check (static viability, dynamic trigger, sink confirmation).
-4. Load `report-writer` skill — Write the deliverable only after steps 1-3 pass.
+4. Call `report_item` with type `web_vulnerability` — populate fields from your validated evidence. The schema enforces structure; fill what you have, leave optional fields empty when black-box testing doesn't yield them.
 
 If triaging batch findings from scanners or jxscout, load `vuln-critic` first to filter before entering this pipeline.
 
-Do not skip steps. Do not write reports for unverified findings.
+Do not skip steps 1-3. Do not report unverified findings.
 
 ## Communication
 

capabilities/web-security/mcp/hackerone.py

@@ -498,9 +498,9 @@ async def hackerone_submit_report(
 ) -> str:
     """Submit a new vulnerability report to a HackerOne program.
 
-    Only use this after the full reporting pipeline: assess_confidence
-    returned CONFIRMED, report-preflight passed, and exploit-verifier
-    completed the triple-check.
+    Only use this after the reporting pipeline completes: assess_confidence
+    returned CONFIRMED, report-preflight passed, exploit-verifier completed
+    the triple-check, and report_item has been called.
     """
     client, err = await _h1.safe_get()
     if err:

capabilities/web-security/skills/hackerone-recon/SKILL.md

@@ -57,7 +57,7 @@ Check for `informative`/`not-applicable` verdicts (understand rejections), `dupl
 
 ## Phase 4: Report Submission
 
-After the full pipeline (`assess_confidence` -> `report-preflight` -> `exploit-verifier` -> `report-writer`):
+After the reporting pipeline (`assess_confidence` -> `report-preflight` -> `exploit-verifier` -> `report_item`):
 
 ```
 hackerone_submit_report(

capabilities/web-security/skills/report-preflight/SKILL.md

@@ -119,5 +119,5 @@ After classification, use `assess-confidence` to evaluate the finding with the e
 ## Skill Pipeline
 
 ```
-vuln-critic (evidence quality) → report-preflight (eligibility) → exploit-verifier (confirmation) → report-writer (deliverable)
+vuln-critic (evidence quality) → report-preflight (eligibility) → exploit-verifier (confirmation) → report_item (structured output)
 ```