Menu
Explain training results in plain English — translates metrics into actionable insights for any audience.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Set up autonomous training monitoring — creates cron jobs to track long-running training, auto-continue pipeline when training completes.
Audit YOLO dataset quality — class distribution, annotation quality, image stats, and improvement suggestions.
Orchestrate the full active learning loop: train, analyze, push to CVAT, wait for review, pull, merge, retrain.
Analyze YOLO training runs — compares to baseline/best, checks per-class regression, analyzes training dynamics and tune convergence, writes actionable recommendations.
Run autonomous YOLO training experiments — reads training-plan.md, assesses bottlenecks, acts strategically, and delegates HP optimization to model.tune().
Profile YOLO model inference speed, FPS, and size across image sizes and export formats.
| name | explain-results |
| description | Explain training results in plain English — translates metrics into actionable insights for any audience. |
Translates YOLO training metrics into plain-English explanations. Two audience modes: non-technical (default) and technical.
Find the experiment to explain:
experiments/exp_NNN_* directory (highest NNN)Read from the experiment directory:
report.md — experiment summary with metrics and deltasmetrics.yaml — structured metrics, per-class AP, overrides, configtrain/results.csv or results.csv (if available) — epoch-by-epoch training logAlso read:
experiments/summary.md — for historical context (how this compares to other runs)experiments/dataset_profile.yaml — for dataset size, class counts, image countsskills/analyze-results/resources/metrics-guide.mdGenerate a plain-English report with these sections:
Summarize the training run in one paragraph a project manager could understand.
Template: "We trained a [model] for [X epochs] on [Y images] across [Z classes]. The training [completed normally / stopped early at epoch N / showed signs of overfitting]. This took approximately [time if available]."
Include what changed vs baseline if this is not the baseline run (e.g., "This run increased the image size from 640 to 1280 pixels").
Translate the core metrics using analogies, not jargon. Use the metrics-guide.md thresholds to provide context.
| Quality | mAP50-95 | Plain English |
|---|---|---|
| Great | >0.60 | "The model reliably finds and precisely locates objects — ready for production use" |
| Good | 0.45-0.60 | "The model catches most objects and places boxes reasonably well — solid for many applications" |
| Fair | 0.30-0.45 | "The model finds some objects but often misses or misplaces them — needs more work" |
| Poor | <0.30 | "The model is still learning — not ready for real use yet" |
Translate individual metrics:
If there is a baseline comparison, translate the delta: "Compared to our starting point, this run [improved/decreased] overall detection by [X points]. In practical terms, [concrete impact]."
List the top-performing classes by per-class AP (from metrics.yaml per_class_ap).
Use plain language: "The model is strongest at detecting [class] — it correctly finds and outlines [X]% of them."
Group into tiers using metrics-guide.md per-class thresholds:
List the worst-performing classes and provide likely reasons:
Frame constructively: "The model has the hardest time with [class] (finds only X out of 100). This is likely because [reason]. To improve this, [action]."
Provide 1-3 actionable recommendations in plain language. No ML jargon.
Map common situations to advice:
| Situation | Recommendation |
|---|---|
| High precision, low recall | "The model is cautious — it's accurate when it detects something, but misses too many objects. Adding more training images would help." |
| Low precision, high recall | "The model is trigger-happy — it finds most objects but also flags things that aren't there. Adding more examples of empty backgrounds would help." |
| One class much worse than others | "The model struggles with [class]. Collecting 50-100 more labeled examples of [class] would likely improve this." |
| Small objects missed | "Small objects are being missed. Try training with larger image sizes (e.g., 1280 instead of 640) so the model can see fine details." |
| Overall metrics plateaued | "The model has stopped improving with the current setup. Consider trying a different model architecture or adding more diverse training data." |
| Overfitting detected | "The model memorized the training images instead of learning general patterns. Reduce training duration or add more variety to training images." |
A summary table for stakeholders — no jargon, just the essentials.
| Metric | Value | Rating | What It Means |
|---------------------|--------|-----------|----------------------------------------|
| Overall Score | 0.XX | Good/Great| [one-line plain explanation] |
| Detection Accuracy | 0.XX | ... | "Right X% of the time it makes a call" |
| Object Coverage | 0.XX | ... | "Finds X% of all objects" |
| Best Class | [name] | [AP] | "Finds X% of [class] objects" |
| Worst Class | [name] | [AP] | "Finds only X% of [class] objects" |
| Training Duration | N eps | ... | "Trained for N rounds" |
When user requests --technical or asks for technical details, add these sections after the plain-English report:
Full table of all classes with AP values, sorted descending. Include delta vs baseline if available.
If results.csv is available, analyze:
List all overrides, architecture config, and key hyperparameters.
Print the report to the console.
If the user requests saving, or if the experiment has a clear ID, offer to save as experiments/explain_<exp_id>.md.