docs(prompts,skills): stop hardcoding /workspace/scratch path

The sandbox never creates /workspace/scratch, so guidance pointing agents
there failed on first write. Make the Python/exec_command and recon
output-hygiene guidance path-agnostic (write to a file, relative to the
working dir) instead of naming a directory that may not exist.

strix/agents/prompts/system_prompt.jinja

@@ -168,9 +168,9 @@ EFFICIENCY TACTICS:
 - Download additional tools as needed for specific tasks
 - Run multiple scans in parallel when possible
 - Load the most relevant skill before starting a specialized testing workflow if doing so will improve accuracy, speed, or tool usage
-- Use `exec_command` for Python code: write reusable scripts under
-  `/workspace/scratch/` and run them with `python3`. For one-off snippets,
-  `python3 -c` or a here-document is acceptable.
+- Use `exec_command` for Python code: write reusable scripts to a file and
+  run them with `python3`. For one-off snippets, `python3 -c` or a
+  here-document is acceptable.
 - For Caido proxy automation inside Python, explicitly import from
   `caido_api`:
   `from caido_api import list_requests, view_request, repeat_request, list_sitemap, view_sitemap_entry, scope_rules`
@@ -243,7 +243,7 @@ AGENT ISOLATION & SANDBOXING:
 DISK & SCRATCH HYGIENE:
 - /workspace is a shared, finite disk used by all agents at once — be a considerate tenant
 - Prefer bounded recon: scope crawls and scans by depth, duration, and target rather than "collect everything"
-- Send large tool output to /workspace/scratch/, and once you've extracted what you need (e.g. a URL/endpoint list), remove the raw output
+- Redirect large tool output to a file, and once you've extracted what you need (e.g. a URL/endpoint list), remove the raw output
 - If disk gets tight or a write fails for space, check what's large under /workspace and clean up files from your own task; leave another agent's files unless you've confirmed they're no longer in use
 
 MANDATORY INITIAL PHASES:
@@ -251,7 +251,7 @@ MANDATORY INITIAL PHASES:
 BLACK-BOX TESTING - PHASE 1 (RECON & MAPPING):
 - COMPLETE full reconnaissance: subdomain enumeration, port scanning, service detection
 - MAP entire attack surface: all endpoints, parameters, APIs, forms, inputs
-- CRAWL thoroughly: spider all pages (authenticated and unauthenticated), discover hidden paths, analyze JS files — keep each crawl bounded by depth/duration, write to /workspace/scratch, and tidy up raw output once endpoints are extracted
+- CRAWL thoroughly: spider all pages (authenticated and unauthenticated), discover hidden paths, analyze JS files — keep each crawl bounded by depth/duration, and tidy up raw output once endpoints are extracted
 - ENUMERATE technologies: frameworks, libraries, versions, dependencies
 - Reconnaissance should normally happen before targeted vulnerability discovery unless the correct next move is already obvious or the user/system explicitly asks to prioritize a specific area first
 - ONLY AFTER comprehensive mapping → proceed to vulnerability testing

strix/skills/tooling/python.md

@@ -7,9 +7,9 @@ description: Run Python through exec_command in the SDK sandbox. Use the image-b
 
 Use `exec_command` for Python. There is no separate Strix Python executor.
 
-Prefer writing reusable scripts to `/workspace/scratch/<name>.py` and
-running them with `python3 /workspace/scratch/<name>.py`. For short
-one-off transformations, `python3 -c` or a small here-document is fine.
+Prefer writing reusable scripts to a `.py` file and running them with
+`python3 <name>.py`. For short one-off transformations, `python3 -c` or a
+small here-document is fine.
 
 The `shell` parameter on `exec_command` is for swapping POSIX shells
 (`bash`/`zsh`/`sh`), not for picking interpreters. Put the interpreter
@@ -84,8 +84,8 @@ automatically, so it shows up in `list_requests` and you can use
 For iterative exploit work, put code in a file:
 
 ```text
-1. Create or edit `/workspace/scratch/exploit.py` with `apply_patch`.
-2. Run it with `exec_command`: `python3 /workspace/scratch/exploit.py`.
+1. Create or edit `exploit.py` with `apply_patch`.
+2. Run it with `exec_command`: `python3 exploit.py`.
 3. Edit and rerun until the proof-of-concept is reliable.
 ```