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

2026-05-032

organize-ml-workspace

glemaitre/experiments

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

2026-05-032

python-env-manager

glemaitre/experiments

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

2026-05-032

iterate-from-diagnostic

glemaitre/experiments

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

2026-05-022

iterate-from-literature

glemaitre/experiments

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

2026-05-022

iterate-from-methodology

glemaitre/experiments

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

2026-05-022

name

iterate-from-user

description

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 idea in hand — try a different strategy (diagnostic / methodology / literature) first; the user is asking for a symbol lookup or pipeline mechanics (use the `*-api` skills); there is no `gh` CLI / GitHub access and the user wants the issue tracker — surface the gap and fall back to direct user input. HOW TO USE: this skill is shallow — it elicits the proposal and returns it. If the user has a verbal idea, ask the three shaping questions in the body and synthesize a proposal. If a GitHub issue is the source, fetch it with `gh issue view <N>` (or `gh api`), summarize it through the same three-question lens, and flag anything the issue doesn't answer. If a spec / notes repo is the source, read the relevant files (README, proposal docs, referenced notebooks) and summarize through the same lens. Always return: question / motivation / method outline — not a plan file, not acceptance criteria.

Iterate from user

Source: the user (directly, or via a GitHub issue they own). Output: a proposal handed back to iterate-ml-experiment.

Output contract (read this before the body)

This skill never writes plan/ files and never authors acceptance criteria. It returns a Proposal block back to iterate-ml-experiment (full shape in § What is returned at the bottom): Question, Motivation (with the user quote, issue link, or spec-repo path as Source), Method outline, Open gaps. Required:

Every Proposal must answer all three shaping questions (see § The three shaping questions). Missing → ask the user before returning.
GitHub-issue path: check gh auth status first; resolve repo per § Resolution priority; fetch comments if the issue body is short.
Spec / notes repo path: confirm the path / URL the user gave, read the relevant files only (don't crawl the whole repo), and cite specific files in the Source field.
Goal shifts (different output shape, downstream consumer, or metric class) require user confirmation of a PLAN.md Status update before returning the proposal — see § Stop conditions.

There is no "no proposal" outcome for this skill: it only fires when the user has volunteered an idea (or pointed at an issue / repo). If the user is open-ended without an idea, the dispatcher in iterate-ml-experiment asks them directly via the sourcing menu instead of invoking this skill.

Stop conditions

Don't write plan/ files. That belongs to iterate-ml-experiment. This skill returns a proposal as conversation text or structured fields; the parent skill drafts the file.
Don't infer an issue's content. If the user references an issue, fetch it (gh issue view <N> / gh api) — don't reconstruct from the issue title alone.
Don't paper over missing fields. If the user's idea (or the issue) doesn't answer one of the four shaping questions, surface the gap to the user before returning the proposal.
Check gh auth before fetching anything. Before any gh issue view / gh api call, run gh auth status (cheap, cached). If unauthenticated or on the wrong host, do not retry blindly — ask the user to either run gh auth login themselves (suggest they type ! gh auth login in the prompt so it runs in this session) or paste the issue body directly. A failed gh call surfaces a confusing error; the auth check makes the failure mode explicit.
Flag goal shifts before returning the proposal. If the user's idea (or the issue) materially changes the project goal as recorded in PLAN.md Status — different output shape (point estimate → prediction interval), different downstream consumer (offline batch → online serving), different metric class (squared error → coverage) — that's not just a method change. Surface it as a question to the user before returning the proposal: "this would update PLAN.md Status from to ; confirm or amend the goal first?" The parent skill's per-experiment plan file should not silently re-define what success means while the Status block still reflects the old goal.

The three shaping questions

Every proposal returned from this skill must answer:

What are we trying to learn? (turns "try X" into a hypothesis)
Why now? (the specific reason this idea surfaced — quote the user, link the issue, cite the spec-repo file)
What changes vs. the previous experiment? (which file in src/<pkg>/ is touched, in prose — not code)

Missing → ask the user. Don't fabricate.

No "how will we know it answered the question?" question. That's an acceptance-criteria slot, and the skill does not author those — the user reads the headline result after the run and judges. See iterate-ml-experiment § "What this skill does NOT do".

Three intake paths

Direct user input

The user has a verbal or written idea. Ask the three questions in order, in plain language. Quote them back when summarizing the proposal so the framing stays theirs. Hand the synthesis to iterate-ml-experiment.

Spec / notes repo

The user pointed us at a separate repo / folder / set of notes ("read the spec at ~/code/<repo>", "see the notes at https://github.com/<owner>/<repo>", "look at <dir> for ideas"). Treat it as a structured input source distinct from their own verbal idea — the proposal still needs to come back through the three-question lens.

Procedure:

Confirm the path / URL the user gave; if it's remote and not yet cloned, ask where to clone it (don't pick silently).
Read selectively, not exhaustively. Start with README.md / SPEC.md / NOTES.md / a top-level proposal doc; if the user named a specific file or directory, prioritize that. Don't crawl every file — that hides the actual signal.
Map to the three shaping questions. What does the spec want to learn? What's the motivation as the spec frames it? What concretely changes in src/<pkg>/? Quote the spec verbatim when answering "why now?".
Cite specifically. The Source field in the returned Proposal must reference the file paths (and line numbers if useful) — not just the repo name.
Flag gaps. If the spec doesn't answer one of the three questions, ask the user before returning — same rule as for issues.

GitHub issue tracker

The user pointed us at an issue (number, link, or "check the tracker").

Resolution priority (never silently guess). Pick the owner/repo using the first rule that matches:

Explicit URL in the user's message (https://github.com/<owner>/<repo>/issues/<N>) — wins unconditionally.
org/repo#N shorthand in the user's message (probabl-ai/skore#42) — wins over current context.
Bare #N or "issue 42" with no qualifier — fall back to the current gh context (gh repo view --json nameWithOwner to confirm). If that returns nothing, ask the user before fetching.

Then fetch:

gh issue view <N> --json title,body,labels,url for the baseline.
If the issue body is short (<200 chars) or visibly under-specified, also pull the latest comments — gh issue view <N> --json title,body,labels,url,comments or gh api repos/<owner>/<repo>/issues/<N>/comments — and read the most recent ~5. The actual proposal often lives in the thread, not the top-post.

Map the assembled issue (body + relevant comments) to the three shaping questions; flag missing fields and ask the user to clarify before returning the proposal. The proposal returned must include the issue link as Source so the per-experiment plan file can cite it.

What is returned

A short structured block, not a plan file:

Proposal (from: user | issue #<N> | spec-repo:<path>):
  Question:        <one sentence>
  Motivation:      <quote / link / spec-file path>
  Method outline:  <prose; which file in src/<pkg>/ is touched>
  Open gaps:       <anything the user / issue / spec didn't answer>

iterate-ml-experiment consumes this and drafts plan/NN_short_name.md. No Success field — the skill deliberately does not author acceptance criteria; the user judges the result post-run.

Companion skills

iterate-ml-experiment — the caller; owns the plan file.
iterate-from-literature / iterate-from-methodology / iterate-from-diagnostic — sibling strategies for when the user is open-ended.