Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/bitwise-media-group/skills/python-docsnpx skills add bitwise-media-group/skills --skill python-docsgit clone --depth 1 https://github.com/bitwise-media-group/skillsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00109 | $0.00847 |
| Opus 5 | $0.00055 | $0.00424 |
| Sonnet 5 | $0.00022 | $0.00169 |
| Haiku 4.5 | $0.00011 | $0.00085 |
Grade A, and why
python-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Python documentation conventions
Docstrings are the API's reference manual: editors, help(), and doc generators render them, and
LLM coding agents read them to learn an API. These rules say where they go, what style they take,
and how the linter enforces them. For the code itself see the python-style skill.
1. A docstring on every public API, Google style
Every public module, class, function, and method carries a docstring; private (_-prefixed) and
trivial dunder methods do not need one. Use Google style — a one-line imperative summary, then
Args:, Returns:, Raises: as needed:
def parse(line: str) -> tuple[str, str]:
"""Split a KEY=VALUE line into its key and value.
Args:
line: A single ``key=value`` pair; whitespace around each side is trimmed.
Returns:
The ``(key, value)`` pair.
Raises:
ValueError: If the separator is missing or the key is empty.
"""
Document behavior and invariants the caller can rely on, not the implementation. Types live in the
annotations (see python-typing), so do not repeat them in the docstring prose.
2. Module and package docstrings
Every module starts with a docstring on line 1 (after from __future__ import annotations if
present) describing what it provides. A package's docstring lives in its __init__.py.
3. Enforce with ruff's D rules
Make docstring presence and format a lint error, not a review nit — add the D family and pin the
convention so ruff checks Google style specifically:
[tool.ruff.lint]
extend-select = ["D"]
[tool.ruff.lint.pydocstyle]
convention = "google"
[tool.ruff.lint.per-file-ignores]
"tests/**" = ["D"] # tests document themselves through their names
uv run ruff check now flags missing and malformed docstrings.
4. Generate an LLM-ready CLI reference
A Click command tree (Typer compiles to Click) already knows every command, flag, and help string — publish it as one markdown page per command that humans, search engines, and LLMs can read:
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 81 lines · 109 tokens per session scan A f49b91c08219
python-docs is a skill published in the GitHub repository bitwise-media-group/skills (2 stars, last pushed yesterday), licensed MIT. It adds 109 tokens to every session and 847 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
shipping-reproducible-results
Package completed data analysis and ML work so an independent recipient can reproduce the claimed results, verify artifact lineage, and operate the handoff within its stated scope. Use when finalizing a project, study, model package, or review bundle; not for deploying to a live system.
auditing-data-and-ground-truth
Audit datasets, joins, labels, and ground truth before analysis or modeling. Use when data meaning, row grain, time semantics, source-of-truth reliability, or label construction may invalidate conclusions; not for general model evaluation after the evidence base is already trusted.
designing-leakage-safe-experiments
Design leakage-safe machine learning experiments that mirror real deployment and support fair model comparisons. Use when defining prediction timing, feature eligibility, train-validation-test splits, baselines, metrics, or controlled model iterations; not for auditing whether raw labels are trustworthy.
diagnosing-ml-failures
Isolate the root cause of ML performance drops, inconsistent evaluations, prediction errors, and training-serving mismatches across data, labels, splits, pipelines, models, metrics, and runtime behavior. Use when investigating a reproducible failure or regression, not routine model selection or general performance…
running-decision-grade-data-science
Orchestrate an end-to-end data analysis or machine learning project from decision framing through reproducible handoff. Use when a request spans multiple lifecycle stages or an ambiguous modeling request must become a decision-ready result; use narrower audit or experiment-design skills for isolated reviews.
validating-models-and-claims
Validate trained models and analytical claims against their intended decision, independent evidence, and human-reviewed ground truth. Use when reviewing model performance, analysis conclusions, launch claims, or evaluation reports; use failure diagnosis instead when the main task is locating a known defect.