experiments

Opinionated, Pythonic way to **declare** the pipeline that goes from a data source to a predictor: data loading, preprocessing, feature engineering, estimator selection, and their composition. The pipeline is built as a **skrub DataOps graph**; every step is either a pure-Python function (stateless) attached via `.skb.apply_func`, or a scikit-learn-compatible estimator (stateful) attached via `.skb.apply`. Stops at the declared object. Out of scope: `fit` invocation, train/test split, hyperparameter tuning, persistence, evaluation. Deep-learning declarations are covered via internal `references/*.md`; skrub and scikit-learn mechanics live in sibling skills. TRIGGER when: writing or editing code that declares any link in the chain *data source → predictor* — data readers/loaders feeding a model (`read_csv`, `read_parquet`, `Dataset` classes), preprocessing or feature-engineering steps (transformers, encoders, imputers, scalers, text/image featurizers), **pure-Python data-processing functions destined for the p

Decide where files live in an ML experimentation project: where the reusable code goes, where each experiment goes, where reports are persisted. Owns the layout, the file-creation rules (one file per experiment, ask before editing an existing one), and the jupytext-style `# %%` script convention. Stops at "the file exists in the right place with the right skeleton". Never imposes a `data/` layout — the user owns that. TRIGGER when: starting a new ML project / scaffolding a workspace; about to create the first experiment file in a project; about to create `src/<pkg>/data.py`, `features.py`, `pipeline.py`, or `evaluate.py` for the first time; about to write a Jupyter notebook (`.ipynb`) for experimentation — redirect to a `# %%` script under `experiments/`; user asks where something should live, how to organize the project, or how to set up the workspace; about to add a *new experiment iteration* (must decide: new file vs. edit existing — ask the user). SKIP when: the file is clearly part of the package's exist

Single source of truth for "which Python environment manager does this project use, and how do I install a package with it?". Owns the detection table (pixi / uv / poetry / hatch / conda+mamba / pip+venv), the install / remove / upgrade commands per manager, and the bootstrap path when no manager is in place (default recommendation: pixi). Stops at "the install command was issued with the right manager and the package is importable". TRIGGER when (any of these): (1) **about to install / add / pin / upgrade / remove a Python package** — `pip install`, `pixi add`, `uv add`, `poetry add`, `conda install`, etc. — under any framing; (2) `data-science-python-stack` § "Missing dependency" surfaced a missing import and an install is the next step; (3) a workflow skill's Stop condition fired on a missing dependency (`build-ml-pipeline`, `evaluate-ml-pipeline`, `organize-ml-workspace`); (4) starting a new Python project and no manager is in place yet (bootstrap with pixi unless the user picks ot

Source the next ML experiment proposal by inspecting the skore report from the previous run — residuals, calibration, per-slice metrics, threshold behavior, statistical checks surfaced by skore. Hand the proposal back to `iterate-ml-experiment`, which writes it into `plan/NN_short_name.md` and seeks the user's approval. Stops at "a proposal (question, motivation, method outline) has been returned"; does not write any plan file itself, and does not author acceptance criteria — the user judges the result. TRIGGER when: `iterate-ml-experiment` is picking a sourcing strategy, the previous experiment has a skore report on disk, and the user says "the report shows X", "calibration looks bad", "why is slice Y so off?", "residuals look weird", or "what does the report tell us?"; the user is open-ended after a recent run — try this strategy first when a fresh report exists. SKIP when: the previous experiment hasn't run yet (no report to read); the user has a concrete modelling idea (use `iterate-from-user`); the issue

Source the next ML experiment proposal by searching the scientific / engineering literature (papers, blog posts, library docs) for techniques applicable to the current problem. Hand the proposal back to `iterate-ml-experiment`, which writes it into `plan/NN_short_name.md` and seeks the user's approval. Stops at "a proposal (question, motivation, method outline, source citations) has been returned"; does not write any plan file itself, and does not author acceptance criteria — the user judges the result. TRIGGER when: `iterate-ml-experiment` is picking a sourcing strategy and the user asks "any papers on this?", "what does the literature say?", "how do people usually handle X?", or "search for techniques for Y"; the user has run out of obvious next steps and is open-ended; a sibling strategy (methodology / diagnostic) has surfaced a problem with no obvious in-house fix and external prior art would help. SKIP when: the user has a concrete idea already (use `iterate-from-user`); the gap is clearly methodological

Source the next ML experiment proposal by auditing the *methodology* of the previous experiment(s) — split strategy, leakage risk, target encoding, sample size, metric choice, baseline comparability, randomness control. Hand the proposal back to `iterate-ml-experiment`, which writes it into `plan/NN_short_name.md` and seeks the user's approval. Stops at "a proposal (question, motivation, method outline) has been returned"; does not write any plan file itself, and does not author acceptance criteria — the user judges the result. TRIGGER when: `iterate-ml-experiment` is picking a sourcing strategy and the user says "did we get the split right?", "is this leaking?", "small sample size?", "is the baseline fair?", "is this metric the right one?"; the previous experiment's result looks suspicious (too good, too noisy, too flat) and the user wants to check the setup before iterating further; a literature / diagnostic strategy has surfaced something that turns out to be a methodology issue, not a modelling issue. SKI

Source the next ML experiment proposal from the user directly, from a GitHub issue tracker the user has pointed us at, or from a spec / notes / reference repo the user has pointed us at. Hand the proposal back to `iterate-ml-experiment`, which writes it into `plan/NN_short_name.md` and seeks the user's approval. Stops at "a proposal (question, motivation, method outline) has been returned"; does not write any plan file itself, and does not author acceptance criteria — the user judges the result. TRIGGER when: `iterate-ml-experiment` is picking a sourcing strategy and the user has offered a concrete idea ("I want to try X", "let's add Y", "tweak the encoder"); the user pastes or links a GitHub issue / discussion that describes the next experiment; the user says "use the issue tracker" or "check issue #N"; the user points us at another repo / folder / set of notes ("look at the spec at <path>", "see the notes in <repo-url>", "read what's in <dir>"). SKIP when: the user is open-ended ("what's next?") with no ide

Owns the iteration loop on top of an ML workspace: the `plan/PLAN.md` history log and the per-experiment `plan/NN_short_name.md` design notes that must be written **and validated by the user** before the matching `experiments/NN_short_name.py` is created. Drives the conversational loop where the next experiment is proposed, refined, and committed to plan, then dispatches to one of the `iterate-from-*` strategy skills when the source of the next proposal needs to be picked. Stops at "the plan file is on disk and the user has approved it". TRIGGER when: a session starts in an ML workspace that already has a `plan/` folder (read `PLAN.md` first to see where things stand); the user says "what's next", "resume", "where were we", "let's iterate", "propose the next experiment", or similar; about to create a new `experiments/NN_*.py` (the matching `plan/NN_*.md` must exist and be validated first); the user wants to record an outcome from a finished experiment in `PLAN.md`; the user asks to compare past experiments or

Decide where files live in an ML experimentation project: where the reusable code goes, where each experiment goes, where reports are persisted. Owns the layout, the file-creation rules (one file per experiment, ask before editing an existing one), and the jupytext-style `# %%` script convention. Stops at "the file exists in the right place with the right skeleton". Never imposes a `data/` layout — the user owns that. TRIGGER when: starting a new ML project / scaffolding a workspace; about to create the first experiment file in a project; about to create `src/<pkg>/data.py`, `features.py`, `pipeline.py`, or `evaluate.py` for the first time; about to write a Jupyter notebook (`.ipynb`) for experimentation — redirect to a `# %%` script under `experiments/`; user asks where something should live, how to organize the project, or how to set up the workspace; about to add a *new experiment iteration* (must decide: new file vs. edit existing — ask the user). SKIP when: the file is clearly part of the package's exist

Owns Python code style for this stack: ruff for lint + format, numpydoc for docstrings. Two responsibilities — (1) place the project's `ruff.toml` from the bundled template once the stack and workspace are in place, and (2) run ruff against any Python files Claude has just generated or edited. Stops at "the touched files pass `ruff check`." TRIGGER when (any of these): (1) a Python file was just created or edited via Write / Edit / MultiEdit — invoke this skill before declaring the task done so ruff is run on the touched files; (2) a fresh ML workspace was just scaffolded by `organize-ml-workspace` and the project has no `ruff.toml` at its root yet — drop the bundled template; (3) the user asks about lint, format, docstring style, or reaches for `black` / `isort` / `flake8` / `pydocstyle` (redirect to ruff — the stack's canonical linter, owned by `data-science-python-stack` Tier 1). SKIP when: the project is non-Python; the only edits in this turn are to Markdown / TOML / JSON / Y

Opinionated Python stack for data-science / ML work — one library per job, organized into tiers (mandatory / user choice / optional / transitive). SKILL.md is the index; per-library `references/<library>.md` files carry scope, "pick this when" / "pick something else when", and pairings. TRIGGER when (any of these): (1) **a library import fails** in this stack's domain — the answer is install, not substitute (see § "Missing dependency"); (2) **a library choice has to be made** — explicitly (the user asks "which library for X?") or implicitly (code is about to introduce a new dependency, or the project is being scaffolded and the tabular library hasn't been picked yet); (3) starting a new Python data-science / ML project; (4) the user or current code reaches for a substitute outside the stack (xgboost, lightgbm, black, isort, flake8, poetry, hatch), or reaches for `mlflow` to log params/metrics, or for `cross_val_score` + handwritten reporting — redirect: tracking → `skore` Project API, evaluation / reporting →

Single source of truth for "which Python environment manager does this project use, and how do I install a package with it?". Owns the detection table (pixi / uv / poetry / hatch / conda+mamba / pip+venv), the install / remove / upgrade commands per manager, and the bootstrap path when no manager is in place (default recommendation: pixi). Stops at "the install command was issued with the right manager and the package is importable". TRIGGER when (any of these): (1) **about to install / add / pin / upgrade / remove a Python package** — `pip install`, `pixi add`, `uv add`, `poetry add`, `conda install`, etc. — under any framing; (2) `data-science-python-stack` § "Missing dependency" surfaced a missing import and an install is the next step; (3) a workflow skill's Stop condition fired on a missing dependency (`build-ml-pipeline`, `evaluate-ml-pipeline`, `organize-ml-workspace`); (4) starting a new Python project and no manager is in place yet (bootstrap with pixi unless the user picks ot

Opinionated, Pythonic way to **declare** the pipeline that goes from a data source to a predictor: data loading, preprocessing, feature engineering, estimator selection, and their composition. The pipeline is built as a **skrub DataOps graph**; every step is either a pure-Python function (stateless) attached via `.skb.apply_func`, or a scikit-learn-compatible estimator (stateful) attached via `.skb.apply`. Stops at the declared object. Out of scope: `fit` invocation, train/test split, hyperparameter tuning, persistence, evaluation. Deep-learning declarations are covered via internal `references/*.md`; skrub and scikit-learn mechanics live in sibling skills. TRIGGER when: writing or editing code that declares any link in the chain *data source → predictor* — data readers/loaders feeding a model (`read_csv`, `read_parquet`, `Dataset` classes), preprocessing or feature-engineering steps (transformers, encoders, imputers, scalers, text/image featurizers), **pure-Python data-processing functions destined for the p

Methodology for evaluating a single sklearn-compatible learner (in particular, the `SkrubLearner` produced by `build-ml-pipeline`). Owns: which entry point to call (`skore.evaluate` first, the explicit report classes when needed), which cross-validator to pick from scikit-learn's catalogue, how to consume the structural metadata (`groups`, `times`, …) attached at build time via `.skb.mark_as_X(split_kwargs=...)`. Stops at "what does the report say". Defaults (metrics, plots) come from skore; only override on explicit user request. TRIGGER when: code calls `cross_val_score`, `cross_validate`, `classification_report`, or any handwritten metric print (`print(mean_squared_error(...))`); code calls `.skb.cross_validate(...)` (route through skore for richer output); user asks how to score, evaluate, or compare a single learner; user asks how to pick a cross-validator; user wants to see a report / metrics / diagnostic plots for a fitted learner. SKIP when: declaring the pipeline (use `build-ml-pipeline`); hyperparam

API reference for using skore as an evaluation library for scikit-learn-compatible models. Covers `evaluate` as a dispatcher returning a report, the report API (metrics / inspection / data accessors and their diagnostics), and project management to persist and compare reports across runs (local, hub, mlflow). Trigger when the user mentions skore reports, `EstimatorReport`, `CrossValidationReport`, `ComparisonReport`, `evaluate`, `Project`, `summarize`, or asks how to evaluate / inspect / persist a model with skore.

Discover the public API of the skrub package — top-level estimators, joiners, the DataOps lazy-pipeline framework, column selectors, datasets, and configuration. Use when you need to know what skrub exposes, what a class/function does, its signature, and where it lives, without grepping the source.

Look up the public API surface of any scikit-learn module — names, signatures, and one-line summaries. Use whenever you need to know what's exported from `sklearn.X`, recall a class/function signature, find the right estimator/metric/utility for a task, or check whether something is part of the public API. The reference is generated from `doc/api_reference.py`, so it matches what appears on the official docs site.