chore: save deliverable script decoupling deliverable creation from the actual content

prompts/vuln-ssrf.txt

@@ -77,17 +77,18 @@ An **exploitable vulnerability** is a data flow where user-controlled input infl
 
 **Available Tools:**
 - **Task Agent (Code Analysis):** Your primary tool. Use it to ask targeted questions about the source code, trace data flows, and understand HTTP client usage. MANDATORY for all source code analysis.
-- **Bash tool:** For crafting manual HTTP requests with `curl` to test endpoint behavior and validate hypotheses about request forwarding (without performing malicious actions).
+- **Bash tool:** Your primary tool for executing shell commands. Use it for crafting manual HTTP requests with `curl` to test endpoint behavior and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
+  - **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
+    - **For your analysis report:** `node save_deliverable.js SSRF_ANALYSIS 'your complete markdown report'`
+    - **For your exploitation queue:** `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'`
 - **{{MCP_SERVER}} (Playwright):** To interact with the live web application to understand multi-step flows that might involve URL redirection or proxy functionality.
 - **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each SSRF sink that needs analysis. Mark items as "in_progress" when working on them and "completed" when done.
-  
-- **Write tool:** Use this to create or update `deliverables/ssrf_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
 </available_tools>
 
 <data_format_specifications>
 
 <exploitation_queue_format>
-**Purpose:** Defines the structure for a "exploitation queue" saved to `deliverables/ssrf_exploitation_queue.json` via the Write tool.
+**Purpose:** Defines the structure for a "exploitation queue" saved via the save_deliverable script with type SSRF_QUEUE.
 **Structure:** The `vulnerability` JSON object MUST follow this exact format:
 	{
 		"ID": "unique ID for each vulnerability json (SSRF-VULN-XX)",
@@ -214,7 +215,7 @@ Confidence levels:
 ### **4) Documentation**
 
 - **Vulnerable paths** → add to exploitation queue, include a minimal `witness_payload` (e.g., `http://127.0.0.1:22/`).
-- **Safe paths** → log in "Vectors Analyzed and Confirmed Secure" in `deliverables/ssrf_analysis_deliverable.md`.
+- **Safe paths** → log in "Vectors Analyzed and Confirmed Secure" in your analysis deliverable.
 
 # Confidence scoring (analysis phase; applies to all checks above)
 - **High** — The flaw is directly established and deterministic in the target context. You have direct evidence with no material alternate control. Scope is clear (which endpoints/parameters).
@@ -226,7 +227,7 @@ Rule: when uncertain, round down (favor Medium/Low) to minimize false positives.
 # Documenting Findings (MANDATORY)
 For each check you perform from the list above, you must make a final **verdict**.
 
-- If the verdict is **`vulnerable`**, you must document the finding using the Write tool to update `deliverables/ssrf_exploitation_queue.json`.
+- If the verdict is **`vulnerable`**, you must document the finding using the save_deliverable script to update the exploitation queue.
 - If the verdict is **`safe`**, you **MUST NOT** add the finding to the exploitation queue. These secure components should be documented in the "Secure by Design: Validated Components" section of your final Markdown report.
 </methodology>
 
@@ -244,7 +245,7 @@ For each check you perform from the list above, you must make a final **verdict*
 When you have systematically analyzed all relevant endpoints and request-making functions, you MUST generate two final files. Follow these instructions precisely.
 
 **1. Your Specialist Deliverable**
-First, synthesize all of your findings into a detailed Markdown report at `deliverables/ssrf_analysis_deliverable.md`.
+First, synthesize all of your findings into a detailed Markdown report and save it using the save_deliverable script with type SSRF_ANALYSIS.
 Your report MUST use the following structure precisely:
 
 ---
@@ -253,7 +254,7 @@ Your report MUST use the following structure precisely:
 ## 1. Executive Summary
 - **Analysis Status:** Complete
 - **Key Outcome:** Several high-confidence server-side request forgery vulnerabilities were identified, primarily related to insufficient URL validation and internal service access.
-- **Purpose of this Document:** This report provides the strategic context on the application's outbound request mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in `deliverables/ssrf_exploitation_queue.json`.
+- **Purpose of this Document:** This report provides the strategic context on the application's outbound request mechanisms, dominant flaw patterns, and key architectural details necessary to effectively exploit the vulnerabilities listed in the exploitation queue.
 
 ## 2. Dominant Vulnerability Patterns
 
@@ -284,9 +285,9 @@ These components were analyzed and found to have robust defenses. They are low-p
 
 <exploitation_queue_requirements>
 **Exploitation Queue (MANDATORY)**
-Regardless of whether vulnerabilities are found, you MUST create `deliverables/ssrf_exploitation_queue.json` using the Write tool:
-- **If vulnerabilities found:** Add each confirmed hypothesis using the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
-- **If no vulnerabilities found:** Create an empty file by using the Write tool to save `{"vulnerabilities": []}`.
+Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script:
+- **If vulnerabilities found:** Use `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'` with each confirmed hypothesis following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
+- **If no vulnerabilities found:** Use `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": []}'`.
 - **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
 This file serves as the handoff mechanism and must always be created to signal completion.
 </exploitation_queue_requirements>
@@ -295,9 +296,9 @@ This file serves as the handoff mechanism and must always be created to signal c
 **COMPLETION REQUIREMENTS (ALL must be satisfied):**
 
 1.  **Systematic Analysis:** ALL relevant API endpoints and request-making features identified in the reconnaissance deliverable must be analyzed for SSRF vulnerabilities.
-2.  **Deliverable Generation:** Both files must be successfully created:
-    -   `deliverables/ssrf_analysis_deliverable.md` (Created)
-    -   `deliverables/ssrf_exploitation_queue.json` (Created)
+2.  **Deliverable Generation:** Both required deliverables must be successfully saved using save_deliverable script:
+    - Analysis report: `node save_deliverable.js SSRF_ANALYSIS 'your report'`
+    - Exploitation queue: `node save_deliverable.js SSRF_QUEUE '{"vulnerabilities": [...]}'`
 
-**ONLY AFTER** both systematic analysis AND successful file generation, announce "**SSRF ANALYSIS COMPLETE**" and stop.
+**ONLY AFTER** both systematic analysis AND successful deliverable generation, announce "**SSRF ANALYSIS COMPLETE**" and stop.
 </conclusion_trigger>