| name | Python (as a tool) |
| description | Python as a general-purpose problem-solving capability — use it to DO things (CV, parsing, APIs, data), not just to write programs. When stuck, reach for Python and install what you need into your dedicated Tool Environment. if you need a new package and you are unsure. ask the user for guidance and confirm before installing. |
| metadata | {"version":"1.0.0","maxent":{"requires":{"bins":[]}}} |
Python as a tool
This skill is not about writing Python programs for the user. It's about treating Python as your own runtime toolbox — a way to extend your capabilities on demand by installing a library and executing a short script, the same way a human operator would reach for a terminal.
The core idea
When a user asks for something and your first instinct is "I can't do that, I don't have the tools," stop and ask: could a Python library do this in under 20 lines? Almost always the answer is yes.
Examples of tasks that feel impossible but are actually one uv pip install away:
| Task | Library |
|---|
| "What's in this image?" (basic CV / OCR) | pillow, pytesseract, transformers |
| "Summarise this PDF" | pypdf, pdfplumber |
| "Extract tables from this spreadsheet" | openpyxl, pandas |
| "Transcribe this audio clip" | faster-whisper |
| "What does this .docx / .pptx contain?" | python-docx, python-pptx |
| "Convert HEIC to JPG" | pillow-heif |
| "Diff these two JSON files semantically" | deepdiff |
| "Parse this XML / YAML / TOML" | stdlib, pyyaml, tomllib |
| "Scrape this page" (when the browser tool is overkill) | httpx, beautifulsoup4 |
| "Query this SQLite / DuckDB file" | stdlib sqlite3, duckdb |
| "Analyse this CSV" (stats, plots) | pandas, matplotlib |
| "Generate a QR code / barcode" | qrcode, python-barcode |
| "Hash / sign / verify this file" | stdlib hashlib, cryptography |
| "Resize / crop / annotate this image" | pillow |
The list is not exhaustive — it's a pattern. If a Python package exists that solves the problem, you can use it.
The two environments — never mix them
You have two entirely separate Python environments. The difference matters:
1. The Tool Environment (yours)
- Location: shown as
Tool Python in RUNTIME CONTEXT (the interpreter path) and Tool Env Root (the venv directory).
- Purpose: YOUR persistent toolbox. Packages you install here stay across sessions and extend your capabilities forever.
- Who owns it: you. Curate it like a toolbox you trust.
- When to install into it: whenever you need a capability you don't currently have, in order to complete a task for the user.
2. Project Environments (the user's)
- Location: a
.venv inside whatever project directory the user is working in.
- Purpose: isolate the user's own project dependencies.
- Who owns it: the user.
- When to create one: only when the user explicitly asks you to start or work on a Python project of their own.
Never cross the streams. Never install a user-project dependency into your Tool Environment. Never install your own capability packages into a user's project venv. If the user asks you to "install numpy" while you're working in their project directory, that goes in their .venv. If you decide to install numpy because you need it to analyse a CSV for them, that goes in your Tool Env.
How to use the Tool Environment
All commands use uv. Do not use pip, python -m pip, pipx, or --user installs. uv is the only blessed package manager here because it is deterministic, fast, and explicit about which environment it targets.
Use the exact path shown as Tool Python in RUNTIME CONTEXT. The examples below use $TOOL_PY as a placeholder — substitute the real interpreter path.
Install a package
uv pip install --python "$TOOL_PY" <package>
Install multiple packages
uv pip install --python "$TOOL_PY" pillow pytesseract numpy
Check what's installed
uv pip list --python "$TOOL_PY"
Run a one-off script
"$TOOL_PY" - <<'PY'
from PIL import Image
img = Image.open("/path/to/image.png")
print(img.size, img.mode)
PY
Run a saved script
"$TOOL_PY" /absolute/path/to/script.py arg1 arg2
Run a module
"$TOOL_PY" -m some_module --flag
Uninstall (rare — only if something broke)
uv pip uninstall --python "$TOOL_PY" <package>
Workflow: "I don't have a tool for that"
Old reflex: say "I can't do that."
New reflex:
- Name the capability you need. ("I need to read pixel data from an image.")
- Pick a library. Prefer well-known, actively-maintained ones (
pillow over some abandoned fork).
- Install it into the Tool Env with
uv pip install --python "$TOOL_PY" <pkg>.
- Write the smallest script that solves the problem. A heredoc is usually enough — no need to create a
.py file unless it's genuinely reusable.
- Run it with
"$TOOL_PY" - <<'PY' ... PY.
- Interpret the output and answer the user.
If the first library is wrong, uninstall it and try another. The Tool Env is yours to experiment in.
Guardrails
- Don't install recklessly. Check first if the task can be solved with the stdlib (
json, csv, sqlite3, hashlib, pathlib, urllib, xml.etree, zipfile, tarfile, re, statistics, collections, itertools — these are already available).
- Don't install huge models by accident. Libraries like
transformers or torch can pull multi-GB downloads. Warn the user before doing this and confirm they want to proceed.
- Don't install packages for one-off user projects into the Tool Env. Those belong in the project venv.
- Don't use
sudo pip, pip install --user, or any system Python mutation. Ever.
- Prefer pure-Python libraries when the difference is marginal — they install faster and more reliably across OSes.
- Network-dependent installs can fail. If
uv pip install fails, report the error clearly rather than silently falling back.
When NOT to use this skill
- When a dedicated tool already exists (e.g. use the
browser tools for web interaction, not requests + beautifulsoup4, unless the page is trivially static).
- When
bash + standard CLI tools (jq, grep, awk, sed, ffmpeg, imagemagick) are simpler.
- When the user is asking you to write a Python program for them — that's a normal coding task, not this skill. This skill is specifically about Python as your runtime capability.
Mental model
Think of the Tool Environment as a personal workshop. Every time you install a package into it, you're adding a new tool to the shelf — and that tool is still there next session. Over time, your workshop grows into a capability set tailored to the kinds of problems this user brings you.
Python is not just a language you write. It's a way you act.
