detectkit 0.41.0__tar.gz → 0.43.0__tar.gz

{detectkit-0.41.0/detectkit.egg-info → detectkit-0.43.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: detectkit
-Version: 0.41.0
+Version: 0.43.0
 Summary: Metric monitoring with automatic anomaly detection
 Author: detectkit team
 License: MIT

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/__init__.py

@@ -4,7 +4,7 @@ detectk - Anomaly Detection for Time-Series Metrics
 A Python library for data analysts and engineers to monitor metrics with automatic anomaly detection.
 """
 
-__version__ = "0.41.0"
+__version__ = "0.43.0"
 
 from detectkit.core.interval import Interval
 from detectkit.core.models import ColumnDefinition, TableModel

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/autotune/__init__.py

@@ -15,7 +15,6 @@ from detectkit.autotune._base import AutoTuneError, _AutoTuneBase
 from detectkit.autotune._types import ScoringMetric, TuneMode
 from detectkit.autotune.autotuner import AutoTuner, run_autotune_engine
 from detectkit.autotune.config_emitter import compute_run_id, emit_tuned_config
-from detectkit.autotune.html_labeler import render_labeler_html
 from detectkit.autotune.labels import (
     GroundTruth,
     IncidentLabels,
@@ -39,6 +38,5 @@ __all__ = [
     "emit_tuned_config",
     "parse_incident_labels",
     "parse_labels_file",
-    "render_labeler_html",
     "run_autotune_engine",
 ]

detectkit-0.43.0/detectkit/autotune/runner.py

@@ -0,0 +1,102 @@
+"""Shared autotune entry point reused by ``dtk autotune`` and ``dtk tune``.
+
+The pure ``run_autotune_engine`` operates on an in-memory ``data`` dict, a
+``GroundTruth`` and a ``TuneSettings``. Both callers need the same plumbing to
+get there from a metric's ``AutoTuneConfig`` + labels: resolve the scoring
+metric, cap the training history, build the settings, project the labels onto
+the grid, and run the engine. That plumbing used to live privately in
+``cli/commands/autotune.py``; it lives here so the ``dtk tune`` server can reuse
+it verbatim for its server-side **Autotune** mode (no browser port of the
+scoring/CV/seasonality search). Neither this module nor the engine touches the
+database or the filesystem — the caller loads the datapoints and decides what to
+persist.
+"""
+
+from __future__ import annotations
+
+from collections.abc import Callable
+
+import numpy as np
+
+from detectkit.autotune._types import ScoringMetric
+from detectkit.autotune.autotuner import run_autotune_engine
+from detectkit.autotune.labels import IncidentLabels
+from detectkit.autotune.result import AutoTuneResult
+from detectkit.autotune.settings import TuneSettings
+from detectkit.config.metric_config import AutoTuneConfig
+
+# Cap the scored training span when the user doesn't pin max_history, so tuning
+# stays responsive on very long histories (recent data is the most relevant).
+DEFAULT_TRAIN_CAP = 50_000
+
+
+def resolve_scoring(scoring_override: str | None, autotune_cfg: AutoTuneConfig) -> ScoringMetric:
+    """Resolve the scoring metric: CLI override > config > MCC default.
+
+    Raises ``ValueError`` on an unknown name (callers translate as they see fit).
+    """
+    value = scoring_override or autotune_cfg.scoring_metric or ScoringMetric.MCC.value
+    try:
+        return ScoringMetric(value)
+    except ValueError as exc:
+        allowed = ", ".join(m.value for m in ScoringMetric)
+        raise ValueError(f"Invalid scoring metric '{value}'. Allowed: {allowed}") from exc
+
+
+def build_settings(*, scoring: ScoringMetric, autotune_cfg: AutoTuneConfig) -> TuneSettings:
+    """Map an ``AutoTuneConfig`` block (+ resolved scoring) to ``TuneSettings``."""
+    return TuneSettings(
+        metric=scoring,
+        beta=autotune_cfg.beta,
+        fold_count=autotune_cfg.folds,
+        stability_lambda=autotune_cfg.stability_lambda,
+        allowed_detector_types=autotune_cfg.detector_types,
+        allowed_seasonality=autotune_cfg.seasonality_candidates,
+        force_seasonality=autotune_cfg.force_seasonality,
+        fixed_params=dict(autotune_cfg.fixed_params),
+        max_history=autotune_cfg.max_history,
+    )
+
+
+def cap_history(data: dict[str, np.ndarray], max_history: int | None) -> dict[str, np.ndarray]:
+    """Keep the most recent ``max_history`` (or the default cap) points."""
+    n = len(data["timestamp"])
+    cap = max_history if max_history is not None else DEFAULT_TRAIN_CAP
+    if n <= cap:
+        return data
+    return {
+        "timestamp": data["timestamp"][-cap:],
+        "value": data["value"][-cap:],
+        "seasonality_data": data["seasonality_data"][-cap:],
+        "seasonality_columns": data["seasonality_columns"],
+    }
+
+
+def autotune_from_data(
+    *,
+    metric_name: str,
+    data: dict[str, np.ndarray],
+    labels: IncidentLabels,
+    interval_seconds: int,
+    autotune_cfg: AutoTuneConfig,
+    scoring_override: str | None = None,
+    on_stage: Callable[[str, str], None] | None = None,
+) -> AutoTuneResult:
+    """Run the full autotune engine on an in-memory series + labels.
+
+    Caps the history, resolves the scoring metric, projects ``labels`` onto the
+    (capped) grid as ground truth, builds the settings and runs the engine.
+    Pure: no DB, no filesystem, no lock — the caller decides what to persist.
+    """
+    data = cap_history(data, autotune_cfg.max_history)
+    scoring = resolve_scoring(scoring_override, autotune_cfg)
+    ground_truth = labels.to_ground_truth(data["timestamp"], interval_seconds)
+    settings = build_settings(scoring=scoring, autotune_cfg=autotune_cfg)
+    return run_autotune_engine(
+        metric_name=metric_name,
+        data=data,
+        ground_truth=ground_truth,
+        interval_seconds=interval_seconds,
+        settings=settings,
+        on_stage=on_stage,
+    )

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/cli/assets/claude/CLAUDE.section.md

@@ -17,10 +17,12 @@ run. But you assist far better with **read access to the same database** (e.g. a
 database MCP for the project's ClickHouse / PostgreSQL / MySQL): you can inspect
 a metric's series, find real incidents to label for `dtk autotune`, sanity-check
 a metric query before running it, and confirm detections — instead of asking the
-user to run every query by hand. Without it, fall back to
-`dtk autotune --select <metric> --label` (a visual labeler) and to asking the
-user. This access is optional and separate from the `profiles.yml` connection
-detectkit uses for the pipeline.
+user to run every query by hand. Without it, fall back to marking incidents
+visually in `dtk tune --select <metric>` (**Label** mode to drag spans / Threshold
+capture / Lasso the anomaly cloud, or **Review** mode to confirm fired alerts as
+incidents), then **Save incidents** — which `dtk autotune` auto-discovers in
+`incidents/<metric>/` — and to asking the user. This access is optional and
+separate from the `profiles.yml` connection detectkit uses for the pipeline.
 
 ### Where to look (read the matching file before answering)
 
@@ -52,7 +54,9 @@ version — **read the relevant one on demand** instead of guessing:
   `dtk autotune`, and explains the chosen, annotated config (an automatic,
   cross-validated search). For **hands-on** tuning instead, `dtk tune` opens a
   browser view where you drag the detector's knobs against the real series and
-  write the result back in place (see `cli.md`).
+  write the result back in place — and its **Autotune** mode can run that same
+  search server-side and re-seed the knobs without leaving the cockpit (see
+  `cli.md`).
 - **Hit a detectkit bug, or have feedback** — once you've ruled out a local
   config fix (see the gotchas below), use the **`dtk-feedback`** skill to file a
   redacted bug report, feature request, or comment as a GitHub issue on the

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/cli/assets/claude/rules/autotune.md

@@ -17,6 +17,14 @@ same windowed detectors and `detector_id` identity). The fastest path is the
 > `metrics/.history/<metric>/` first). Use `autotune` to search automatically and
 > emit a new file; use `tune` to dial a detector in by eye and commit it. See
 > `cli.md`.
+>
+> **You can also run this engine *inside* `dtk tune`** — its **Autotune** mode runs
+> the same search **server-side** (using the incidents you've marked as ground
+> truth), re-seeds the knobs with the winner, and lets you **Apply** in place. That's
+> the same computation as this command; the difference is it edits the metric YAML in
+> place (advisory — no run record / `__tuned_<id>.yml` / persisted detections) rather
+> than emitting a new tuned file. Reach for `dtk autotune` when you want the audited
+> run + tuned file + persisted winner detections.
 
 ## What it searches
 
@@ -64,28 +72,24 @@ ratios to choose.
 ## Command
 
 ```bash
-dtk autotune --select <sel> [--incidents FILE] [--label] [--scoring METRIC] \
+dtk autotune --select <sel> [--incidents FILE] [--scoring METRIC] \
              [--from DATE] [--to DATE] [--profile NAME] [--force] [--dry-run] [--report]
 ```
 
 - `--incidents FILE|DIR` — a labels file (below) → **supervised** tuning. May be a
   **directory** (e.g. `incidents/<name>/`): interactive runs prompt to pick a
-  version (default newest), non-interactive use the newest. With nothing given, an
+  version (default newest), non-interactive use the newest. **Omit it and `dtk
+  autotune` auto-discovers the newest labels in `incidents/<metric>/`** (the store
+  `dtk tune`'s **Save incidents** writes) — so after labeling in `dtk tune` you run
+  `dtk autotune --select <metric>` with no flag. With no labels anywhere, an
   interactive terminal prompts to enter incidents inline; declining (or running
   non-interactively) tunes **unsupervised**.
-- `--label` — open the interactive labeler (zoom/pan, edit incident edges,
-  per-incident descriptions, named sets). **Default:** a local 127.0.0.1 server +
-  browser; **Save & tune** writes `incidents/<metric>/<metric>[-<set>]-<UTC>.yml`
-  (named after the metric, optional set name as a suffix) and the run
-  **continues into tuning on it**. It **seeds from the metric's newest saved set**
-  (or from `--incidents FILE|DIR` when given), so re-running `--label` continues
-  editing in place. Beyond click-drag marking it offers **Threshold capture**
-  (grab every span above/below a horizontal line in one gesture), **Lasso capture**
-  (loop around a cloud of points; each grid-adjacent run, gaps bridged, becomes one
-  incident span), **on-chart delete** (each band's ✕, or select + Delete key), and
-  **Import file…** (load a labels file you pick). `--no-serve` writes a static
-  `metrics/<name>__labeler.html` (Export downloads the file) and exits; `--no-open`
-  prints the URL instead of launching a browser.
+- **To label incidents**, use `dtk tune --select <metric>`: switch to **Label**
+  mode (drag spans, **Threshold capture** every span past a horizontal line,
+  **Lasso** the anomaly cloud) or **Review** mode (confirm fired alerts as
+  incidents), then **Save incidents**. That writes versioned files into
+  `incidents/<metric>/` — the **same store this command reads** — so the labels feed
+  the next supervised tune with no `--incidents` flag (see `cli.md`).
 - `--scoring` — `mcc` (default), `f1`, `f_beta`, `balanced_accuracy`, `roc_auc`,
   `pr_auc`. MCC uses the whole confusion matrix and suits rare anomalies.
 - `--dry-run` — run the search but persist nothing and write no config.
@@ -115,45 +119,35 @@ incidents:
   - {at: "2026-05-11 09:05:00"}                                  # point
 ```
 
-### Getting labels — offer the interactive labeler first
+### Getting labels — label in `dtk tune` first
 
-When labels would help, **offer the interactive HTML labeler before asking the
+When labels would help, **offer to mark incidents in `dtk tune` before asking the
 user to recall timestamps** — it is the easiest, most reliable path:
 
-1. Run `dtk autotune --select <name> --label`. It starts a local labeler server
-   and opens the browser (use `--no-open` on a remote box and share the printed
-   127.0.0.1 URL; the user port-forwards or runs it locally).
-2. The user marks incidents on the chart (scroll to zoom, drag the navigator to
-   move, click-drag to mark, drag an incident's edges to adjust, add a
-   description, optionally name the set), then clicks **Save & tune**. For many
-   clear outliers, **Threshold capture** grabs every span past a horizontal line
-   at once (above/below, with an optional gap-bridge); it captures within the
-   current view by default, and dragging across the chart limits it to a time
-   window (different boundary per period) — the painted window is **saved with the
-   set and restored on reopen** (a `capture_windows:` block; metadata only). For an
-   irregular cloud, **Lasso capture** loops around the points freehand and turns
-   each grid-adjacent run (small gaps bridged) into one incident span. Each
-   band's ✕ (or select + Delete)
-   removes one, and **focus** on a list row jumps the chart to it.
-3. That writes `incidents/<metric>/<metric>[-<set>]-<UTC>.yml` automatically
-   (named after the metric, optional set name as a suffix; versioned —
-   re-labeling never overwrites) and the **same command continues into the tuning
-   run** on it. No manual file moving.
-4. **Editing over time:** re-running `--label` seeds the page from the metric's
-   newest saved set, so labeling can grow across sessions. To re-tune later on
-   saved sets, point `--incidents` at the folder (`incidents/<name>/`) —
-   interactive runs let the user pick a version, and `--label --incidents <file>`
-   opens that exact set for editing. The static `--no-serve` path still exists
-   (Export downloads a file you move into `incidents/<name>/`; its **Import
-   file…** button loads one back in).
+1. Run `dtk tune --select <name>`. It opens a localhost browser view of the real
+   series (use `--no-open` on a remote box and share the printed 127.0.0.1 URL).
+2. Mark the real incidents one of two ways:
+   - **Label** mode — drag a span over each incident, or **Threshold capture**
+     every span past a horizontal line in one gesture, or **Lasso anomalies** to
+     loop a cloud of anomaly dots into per-streak incident spans.
+   - **Review** mode — the fired alerts lead; click each alert marker to confirm it
+     **valid** (which marks it as a ground-truth incident) or **false alarm**.
+     **Confirm all unreviewed valid** does the lot — a clean metric whose alerts
+     are all good is validated in a few clicks without hand-drawing spans.
+3. Click **Save incidents**. It writes a versioned
+   `incidents/<metric>/<…>.yml` automatically.
+4. Run `dtk autotune --select <name>` with **no `--incidents` flag** — it
+   auto-discovers the newest file in `incidents/<metric>/` and tunes supervised on
+   it. (You can still pass `--incidents <file-or-dir>` to pick a specific set.)
 
 Prefer this whenever the user can *recognise* incidents on a chart but doesn't
 have exact times. If they already know the times (or you found them via a DB
 MCP), write the labels file / inline `incidents:` directly instead. If there are
 no known incidents, run unsupervised — the baseline below is good on its own.
 
-With no labels (no `--incidents`, no config `labels_file`, no interactive
-entry), tuning falls back to an **unsupervised** objective that blends three
+With no labels (no `--incidents`, no config `labels_file`, none auto-discovered
+in `incidents/<metric>/`, no interactive entry), tuning falls back to an
+**unsupervised** objective that blends three
 band-fit / flag-budget terms — `0.4·budget + 0.3·sharpness + 0.3·separation`: a
 smooth one-sided flag-rate budget (no hard cliff), sharpness (a tight,
 well-calibrated confidence interval), and separation (flagged points sitting
@@ -192,8 +186,10 @@ differs from `seasonality_candidates`, which only narrows the *set of columns*
 the search may consider but still runs the search and may choose none.
 
 Label precedence (highest first): `--incidents` flag → `labels_file` → inline
-`incidents` → interactive prompt → none. `labels_file` and `incidents` are
-mutually exclusive. `--scoring` likewise overrides `scoring_metric`.
+`incidents` → auto-discovered `incidents/<metric>/` (the newest file, e.g. from
+`dtk tune`'s **Save incidents**) → interactive prompt → none (unsupervised).
+`labels_file` and `incidents` are mutually exclusive. `--scoring` likewise
+overrides `scoring_metric`.
 
 ## The annotated config
 

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/cli/assets/claude/rules/cli.md

@@ -67,8 +67,11 @@ Automatically chooses a metric's seasonality, detector type, hyperparameters and
 history window, then writes an annotated `metrics/<name>__tuned_<id>.yml`. Reads
 the metric's loaded datapoints (run `dtk run --steps load` first if empty), never
 edits the original, never alerts. `--incidents FILE` enables supervised tuning
-against labeled incidents; without it, an unsupervised objective is used.
-`--dry-run` searches without writing. `--report [PATH]` writes the same
+against labeled incidents; omit it and autotune **auto-discovers** the newest
+labels in `incidents/<metric>/` (the store `dtk tune`'s **Save incidents** writes
+— label there in Label/Review mode, then just run `dtk autotune`); with no labels
+anywhere, an unsupervised objective is used. `--dry-run` searches without writing.
+`--report [PATH]` writes the same
 self-contained HTML report as `dtk run` for the tuned winner (default
 `reports/<metric>__tuned_<id>.html`; `<dir>` or a `.html` file also accepted).
 Full reference: `autotune.md`.
@@ -85,7 +88,8 @@ cockpit**: ONE chart (the windshield) fills the view, the live metrics ride
 **pinned in a HUD over the chart** (the speedometer), and every control lives in an
 **always-visible, mode-aware side rail** beside the chart (Tune shows the detector
 knobs + effective config + Apply, Review the verdict actions, Label the capture
-tools + incident list + Save), while the controls that aren't detector-specific —
+tools + incident list + Save, Autotune the search button + winning config), while
+the controls that aren't detector-specific —
 the **Points shown** data window, the alert rule (**direction** + **consecutive
 anomalies**) and the **y = 0** toggle — stay visible in every mode. The chart is
 **zoomable** (scroll/drag + navigator strip) with a **"Points shown"** trim slider.
@@ -100,11 +104,20 @@ and which interactions are armed on the one chart: **Tune** (band leads; inciden
 recede to read-only context; hover a point for its window), **Review** (the fired
 alerts lead, band ghosts — click an alert marker to cycle its verdict un-reviewed →
 **valid** (green) → **false alarm** (slate); **Confirm all unreviewed valid** does
-the lot), and **Label** (band hides; **mark the real incidents** by drag, **Lasso
+the lot), **Label** (band hides; **mark the real incidents** by drag, **Lasso
 anomalies** — loop a cloud of anomaly dots, each consecutive run, gaps bridged up to
 `consecutive_anomalies`, becomes one span — or **Threshold capture** every span past
 a horizontal line, each widened to a full interval so the alert lands inside; the
-painted window saves as `capture_windows`). **Confirming an alert valid IS marking an
+painted window saves as `capture_windows`), and **Autotune** (**Run autotune**
+launches the **real** `dtk autotune` engine **server-side** over the metric's full
+history, using your marked incidents as ground truth, then **re-seeds every knob**
+with the winner and shows the score + decision log; the band leads like Tune). The
+Autotune mode is **advisory** — it computes + re-seeds only and persists nothing (no
+run record / `__tuned_<id>.yml` / detections, so `dtk tune` stays lock-free); review
+the band and **Apply** to write it back. It honours the metric's `autotune:` block,
+is supervised when incidents are marked (also picks `consecutive_anomalies`) else
+unsupervised, and needs the live server (unavailable under `--no-serve`).
+**Confirming an alert valid IS marking an
 incident**: the confirmed streak becomes a first-class **ground-truth incident** that
 shows in the Marked-incidents list (a read-only "✓ confirmed alert" row; its ✕
 un-confirms the alert), counts toward recall + correct, and is written on Save — so a

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/cli/assets/claude/skills/dtk-autotune/SKILL.md

@@ -79,44 +79,39 @@ generalize is rejected.
 Labels turn tuning from a good unsupervised default into a config optimised
 against *your* real incidents (it then optimises MCC and also tunes the alert
 window `consecutive_anomalies`). **The easiest, most reliable way to produce them
-is the interactive HTML labeler — offer this first**, before asking the user to
+is to mark incidents in `dtk tune` — offer this first**, before asking the user to
 recall timestamps:
 
 ```bash
-dtk autotune --select <name> --label
+dtk tune --select <name>
 ```
 
-By default this starts a **local labeler server** (127.0.0.1) and opens the
-browser; on a remote machine add `--no-open` and share the printed URL. Walk the
-user through it:
+This opens a localhost browser view of the metric's **real** series; on a remote
+machine add `--no-open` and share the printed URL. Walk the user through it:
 
 1. Navigate a long/dense series: **scroll to zoom**, double-click to reset, drag
-   the **navigator strip** to move the view (window = pan, edges = stretch).
-2. **Click-drag across the chart** to mark each incident (red band + a row below
-   with an optional **description**). Adjust one by dragging its **edges**, or its
-   **middle** to move it; optionally **name the set**. Remove one by clicking its
-   **✕** on the chart (or selecting it and pressing **Delete**) — no hunting in
-   the list; **focus** on a list row jumps the chart to that incident; *Clear all*
-   resets.
-3. When many outliers are obvious, use **Threshold capture**: set a horizontal
-   line (hover the chart or type a value), pick **above/below**, optionally bridge
-   small gaps, and **Add N spans** marks them all at once — then tidy with the ✕.
-   It captures within the current view by default; **drag across the chart** to
-   limit it to a time window (so a metric that behaves differently across periods
-   can take a different boundary in each). **↺ whole view** clears the window.
-4. Click **Save & tune**. The server writes `incidents/<metric>/<metric>[-<set>]-<UTC>.yml`
-   automatically (named after the metric, with the optional set name as a suffix;
-   versioned — re-labeling never overwrites) and the **same command
-   continues into the tuning run on it**. No manual file moving.
-
-**Editing an existing set:** re-running `--label` **seeds the page from the
-metric's newest saved set** (or from `--label --incidents <file-or-dir>`), so
-labeling can grow across sessions — mark a few more, save a new version. (`--no-serve`
-is the offline fallback: it writes a static `metrics/<name>__labeler.html` whose
-Export downloads a versioned file you then move into `incidents/<name>/` and pass
-via `--incidents`; its **Import file…** button loads a saved set back in.) To
-re-tune later on a saved set, point `--incidents` at `incidents/<name>/`
-(interactive runs let the user pick a version).
+   the **navigator strip** to move the view.
+2. Mark the real incidents in one of two modes:
+   - **Label** mode — **drag a span** over each incident (edges to resize, middle
+     to move, ✕/Delete to remove). When many outliers are obvious, **Threshold
+     capture** grabs every span past a horizontal line in one gesture (set the
+     line, pick the side, optionally bridge gaps); **Lasso anomalies** loops a
+     freeform cloud of anomaly dots into one incident span per grid-adjacent run.
+   - **Review** mode — the fired alerts lead; **click each alert marker** to cycle
+     its verdict un-reviewed → **valid** (green) → **false alarm** (slate).
+     **Confirming an alert valid marks it as a ground-truth incident**, and
+     **Confirm all unreviewed valid** does the lot — so a clean metric whose alerts
+     are all good is validated in a few clicks without hand-drawing spans.
+3. Click **Save incidents**. It writes `incidents/<metric>/<…>.yml` automatically
+   (versioned — saving never overwrites). Saving doesn't end the session, so you
+   can keep tuning; you can also click **Apply** to write the detector config back.
+
+**Then run autotune with no `--incidents` flag** — `dtk autotune --select <name>`
+**auto-discovers the newest file in `incidents/<metric>/`** (the same store
+`dtk tune` saves to) and tunes supervised on it. To re-tune on a specific set,
+pass `--incidents <file-or-dir>` (point it at `incidents/<name>/` and interactive
+runs let the user pick a version). Labeling grows across sessions — reopen
+`dtk tune`, mark a few more, **Save incidents** again, re-run autotune.
 
 Prefer this whenever the user can *recognise* incidents on a chart but doesn't
 have exact timestamps — it is far easier than dictating times, and they label
@@ -158,10 +153,14 @@ is good on its own; it just can't learn *which* spikes you specifically care abo
 ## Step 3 — Run autotune
 
 ```bash
-# Supervised (recommended when you have incidents):
+# Supervised — labeled in `dtk tune`: just run it, autotune auto-discovers
+# the newest file in incidents/<name>/ (no --incidents flag needed):
+dtk autotune --select <name>
+
+# Supervised — point at a specific labels file or set explicitly:
 dtk autotune --select <name> --incidents incidents/<name>.yml
 
-# Unsupervised (no labels — tunes on data statistics):
+# Unsupervised (no labels anywhere — tunes on data statistics):
 dtk autotune --select <name>
 ```
 

{detectkit-0.41.0 → detectkit-0.43.0}/detectkit/cli/assets/claude/skills/dtk-setup-project/SKILL.md

@@ -45,7 +45,8 @@ side by side, ask which one to set up.
 > a database MCP): you can inspect metric series, find incidents to label for
 > `dtk autotune`, sanity-check queries, and confirm detections yourself. Suggest
 > the user connect one if they haven't; if they can't, you can still do
-> everything by asking them to run queries and by using `dtk autotune --label`.
+> everything by asking them to run queries and by marking incidents visually in
+> `dtk tune` (Label/Review modes), which `dtk autotune` auto-discovers.
 
 ## Step 1 — Pick the database backend