Agent ML Skills

What job it is for, and why this one

This is a pack of fifteen machine-learning skills rather than one tool, and the useful unit is a single skill. The one this guide reads in detail is the data-cleaning skill, and it is worth singling out because it enforces a rule that is easy to state and easy to break: every statistic used to clean the data must be learned from the training split only.

One reason to use this checklist is that leakage can arise from ordering even when you know the rule: cleaning runs before the split, or a convenience call computes a mean over the whole frame. The skill names those mistakes and recommends a pipeline that separates fitting on training data from transforming other splits. That gives you specific code paths to check. Instructions alone cannot prevent leakage; you still need to inspect where fitting happens and test the resulting pipeline.

It also comes with the rest of the pipeline, and that is the real argument of the pack: the same conventions run from exploration through cleaning, feature engineering, pipelines, evaluation, tuning and serving. If you adopt one, the hand-off between them is already written down, which is the part teams usually leave to habit.

When it is the wrong tool

The installer is the first thing to think about, and it is the strongest reason to hesitate. Its documented quick start writes skills into the per-user or per-project skill directories of your agent using a package runner, and it offers an overwrite flag. Running it means files appear outside your repository, in a location your version control does not cover. If that is not acceptable in your environment, the pack is still readable and copyable by hand, but you are then maintaining a copy.

It is written for Python machine-learning work, and much of it assumes a scikit-learn and pandas world. If your stack is not that, several skills will read as advice about libraries you do not use.

It is also not a substitute for knowing your own data. The skills encode general method; they cannot know that a column in your table is a proxy for the label, which is the leakage that hurts most and the one no general checklist catches.

What it needs, and what comes back

The prerequisite is a working Python data environment and data that is already loaded. The skill does not fetch or generate data. It expects you to be at the point where a raw table exists and its quality problems have been identified, typically after an exploration pass.

What comes back is a method rather than a program. The cleaning skill sets out an ordered workflow — remove duplicates, fix types, standardise categories, handle missing values, treat outliers, then validate — with a per-situation table for missing values, a code pattern that fits transforms on the training split, a winsorising pattern whose bounds also come from the training split, and a list of named pitfalls.

It ends by asking for a hand-off artefact that is easy to skip and worth insisting on: the cleaned, typed table plus a documented list of the decisions taken, saying what was imputed, capped or dropped and why. Without that list, the next person cannot tell a deliberate cleaning decision from an accident.

Tool support, permissions and dependencies

The documentation of the project lists four coding agents it works with and gives an install target for each, and the published record labels the source check verified. The skills are plain Markdown instruction files, so any agent that reads a skill folder can use them; the installer is a convenience, not a requirement.

The permission picture has two layers, and they are different. The skill files themselves need only what the underlying work needs: reading your data and writing code and cleaned tables. The installer is the wider one — it writes files into agent configuration directories that sit outside your project and outside version control, and it documents an overwrite option. Treat the install as a deliberate step, run it from a directory you understand, and know where the files land before you run it.

The dependencies belong to your analysis, not to the skill. The code patterns reference common Python data libraries, and one skill hands off to another by name, so following the full chain means installing the stack those patterns assume. Nothing in the skills executes on its own: they are instructions your agent reads and then acts on with the tools you have given it.

Compared with one careful prompt

For a single cleaning task on a small table, a prompt that asks for all preprocessing to be fit on the training split only, and for every decision to be reported, gets you most of the way and costs nothing to maintain. The difference is completeness under pressure: the skill carries the specific pitfalls — the whole-frame mean, the silent row drop, deleting outliers that are the signal — that a short prompt leaves to the memory of the model.

The cost is that you take on a pack. Fifteen skills, an installer, a maintenance relationship with an upstream repository, and a set of conventions that may not match the ones your team already uses. If you only need the leakage rule, copying that one method into your own house standards is a defensible alternative, and it removes the installer entirely.

One more comparison is worth making explicitly: this pack teaches method, it does not review your data. If what you actually need is a second pair of eyes on a leaking pipeline you already have, a targeted review prompt against your own notebook will find more than adopting fifteen general skills will.

How to check the result yourself

A cleaned table is easy to accept and hard to trust. These checks are the ones that catch leakage and silent data loss after the fact.

• Count the rows before and after every step. Imputation keeps rows, dropping does not, and a row count that fell without a recorded decision is the clearest sign of silent loss.
• Search the pipeline for any statistic computed before the split. A mean, a median, a quantile or a category map derived from the full table is leakage even when the code looks tidy.
• Check that the imputer is fit once and reused, not fit separately on each split. Two fits produce two different mappings and quietly wrong validation numbers.
• Verify the decision list exists and names each column that was changed. A cleaned table with no record of what happened to it is not reproducible.
• Re-run the cleaning on the same input and check you get the same output. Non-determinism here usually means a random seed, a dictionary order or a sort without a tie-breaker.
• Ask whether any surviving column is a proxy for the label. That check is not in the skill, and it is the leak that survives every generic test.

Source, version and what was actually read

The judgements above were made against the commit shown on this page. When the published record moves to another commit this guide stops rendering, so it cannot end up describing a version nobody re-read.

What was read: the repository overview of the project and one skill in full — the data-cleaning skill at that commit. The other fourteen skills were seen only as one-line summaries in the overview, so nothing above should be read as a judgement about them. The installer behaviour described here comes from the documented commands and target table of the project. Nothing was installed, no package was fetched, no data was processed and no agent was run. Claims about how the method performs are read from the instructions, not observed from a run.