Skore: One-Line Cross-Validation Reports for scikit-learn Pipelines
Track your Data Science. Skore's open-source Python library accelerates ML model development with automated evaluation reports, smart methodological guidance, and comprehensive cross-validation analysis.
At a glance
- What is it?
- Skore is an MIT-licensed Python library from Probabl that wraps scikit-learn estimators in report objects, returning metrics summaries, ROC curves and methodological warnings instead of hand-written evaluation code. It is a convenience layer around scikit-learn, not a replacement for it, and the documentation is where the real depth lives.
- Who is it for?
- Adopt Skore if your team already lives inside scikit-learn, writes the same evaluation boilerplate in every notebook, and wants methodological warnings surfaced automatically. Do not adopt it if you need a model registry, a serving layer, or anything beyond structured reporting, because the library does not do those things.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The boilerplate problem Skore targets
Anyone who has trained more than a handful of scikit-learn models knows the routine. You split the data, loop over folds, fit the estimator, collect predictions, compute accuracy, precision, recall, build a confusion matrix, plot an ROC curve, and then repeat the whole sequence for the next candidate model. The code is nearly identical each time, and it is easy to make small mistakes: forgetting to set a random state, computing metrics on training data, or comparing models that were evaluated on different splits. The README frames this directly, saying that users "often spend significant time navigating documentation, writing boilerplate code for common evaluations, and struggling to maintain clear project structure." Skore's answer is to collapse that sequence into a single object construction. The audience is not beginners looking for an AutoML tool. It is working data scientists and ML engineers who know scikit-learn well enough to choose their own estimators, but who would rather not reimplement the evaluation scaffolding for every experiment. The library assumes you bring the data, the estimator and the domain judgement, and it supplies the reporting layer.
What CrossValidationReport actually returns
The central abstraction is the report object. In the README example, you construct CrossValidationReport(clf, X, y) with an unfitted estimator and the full dataset, and the object handles the cross-validation internally. From there, the API exposes named accessors. cv_report.help() lists what insights are available for that particular report, which matters because the available metrics and plots depend on the estimator type (a classifier exposes different outputs than a regressor). cv_report.metrics.summarize().frame() returns a metrics summary as a dataframe, and cv_report.metrics.roc() returns a plot object that you call .plot() on. The .frame() suffix is a deliberate design choice: it signals that the underlying data is tabular and can be inspected, filtered or exported rather than locked inside a rendering function. The .plot() call separates computation from display, which is useful in scripts and notebooks alike. The README does not document the full set of accessors, so the honest position is that help() is the discovery mechanism, not the documentation page. That is a real friction point for anyone who wants to know the complete API surface before writing code.
Installation and the optional extras
The README recommends a virtual environment and requires python>=3.11. The base install is pip install -U skore, which covers local use. Two extras exist: pip install -U skore[hub] if you intend to interact with Skore Hub, the separate collaborative platform, and pip install -U skore[mlflow] if you want to log projects to MLflow. Conda users can install via conda install conda-forge::skore, and the README notes this covers both local and hub use. The distinction between the base package and the extras is worth noting: the open-source library described in the README is Skore Lib, while Skore Hub is a separate product with its own page at probabl.ai/skore. Installing skore[hub] pulls in whatever client code is needed to talk to that platform, but the README does not describe what that communication looks like or what data leaves your machine. If you work in a regulated environment, that is a question to answer before installing the hub extra, not after.
The tested version matrix is narrower than you might expect
The README's Support section lists the combinations that are actually tested. Linux and Windows only, with no mention of macOS. Python 3.11 through 3.14, and scikit-learn 1.6 through 1.9, but the pairings are not uniform: Python 3.11, 3.12 and 3.13 each cover scikit-learn 1.6 and 1.9, while Python 3.14 covers 1.7, 1.8 and 1.9. That means a user on Python 3.11 with scikit-learn 1.7 falls outside the tested set, even though both versions are individually supported. The README also states the library is tested for "at most 4 versions of Python, and at most 4 versions of scikit-learn," which is an explicit statement that older releases are dropped rather than carried. For teams pinned to an older scikit-learn for reproducibility reasons, this is a real constraint. The library is at version 0.25.0 as of the August 2026 release, which signals that the API is still moving. Pre-1.0 versioning plus a rolling support window means upgrade work is a recurring cost, not a one-time one.
Methodological guidance is the differentiator, and the least documented part
Most evaluation wrappers stop at producing metrics. Skore's stated aim is broader: "Guides your decisions: Built-in methodological warnings help you avoid common pitfalls." The README does not list what those warnings are, when they fire, or whether they can be suppressed. That is the most interesting claim in the repository and the one a reader cannot verify from the supplied material. The plausible mechanism, based on the report-object design, is that the library inspects the estimator and the data characteristics during cross-validation and surfaces advisories alongside the metrics. But the specific checks, their thresholds and their false-positive behaviour are not described. A practitioner evaluating Skore should treat the guidance feature as unverified until they run it against a dataset where they already know the methodological trap exists. If the warnings fire correctly on a deliberately leaky pipeline, the feature earns its place. If they fire on everything, they become noise that gets ignored, which is worse than no warnings at all.
Where Skore is the wrong tool
Skore is a reporting and guidance layer. It is not a model registry, not a serving framework, not an experiment tracker in the sense that MLflow is, and not a feature store. The README's own description of the MLflow extra is that it lets you "log projects to MLflow," which positions Skore as a producer of structured artifacts that flow into an existing tracking system rather than a system of record itself. If your problem is deploying a model behind an API, Skore does nothing for you. If your problem is coordinating fifty experiments across a team with audit requirements, Skore Lib alone does not solve it; that is what Skore Hub is for, and it is a separate product. There is also a scale question the README does not address. The example uses 100,000 samples with a logistic regression, which is cheap. Cross-validation on an expensive estimator, a gradient-boosted model or a deep network, multiplies training cost by the number of folds. Skore does not appear to change that arithmetic, so the convenience is in the reporting, not in the compute.
How it compares to plain scikit-learn and to MLflow
The honest comparison is not against another reporting library but against the code you would write yourself. With plain scikit-learn, you call cross_validate or cross_val_score, get back arrays of scores, and build your own plots and summaries. You control every detail, and you own every line. Skore trades that control for a smaller surface area: one constructor, then named accessors. The cost is that when you need a metric or a plot the report does not expose, you fall back to manual scikit-learn code anyway, and now you maintain two evaluation paths. The comparison to MLflow is different in kind. MLflow records runs, parameters, metrics and artifacts over time so you can compare experiments historically. Skore produces a structured evaluation of a single model or pipeline at a point in time. They are complementary, and the skore[mlflow] extra exists precisely because the maintainers expect both to be used together. Neither replaces the other, and treating Skore as an MLflow substitute would be a category error.
Licence, maintenance and what to check before adopting
Skore is MIT-licensed, which is permissive and imposes few obligations beyond retaining the copyright notice and licence text. The README does not state a contributor licence agreement or a governance model, and this is not legal advice; if your organisation has policies about dependencies, review the actual LICENSE file in the repository rather than relying on the PyPI classifier. Maintenance signals visible in the supplied material are reasonable: three releases in the four weeks before the last push date (0.24.0 on 11 August 2026, 0.24.1 on 12 August 2026, 0.25.0 on 19 August 2026), an active documentation site, a Discord community and a contributing guide. The version cadence also tells you something about stability. A library that ships 0.x releases that frequently is still finding its API, and the documented support window for Python and scikit-learn versions confirms that old combinations are dropped rather than maintained. Before adopting, check three things: that your Python and scikit-learn versions sit inside the tested matrix in the README, that the specific metrics and plots you need appear in cv_report.help() for your estimator type, and that the methodological warnings behave sensibly on a dataset where you already know the answer. The first two are quick checks. The third is the one that determines whether Skore earns a place in your workflow or becomes another dependency you carry without using.
Editorial conclusion
Adopt Skore if your team already lives inside scikit-learn, writes the same evaluation boilerplate in every notebook, and wants methodological warnings surfaced automatically. Do not adopt it if you need a model registry, a serving layer, or anything beyond structured reporting, because the library does not do those things. Before committing, install it in a venv, run the CrossValidationReport example from the README against your own estimator, and confirm your Python and scikit-learn versions fall inside the tested matrix (Python 3.11 to 3.14, scikit-learn 1.6 to 1.9).
Community notes