probabl-aiprobabl-ai/skore-skills/skills/research-ml-practice/SKILL.md

research-ml-practice

Skill144 starsChanged 18 days agoBSD-3-ClauseView on GitHub

Literature research for an ML methodology concern. Trigger when explore-ml-data or build-ml-pipeline load this skill. Not for routine profiling or a single API signature — use `api get` for symbols. Not a session owner — callers distill and write project files.

1 other project uses a version of this.

Adopted by

Most recently taken up by

probabl-ai/skillsword for word, first seen Oct 27, 2026

Other versions1 project uses a version of this.
Word for word · 1
probabl-ai/skills★ 144100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-python-packageSkill
- audit-ml-pipelineSkill
- build-ml-pipelineSkill
- choose-python-librarySkill
- evaluate-ml-pipelineSkill
- explore-ml-dataSkill
- export-ml-notebookSkill
- export-ml-projectSkill
- export-ml-siteSkill
- frame-ml-problemSkill
- manage-ml-backlogSkill
- model-ml-pipelineSkill
- persist-ml-gitSkill
- plot-ml-figureSkill
- review-ml-choicesSkill
- review-ml-experimentSkill
- search-ml-literatureSkill
- setup-gitSkill
- setup-ml-projectSkill
- setup-python-envSkill
- setup-workspaceSkill
- shape-user-ideaSkill
- smoke-test-ml-pipelineSkill
- sync-ml-reportsSkill
- triage-ml-taskSkill

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 6 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Abstract the problem class: before any query (references/search.md).
line 49
Very specific:
Run the matching search loop (references/search.md).
line 53
Very specific:
Write scratch/research/ using the matching structure in references/search.md (survey: survey-<slug>.md.
line 56
Distinctive:
Do not drop, impute, or remove outliers.
line 76
Distinctive:
Do not pick the final learner or architecture.
line 77
Distinctive:
Do not treat a single blog as ground truth.
line 78
Very specific:
Do not pixi add / uv add / env add.
line 80
Very specific:
Do not run api get as a substitute for literature (symbols still go through api get in the caller).
line 82
Distinctive:
Do not copy Open questions / EDA findings onto the extras list without a source.
line 85
Very specific:
Do not search the dataset proper name, sklearn.datasets, a Kaggle slug, or “baseline pipeline”.
line 87
Distinctive:
Never answer from memory when search ran.
line 90
Distinctive:
Do not paste the scratch markdown into chat (no “Depth note —”, no survey body).
line 92

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Research ML Practice

Worker skill. Callers own the stage turn and the user-facing summary. Do not git end-turn.

Human-facing prose

Details: setup-workspace references/human_facing_prose.md. Chat stays path + one or two sentences of the finding. Do not narrate the skills framework or the wrapper CLI.

Sequence

Intake. Infer modality from dtypes / JOURNAL when obvious; use a stated domain and stage (data_analysis | model) if the caller named them. Then pick a mode (references/search.md):
- Caller passed a named concern (not the canned EDA extra-analysis question) → depth. Do not re-ask. Do not run the canned survey first.
- Caller passed the canned extra-analysis survey or “survey extra analyses” → survey.
- Neither → if JOURNAL and an EDA report exist, run the canned survey; else AskUserQuestion for a named concern, stating the modality and stage inferred this turn and that the answer only drives a literature search, no code. A file link is an addition, never the context. Do not start a depth search with an empty concern.
Abstract the problem class before any query (references/search.md). JOURNAL and EDA are context, not the answer list and not search keywords for the table’s proper name.
Run the matching search loop (references/search.md). Fetch primary pages. Follow up per promising extra if the first pass is thin or single-sourced.
Write scratch/research/ using the matching structure in references/search.md (survey: survey-<slug>.md; depth: <slug>.md with lanes). There is no templates/ directory in this skill — copy the markdown skeleton from that reference. Gitignored.
Return to the caller: scratch path and a one- or two-sentence finding. Name that candidates are laned (measure / declare / evaluate / confirm). Chat is path + those sentences only — no pasted headings, tables, or “Depth note — …” body. That is the complete user-facing deliverable even when a harness says to put the full answer in chat. If tools cannot search or write, stop there: still only path + sentences (name the intended scratch/research/ path). No hypotheses, diagnostics, planned-query bullets, or template headings in chat (that is the paste). Do not write data_analysis.md, the design note, or data/. The caller asks which extras to add.

Stop conditions

Do not drop, impute, or remove outliers. Do not change the split.
Do not pick the final learner or architecture.
Do not treat a single blog as ground truth; say when sources disagree. Thresholds need two independent sources.
Do not pixi add / uv add / env add. If code needs a library, name add-python-package and return.
Do not run api get as a substitute for literature (symbols still go through api get in the caller).
Missing skill from a caller → that caller one-line skips.
Do not copy Open questions / EDA findings onto the extras list without a source.
Do not search the dataset proper name, sklearn.datasets, a Kaggle slug, or “baseline pipeline”. Do not return learners / Pipeline steps as EDA extras.
Never answer from memory when search ran. Do not ask the user to go look something up.
Do not paste the scratch markdown into chat (no “Depth note —”, no survey body). Path + 1–2 sentences only. If tools cannot search or write, stop after that. A no-tools harness does not license pasting the note.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free