Claude Skill

ml-experiment-standards

Always invoke for training, validating, tuning, benchmarking, or claiming readiness of a predictive model. Covers leakage audits, spatial and grouped splits, metrics, reproducibility, and honest reporting. Invoke especially when spatial dependence, split design, or deployment geo

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download muend-geoai-skills-skills_ml-experiment-standards-096e5d4.zip · 5 KB
Part of muend/geoai-skills — 18 skills

Install

skills CLI npx skills add https://github.com/muend/geoai-skills/tree/main/skills/ml-experiment-standards
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install muend-geoai-skills@llmmart
Git git clone https://github.com/muend/geoai-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole muend/geoai-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

ML Experiment Standards

Purpose: every ML job (quick prototypes included) is reproducible, leakage-free, and metric-justified. These are not optional polish; every skipped item typically returns as "the model collapsed in production" or "the result didn't replicate".

1. EDA comes first

Before any model, produce and show: distributions, missingness rates, outliers, target balance, salient correlations. Metric and loss choice depend on this information; a model recommendation without EDA is a guess.

2. Leakage audit

At every split decision, answer explicitly (and write the answer as a code comment): "Does the training set contain indirect information about any test sample?"

Data type Correct split Why
Independent samples Stratified k-fold Preserves class ratios
Time series TimeSeriesSplit / walk-forward Future must not leak into past
Spatial data Spatial block CV — see references/spatial-cv-protocol.md Neighbors are near-duplicates
Grouped data (patient, parcel, scene) GroupKFold A group must not straddle the split
  • Scalers/encoders/imputers are fit on train only; the clean path is sklearn.pipeline.Pipeline — CV then fits correctly by construction.
  • Target-derived features (target encoding etc.) must be computed out-of-fold, and shown to be.

The spatial protocol in references/spatial-cv-protocol.md is the single canonical source for this repo — other skills link here; do not restate it.

3. Metric selection — justified

Never choose a metric by default; write a one-sentence rationale:

  • Imbalanced classes → F1 / AUC-PR, not accuracy (accuracy rewards majority-class memorization).
  • Segmentation → IoU/Dice (pixel accuracy is inflated by background).
  • Regression → RMSE (sensitive to large errors) vs MAE (robust) vs R² (variance explained) — justify from the use case.
  • Every point estimate gets uncertainty: bootstrap CI or mean ± std across CV folds. A single number hides whether a difference is signal or noise.

4. Reproducibility skeleton

Every training script follows this shape (script-first; no notebook magic):

"""Experiment: <name>. Goal and success criterion: <one sentence>."""
from dataclasses import dataclass, asdict
import json, random
import numpy as np

@dataclass
class Config:
    seed: int = 42
    lr: float = 1e-3
    batch_size: int = 32
    epochs: int = 100
    patience: int = 10  # early stopping

def set_seed(seed: int) -> None:
    random.seed(seed)
    np.random.seed(seed)
    # if torch: torch.manual_seed(seed); torch.cuda.manual_seed_all(seed)

def main(cfg: Config) -> None:
    set_seed(cfg.seed)
    ...  # data -> split -> pipeline -> train -> evaluate
    with open("runs/run_meta.json", "w", encoding="utf-8") as f:
        json.dump({"config": asdict(cfg), "metrics": metrics}, f, indent=2)

if __name__ == "__main__":
    main(Config())
  • Config lives in a dataclass/YAML, never hardcoded — sweeps and run comparison depend on it.
  • Pin library versions (pip freeze > requirements.txt).
  • Use MLflow/W&B when available; the JSON log above is the minimum.

5. Deep learning extras

  • Loss rationale: Dice/Dice+CE for imbalanced segmentation; write why. Focal only after comparison — not a free win.
  • Augmentation rationale: state which transforms respect the physics of the problem (orientation-dependent tasks forbid some rotations; multispectral forbids naive color jitter).
  • Overfitting control: early stopping with patience + a train/val curve in the report; no curve, no "the model is good".
  • Capacity order: small model + simple baseline first (logistic regression, RF); a deep model that can't beat the baseline is a data problem, not an architecture problem.
  • EO-specific chipping/inference details → geo-deep-learning.

6. System context (MLOps)

Position every model in its chain in one paragraph: data source → cleaning → features/versioning → training → evaluation → deployment (batch/real-time) → monitoring (data/model drift). Even for a prototype, note "what this step becomes in production".

7. Report format

## Experiment: <name>
- Data: n=<>, split: <strategy + rationale>
- Baseline: <model> → <metric ± CI>
- Model: <model> → <metric ± CI>
- Leakage audit: <what was checked>
- Next step: <single recommendation>

When reporting differences, respect statistical honesty: if the gap doesn't exceed the across-fold std, say "no clear difference" — no p-hacking, no selective reporting.

Execution contract

  • Workflow: define prediction target and decision use; establish a baseline; audit leakage; create spatially valid splits; train reproducibly; quantify uncertainty; inspect errors and deployment fit.
  • Decision rules: apply this skill only to predictive model experiments; use spatial statistics for inference, geostatistics for sampled-surface estimation, and descriptive analysis without forcing a model.
  • Verification protocol: reproduce from a clean environment, compare against baseline across folds or seeds, inspect spatial residuals, verify split independence, and test the final decision threshold.
  • Failure modes: invalidate uplift claims for leakage, post-split preprocessing, inappropriate metrics, non-independent test units, selective runs, or train-serving skew.
  • Deliverables: experiment configuration, split and seed manifest, baseline and model metrics with uncertainty, leakage audit, error analysis, artifacts, and deployment caveats.
  • Source freshness: consult the authoritative source registry before using version-sensitive split, metric, or reproducibility APIs.
Files (geoai-skills)
  • agents
    • openai.yaml 232 B
      interface:
        display_name: "ML Experiment Standards"
        short_description: "Design honest, reproducible ML experiments"
        default_prompt: "Use $ml-experiment-standards to audit this model experiment for leakage and metric validity."
      
  • references
    • authoritative-sources.md 767 B
      # Authoritative sources
      
      - Last verified: 2026-07-19
      - Review cadence: every 3 months
      - Refresh triggers: scikit-learn or PyTorch major release; metric or split API change
      
      ## Canonical sources
      
      - [scikit-learn cross-validation guide](https://scikit-learn.org/stable/modules/cross_validation.html) — split and evaluation APIs.
      - [scikit-learn common pitfalls](https://scikit-learn.org/stable/common_pitfalls.html) — leakage, preprocessing, and reproducibility risks.
      - [PyTorch reproducibility notes](https://docs.pytorch.org/docs/stable/notes/randomness.html) — deterministic execution limits.
      
      Pin implementations and record split units, seeds, preprocessing fit scope, metric definitions, and dependency versions. Re-run baselines after dependency upgrades.
      
    • spatial-cv-protocol.md 3.2 KB
      # Spatial cross-validation protocol (canonical)
      
      This is the single authoritative statement of the spatial split rule for
      this repo. Other skills (`geoai-orchestrator`, `geo-deep-learning`,
      `remote-sensing-analysis`, `geostatistics-interpolation`,
      `google-earth-engine`) link here instead of restating it.
      
      ## Why random splits are fraudulent on spatial data
      
      Tobler's first law: near things are more related than distant things.
      Nearby observations (adjacent pixels, chips, parcels, stations) are
      near-duplicates. A random train/test split scatters near-duplicates across
      both sides, so the model is evaluated on data it has effectively seen.
      Reported metrics inflate — often dramatically (10+ points of mIoU/accuracy
      in segmentation tasks is common) — and the model fails on genuinely new
      areas. This is not a minor bias; it is the difference between a publishable
      result and a fake one.
      
      ## The rule
      
      **Split by geographic block, scene, or region — never by random
      observation.** The unit of assignment must be spatially coherent and larger
      than the autocorrelation range of the phenomenon.
      
      ## Practical recipe
      
      1. **Assign block IDs.** Overlay a coarse grid over the study area (block
         size ≥ the autocorrelation range — estimate from a variogram of the
         target or a key predictor; when unknown, use a generous size, e.g.
         several km for 10 m imagery tasks).
      
         ```python
         import numpy as np
      
         block = 5_000  # meters — must exceed autocorrelation range
         gdf["block_id"] = (
             (gdf.geometry.x // block).astype(int).astype(str)
             + "_"
             + (gdf.geometry.y // block).astype(int).astype(str)
         )
         ```
      
      2. **Split blocks, not rows.** `GroupKFold` (or `StratifiedGroupKFold`)
         with `groups=block_id`; for a single hold-out, sample block IDs.
      
         ```python
         from sklearn.model_selection import GroupKFold
      
         for tr, te in GroupKFold(n_splits=5).split(X, y, groups=gdf["block_id"]):
             ...
         ```
      
      3. **Verify zero spatial overlap.** Compute the minimum distance between
         train and test geometries per fold; it should be ≥ the intended
         separation. For chips: assert no train chip's bounds intersect any test
         chip's bounds.
      
      4. **Document the split** in run metadata: block size, n blocks per fold,
         min train-test distance, and the map of fold assignment (a plotted fold
         map is the fastest reviewer check).
      
      ## Variants
      
      - **Scene/region hold-out**: for generalization claims across areas, hold
        out entire scenes/regions/cities — the strongest and most honest test.
      - **Buffered leave-one-out (spatial LOO)**: for small n point datasets
        (interpolation), exclude a buffer around each test point from training.
      - **Grouped non-spatial structure**: if observations also cluster by
        non-spatial keys (patient, farm, survey team), group by the coarser of
        the two structures — or both.
      - **Time + space**: when data are spatio-temporal, block in both
        dimensions; a model tested on the same place in a different month has
        leaked place.
      
      ## Honest reporting
      
      Report the spatially blocked metric as THE metric. If you also computed a
      random-split metric, you may show it only as an explicit "upper bound
      under leakage" comparison — never as the headline number. Expect the
      blocked number to be worse; that is the point.
      
  • SKILL.md 6.2 KB
    ---
    name: ml-experiment-standards
    description: >-
      Always invoke for training, validating, tuning, benchmarking, or claiming
      readiness of a predictive model. Covers leakage audits, spatial and grouped
      splits, metrics, reproducibility, and honest reporting. Invoke especially
      when spatial dependence, split design, or deployment geography is unknown;
      uncertainty is a reason to use this skill. Do not trigger for descriptive
      EDA or non-predictive statistical inference.
    license: MIT
    metadata:
      author: Muhammed Enes Duran
    ---
    
    # ML Experiment Standards
    
    Purpose: every ML job (quick prototypes included) is reproducible,
    leakage-free, and metric-justified. These are not optional polish; every
    skipped item typically returns as "the model collapsed in production" or
    "the result didn't replicate".
    
    ## 1. EDA comes first
    
    Before any model, produce and show: distributions, missingness rates,
    outliers, target balance, salient correlations. Metric and loss choice
    depend on this information; a model recommendation without EDA is a guess.
    
    ## 2. Leakage audit
    
    At every split decision, answer explicitly (and write the answer as a code
    comment): "Does the training set contain indirect information about any
    test sample?"
    
    | Data type | Correct split | Why |
    |---|---|---|
    | Independent samples | Stratified k-fold | Preserves class ratios |
    | Time series | TimeSeriesSplit / walk-forward | Future must not leak into past |
    | **Spatial data** | Spatial block CV — see `references/spatial-cv-protocol.md` | Neighbors are near-duplicates |
    | Grouped data (patient, parcel, scene) | GroupKFold | A group must not straddle the split |
    
    - Scalers/encoders/imputers are **fit on train only**; the clean path is
      `sklearn.pipeline.Pipeline` — CV then fits correctly by construction.
    - Target-derived features (target encoding etc.) must be computed
      out-of-fold, and shown to be.
    
    The spatial protocol in `references/spatial-cv-protocol.md` is the single
    canonical source for this repo — other skills link here; do not restate it.
    
    ## 3. Metric selection — justified
    
    Never choose a metric by default; write a one-sentence rationale:
    
    - Imbalanced classes → **F1 / AUC-PR**, not accuracy (accuracy rewards
      majority-class memorization).
    - Segmentation → **IoU/Dice** (pixel accuracy is inflated by background).
    - Regression → RMSE (sensitive to large errors) vs MAE (robust) vs R²
      (variance explained) — justify from the use case.
    - Every point estimate gets uncertainty: bootstrap CI or mean ± std across
      CV folds. A single number hides whether a difference is signal or noise.
    
    ## 4. Reproducibility skeleton
    
    Every training script follows this shape (script-first; no notebook magic):
    
    ```python
    """Experiment: <name>. Goal and success criterion: <one sentence>."""
    from dataclasses import dataclass, asdict
    import json, random
    import numpy as np
    
    @dataclass
    class Config:
        seed: int = 42
        lr: float = 1e-3
        batch_size: int = 32
        epochs: int = 100
        patience: int = 10  # early stopping
    
    def set_seed(seed: int) -> None:
        random.seed(seed)
        np.random.seed(seed)
        # if torch: torch.manual_seed(seed); torch.cuda.manual_seed_all(seed)
    
    def main(cfg: Config) -> None:
        set_seed(cfg.seed)
        ...  # data -> split -> pipeline -> train -> evaluate
        with open("runs/run_meta.json", "w", encoding="utf-8") as f:
            json.dump({"config": asdict(cfg), "metrics": metrics}, f, indent=2)
    
    if __name__ == "__main__":
        main(Config())
    ```
    
    - Config lives in a dataclass/YAML, never hardcoded — sweeps and run
      comparison depend on it.
    - Pin library versions (`pip freeze > requirements.txt`).
    - Use MLflow/W&B when available; the JSON log above is the minimum.
    
    ## 5. Deep learning extras
    
    - **Loss rationale**: Dice/Dice+CE for imbalanced segmentation; write why.
      Focal only after comparison — not a free win.
    - **Augmentation rationale**: state which transforms respect the physics
      of the problem (orientation-dependent tasks forbid some rotations;
      multispectral forbids naive color jitter).
    - **Overfitting control**: early stopping with patience + a train/val
      curve in the report; no curve, no "the model is good".
    - **Capacity order**: small model + simple baseline first (logistic
      regression, RF); a deep model that can't beat the baseline is a data
      problem, not an architecture problem.
    - EO-specific chipping/inference details → `geo-deep-learning`.
    
    ## 6. System context (MLOps)
    
    Position every model in its chain in one paragraph: data source →
    cleaning → features/versioning → training → evaluation → deployment
    (batch/real-time) → monitoring (data/model drift). Even for a prototype,
    note "what this step becomes in production".
    
    ## 7. Report format
    
    ```
    ## Experiment: <name>
    - Data: n=<>, split: <strategy + rationale>
    - Baseline: <model> → <metric ± CI>
    - Model: <model> → <metric ± CI>
    - Leakage audit: <what was checked>
    - Next step: <single recommendation>
    ```
    
    When reporting differences, respect statistical honesty: if the gap
    doesn't exceed the across-fold std, say "no clear difference" — no
    p-hacking, no selective reporting.
    
    ## Execution contract
    
    - **Workflow:** define prediction target and decision use; establish a baseline; audit leakage; create spatially valid splits; train reproducibly; quantify uncertainty; inspect errors and deployment fit.
    - **Decision rules:** apply this skill only to predictive model experiments; use spatial statistics for inference, geostatistics for sampled-surface estimation, and descriptive analysis without forcing a model.
    - **Verification protocol:** reproduce from a clean environment, compare against baseline across folds or seeds, inspect spatial residuals, verify split independence, and test the final decision threshold.
    - **Failure modes:** invalidate uplift claims for leakage, post-split preprocessing, inappropriate metrics, non-independent test units, selective runs, or train-serving skew.
    - **Deliverables:** experiment configuration, split and seed manifest, baseline and model metrics with uncertainty, leakage audit, error analysis, artifacts, and deployment caveats.
    - **Source freshness:** consult [the authoritative source registry](references/authoritative-sources.md) before using version-sensitive split, metric, or reproducibility APIs.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related