Use when a release reaches awaitingverdict (or you are woken for an incident) - how to read runtime logs, error groups, health and smoke evidence for the release's component and decide finish, re-check, roll back or hand to a human.
Use when you need the end-to-end merge -> deploy -> watch -> verdict sequence for a delivery mode, or a tool result you did not expect (refusal, park, tag exists).
Use before and after calling rollbackrelease - what a rollback restores per delivery mode, when a schema change makes a code rollback unsafe, how to work and report manualsteps, and what to do when rollbackrelease refuses.
Use when you write or revise the analiz deliverable - the ONE self-contained HTML report (spec and plan as sections) a human reviews passage by passage.
Use when an analiz question needs the human, not the code, to decide - recording it with recordopenquestions, judging blocking vs non-blocking, and resuming the report after an answer.
Use when an approved analiz spans more than one repository - split the work per repository and open one or more tasks per repository, each carrying its own plan slice.
Use in codereview when the diff touches input handling, auth, queries, files, outbound requests, secrets, dependencies or LLM calls, and in analysis for any new endpoint or data flow.
Use when you write the context and design sections of an analiz report - components, exact interfaces, data flow, errors, decision record, out of scope.
Use when an analiz task arrives in done (approved) - turn the approved split into implementation tasks with repository, AC, derivedfrom and ordering arguments.
Use when you are about to hand off any number, table, chart or analysis someone will act on (a metric query, a dbt mart, a report, an experiment readout) — the pre-delivery checklist for data quality, calculation, reasonableness and presentation, and the pitfalls that produce plausible wrong numbers.
Use when tools from the jupyter, duckdb, dbt, mlflow, huggingface or postgres MCP servers appear in your tool list, or before reaching for one — what each is good for, what it can damage, and the CLI fallback when it is not connected.
Use when adding or changing a scheduled data or ML pipeline — Dagster assets, Prefect flows, Airflow DAGs or a cron'd entrypoint — idempotent partitioned stages, retries, backfills, quality gates, and testing the pipeline without the scheduler.
Use when data crosses a boundary into your code (file, API, warehouse table, upload, model input or output), when a join or cleaning step can change row counts, or when adding pandera, Great Expectations, Pydantic or dbt checks.
Use when dataframe code is slow or runs out of memory, when data outgrows pandas, or when writing pandas 3, Polars or DuckDB code — vectorisation, dtypes, Copy-on-Write, lazy and out-of-core execution, and measuring before and after.
Use when writing or changing PyTorch code — model, Dataset/DataLoader, training and evaluation loops, determinism, mixed precision, torch.compile, checkpoints with safetensors, Hugging Face models, ONNX export, and tests that run on CPU.
Use when you meet a new dataset, table, file or source, before building features or a model on it, or when a number looks wrong — profile grain, keys, nulls, cardinality, time coverage and target balance, and persist what you learn as code.
Use when a change trains a model, reports a metric, or touches seeds, data or model versions, the lockfile, MLflow or DVC — what every run must log, seeding, environment pinning, data versioning and keeping tests off the shared tracking server.
Use when building or changing features, preprocessing, encoders, resampling or train/validation/test splits — keep every fitted transform inside a Pipeline fitted on training folds only, and build time and group features without seeing the future or the same entity twice.
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: