Sandbox File Discovery And Validation

Sandbox File Discovery and Validation

Use this skill when working in constrained or sandboxed shell environments where common folders like ~/Desktop, ~/Documents, or ~/Downloads may not exist, may be inaccessible, or may not be where task files are stored.

The goal is to:

1. discover files from actual accessible roots,
2. avoid brittle path assumptions,
3. generate outputs in known locations, and
4. explicitly validate that outputs were created and match expectations.

Core principles

• Do not assume GUI-era user folders exist.
• Start from the current working directory and other confirmed workspace roots.
• Use recursive search from known roots, not from / unless necessary.
• Prefer deterministic output paths you control.
• After creating an artifact, verify it exists, is readable, and matches the requested form.

When to use this

Use this pattern when:

• you need to locate input files in an unfamiliar sandbox,
• the environment may be ephemeral or nonstandard,
• you are producing files for the user,
• success depends on the actual contents or structure of the output.

Recommended workflow

1) Establish your real working roots

Begin by identifying where you are and what directories are actually available.

Example: pwd ls -la find . -maxdepth 2 -type d | sort

If needed, inspect nearby likely roots: ls -la /tmp ls -la /workspace 2>/dev/null || true ls -la /workspaces 2>/dev/null || true ls -la /mnt/data 2>/dev/null || true

Treat only confirmed, readable directories as search roots.

2) Avoid assumed folders

Do not begin with paths like:

• ~/Desktop
• ~/Documents
• ~/Downloads

unless you have already confirmed they exist and are relevant.

Bad: find ~/Desktop -name "*.xlsx"

Better: find . -type f -name "*.xlsx" or, if a root is confirmed: find /workspace -type f -name "*.xlsx" 2>/dev/null

3) Search from known roots with bounded, focused queries

Prefer targeted searches over broad filesystem scans.

Useful patterns: find . -type f | sort find . -type f -iname "*report*" find . -type f \( -iname "*.csv" -o -iname "*.xlsx" -o -iname "*.json" \)

If multiple roots are known: find . /workspace /mnt/data -type f 2>/dev/null | sort

Guidelines:

• suppress permission noise with 2>/dev/null when appropriate,
• filter by extension or name fragment,
• sort output for stable inspection,
• keep searches bounded to known roots.

4) Choose a deterministic output location

When generating a file, write it somewhere explicit and easy to re-check.

Good patterns:

• current directory,
• a task-specific subdirectory like ./output,
• a confirmed writable workspace directory.

Example: mkdir -p output python make_result.py --out output/final.xlsx

Avoid writing to guessed locations that may not exist.

5) Immediately validate the output artifact

Never assume generation succeeded just because a command exited successfully.

At minimum, confirm:

• the file exists,
• the path is the one you intended,
• the file is non-empty when applicable,
• the format or structure matches the task.

Basic checks: ls -l output/final.xlsx test -f output/final.xlsx && echo "exists" test -s output/final.xlsx && echo "non-empty" file output/final.xlsx

For text-like outputs: head -n 20 output/result.csv wc -l output/result.csv

For structured outputs, inspect with the relevant tool:

• CSV: preview headers and row counts
• JSON: parse and inspect keys
• ZIP-like formats such as .xlsx: verify internal structure or open with a library
• generated code/config: run syntax or schema checks if available