Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →telagod/ml
Machine learning and LLM engineering judgment, distilled from a stronger model - invoke when DECIDING whether/how to use ML or an LLM for a task (prompt vs RAG vs fine-tune vs classical); working with training/eval data or labels; building or reviewing evals for models and LLM features; designing RAG, structured output, or agent pipelines; or diagnosing why a model/LLM feature underperforms. Method-selection ladder, data and leakage discipline, eval-as-spec rules, LLM-era craft, and a trap catal
Passed 22 of 22 test cases with the skill, and 21 of 22 without it.
1 fixed21 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We are starting a new project to categorize incoming support tickets. We need guidance on deciding whether to use an LLM versus simpler rules or classic ML, and the exact sequence of steps to follow from defining metrics to testing. Please outline a concrete workflow plan and evaluation strategy for us.
| Checked | Without skill | With skill |
|---|---|---|
| Recommends starting with the simplest, lowest-cost approach such as heuristics or keyword rules before escalating to complex ML or LLM architectures. | Missed | Passed |
| Requires defining and building the evaluation benchmark suite prior to model training or prompt engineering. | Passed | Passed |
| Mandates manual inspection of raw ticket sample data prior to finalizing metrics or training. | Missed | Passed |
The instructions your model reads when the skill loads.
Rule content lives in the five files below; this SKILL.md only routes
(doctrine/04-maintenance.md governs edits to this bundle too).
| You are about to… | Read (in this folder) |
|---|---|
| Decide whether ML/an LLM is warranted, and which method rung to use | approach.md |
| Touch a dataset, labels, or splits; suspect a score is too good | data.md |
| Define success, build/judge an eval, or assess someone's metric claim | evals.md |
| Build with LLMs: prompts, RAG, structured output, agents, model choice | llm.md |
| Diagnose an underperforming model or LLM feature | data.md §1 first (read real failures), then llm.md §3 if RAG, traps.md to name the pattern |
| Review an ML project's health; name why a claim or pipeline smells wrong | traps.md |
A new ML feature usually runs approach.md (interrogate + pick the rung) →
evals.md §1 (eval BEFORE build) → data.md → then llm.md if the rung is LLM-shaped
→ skim traps.md §C before finalizing any launch or monitoring plan.
Modeling and evaluation judgment. The serving infrastructure around a model is ordinary
backend (backend bundle: APIs, queues, operate.md); experiment execution discipline is
methods (investigate/verify); whether to delegate → doctrine.
The eval is the spec; anything unmeasured is folklore. Look at the data with your
own eyes (data.md §1), climb the method ladder from the cheapest rung (approach.md
§3), and treat every surprising score as leakage until disproven (data.md §2). The
failure mode of this field is not bad models — it is unearned confidence in numbers.
test cases passed, vs 21 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.