smoke-test-ml-pipeline

ML パイプラインのスモークテスト

イテレーション時に「読み込み → 特徴量化 → 分割」という アンチパターンを検出し、本番環境に到達する前に捕捉する最小限の pytest です。

まず成果物を提示します。 事前チェックリストの後、ユーザーに最初に表示する内容は、フェンス付きブロック内の完全なテストファイルです （assert len(predictions) == n_predict_grid_rows、事前履歴バッファーのない predict 環境、実際の data/ ソース、CV 平均をリテラルとしてハードコードしたソフトアサーション、skore のインポートなし）。 その後、実行します。python -m skore_skills smoke run --stem <NN>_<short_name>。JSON の action を正とします。計画を示しただけで止めたり、 ファイルを思考チャンネル内だけに残したりしないでください。後で pytest を実行するようユーザーや CI に伝えてはいけません。該当する smoke run コマンドを明記してください。ツールを使えないハーネスでも、完全なテストファイル（想定したジャーナル／実験／パッケージの情報を使い、<FILL_…> は使わない）と、そのコマンド呼び出しを提示してください。このターンでは pytest を実行できないと伝えるのは問題ありませんが、ユーザーに実行を指示してはいけません。ここで evaluate の AskUserQuestion をしてはいけません。このゲートは、smoke run が proceed になった後の build-ml-pipeline に属します。成功後のユーザー向けの締めくくり（説明とリンク）は親が担当します。このスキルではパイプラインについて説明しません。

停止条件 — 何よりも先に読んでください

• セットアップがまだ完了していません。 まず python -m skore_skills status を実行します。 status.setup.pending が空でなく、 status.skills.setup-ml-project が true の場合は、setup-ml-project を読み込んで 停止します。このスキルは開始しません。処理が戻ったら続行します。このターンでは再度読み込みません。 そのスキルがインストールされていない場合は、保留中の項目を1行で示して 停止します。git init、スキャフォールド、env init をでっち上げてはいけません。 status.setup.env または status.setup.workspace が declined の場合は、1行で停止します。git または editable が declined の場合は再度尋ねず、続行します。
• 承認済みの設計メモとスクリプトなしでスモークテストを実行してはいけません。 ペアリングの ルールは厳守します。python -m skore_skills design consent --stem <stem> を 実行します。 tests/smoke/test_NN_<short_name>.py が存在するのは、その JSON が proceed であり、 かつ、対応するステムの experiments/NN_<short_name>.py が存在する 場合に限ります。 ask / stop の場合は、スモークテストを書いてはいけません。
• pytest がありません。 プロジェクト環境で pytest をインポートできない場合は、停止します。 add-python-package を読み込み、pytest を default に追加します （確認してください。env route は pytest を --feature agent ではなく default に割り当てます）。 pip install pytest を実行したり、agent feature に追加したりしてはいけません （合成された dev 環境、つまり default + agent を使います）。
• 記憶からシンボルを補ってはいけません。 スモークテストに記述する skrub / scikit-learn の名前はすべて、python -m skore_skills api get <dotted>... または、このターン中に 対応するキャッシュを読み取って取得します。複数のシンボルは1回の呼び出しで指定します。スモークテストは小さなファイルですが、予測パッケージの API サーフェスをインポートします。同じ「記憶から補わない」ルールが適用されます。
• アサーションを弱めてはいけません。 厳密なアサーションは行数の完全一致です。「およそ一致」でも、「期待される行数の80%以上」でもありません。行数の不一致こそ、スモークテストが検出するためにある失敗モードです。アサーションを緩めると、バグがひそかに再発します。
• 期待される件数も減らしてはいけません。 アサーションは一組です。== と、その右辺の数値の両方が対象です。n_predict_grid_rows をパイプラインが出力した値まで下げて再定義すること（「予測グリッドからエンバーゴ分を差し引く」「コールドスタート期間を差し引く」など）は、等号を残したまま同じ欠陥を持ち込むことになります。この差が意図されたものだと考える場合は、build-ml-pipeline に X マーカーの質問として伝え、停止します。数値を提案してはいけません。
• 婉曲表現は、禁止された内容を許可するものではありません。 条件付きの提案も提案です。「24行が文書化されたエンバーゴだと判明した場合、適切な変更は……」は、禁止された編集を提案しています。拒否する場合は、拒否の説明と差し戻し先だけで終えます。同じ結論に至る但し書きを付けてはいけません。
• フィクスチャを合成してはいけません。 スモークテストでは、実際の data/ ソースを読み取ります。合成フィクスチャは一見問題なく見えても、本番環境で実際に壊れるローダーを通りません。
• ラッパー、NaN 処理、eval_mode の小細工は禁止です。 予測器をラップしたり、 eval_mode に応じた条件分岐を入れたりして初めてスモークテストが通るなら、 パイプラインに問題があります。build に戻り（§ build に戻る）、X マーカーの配置を修正します。 ラッパーは失敗モードを覆い隠すだけで、解決しません。
• スモークテストでは、予測パッケージの API だけを使います。 build-ml-pipeline が生成した SkrubLearner の場合、skrub の fit / predict / （任意で）score と、 ソフトアサーションで使うメトリクスの sklearn.metrics だけを使用します。 テストファイルで skore（またはその他のトラッキング／レポート用ライブラリ）をインポートしてはいけません。スモークテストは skrub + sklearn をインポートできる環境ならどこでも実行可能でなければなりません。skore Project は副次的な成果物であり、テストの依存関係ではありません。 ソフトアサーションのベースライン（CV 平均 MAE など）は、設計メモの Status.headline からハードコードし、設計メモを示すコメントを付けます。実験の headline の数値が変わったら、手動で更新します。
• 警告をフィルターしてはいけません。 ユーザーが明示的に求めた場合を除き、 @pytest.mark.filterwarnings(...)、テスト本体での warnings.filterwarnings(...)、 pytest.ini / pyproject.toml での filterwarnings = [...] は使用してはいけません。 python -m skore_skills style の § 停止条件を参照してください。

実行前

設計／スクリプトの対応付けと pytest の利用可否を確認したら、テストファイルを書き込む前に、自然な文で1～3文を出力します。これはローカルの実データを使ったスモーク計算であり、宣言された学習器を実データの小さなスライスで学習し、履歴の事前バッファーなしで互いに重複しないスライスを予測して、出力行数が正確であることと、任意のソフト指標を確認する、と伝えます。tests/smoke/test_<stem>.py と、正確な smoke run コマンドを明記します。

このスライスは完全なデータセットの交差検証より意図的に大幅に小さくしていますが、実行時間はローダー、特徴量グラフ、学習器に依存することを説明します。計測済みの時間がすでにわかっている場合を除き、数分で終わるとは約束しません。また、見積もり時間を短くするために、実データを合成行に置き換えてはいけません。このプレビューは1回だけ出力し、pytest のアクションごとには出力しません。必須ゲートが保留中の場合は、テストの可能性をプレビューしますが、テストの作成や実行は行いません。このスキルでは、LLM の調査も完全な評価も行いません。

事前確認 — テストコードの前に、このチェックリストをテキストで表示してください

Pre-flight (smoke-test-ml-pipeline):
- [ ] Tier 1 mandatory libs importable: pytest + sklearn + skrub
      (stage libraries per `python -m skore_skills env stack`). **Not skore** —
      see the Stop conditions; the smoke test is intentionally
      portable to any skrub-capable environment
- [ ] API confirmed for skrub / sklearn symbols used in
      the test: <symbols, or "none">
      Evidence: python -m skore_skills api get <dotted>...
                | Read scratch/api/<lib>/<version>/<topic>.md (this turn)
                | Write scratch/api/<lib>/<version>/<topic>.md (this turn)
                | "n/a — test only uses symbols already present in
                  src/<pkg>/ (build_learner / load_training_table / etc.)"
- [ ] `journal/NN_<short_name>.md` read this turn (frozen sections:
      Question, Method) so the test asserts what the experiment claims
- [ ] `experiments/NN_<short_name>.py` skimmed this turn for the env-dict
      keys `build_learner` consumes (`data_dir` / `start` + `end` /
      `raw_frame` / etc.)
- [ ] `src/<pkg>/data.py` skimmed this turn for the loader signature
      (so the predict-env construction matches the loader's expectations)
- [ ] Test category & stem decided: `tests/smoke/test_NN_<short_name>.py`
- [ ] Predict-grid size decided: smallest window that still triggers
      the failure mode (default: a single horizon-length slice; for
      time series, the most recent N steps such that the target is
      *just* observable for assertion)
- [ ] Hard assertion wired: `len(predictions) == n_predict_grid_rows`,
      plus output width (1 for one target; `translation.targets`
      for multi-output regression, including column names)
- [ ] Soft assertion wired (or explicitly skipped): smoke MAE within
      `3 × CV_MEAN_HARDCODED_FROM_PLAN` (or task-appropriate
      analogue). Value is a literal pulled from the matching
      `journal/NN_<short_name>.md` § Status.headline; the test does
      not import `skore` / read the project store at runtime.
- [ ] Pytest run this turn on `tests/smoke/test_NN_<short_name>.py`.
      Red → back to build (§ Back to build). Green (sub-step) →
      return to build for the design HITL.

スモークテストでアサートする内容

2つのアサーションと、2つの重要度があります。

ハード — 行数チェック

assert len(predictions) == n_predict_grid_rows

これは構造的な正しさを確認するアサーションです。合否が明確に決まり、スモークテストの主目的そのものです。正しく構築されたパイプライン（build-ml-pipeline の X マーカー規則に従ったもの）なら、これは自明に満たされます。一方、読み込み後に特徴量を生成し、それから分割するパイプラインでは失敗します。予測時の特徴量生成が、履歴の事前バッファーなしで予測環境上で実行され、コールドスタートの行がひそかに削除されるためです。

n_predict_grid_rows は、予測環境が予測を要求していると主張する行数です。通常は、予測時のグリッド内のターゲット時刻行の数です。パイプラインのソースバインディングが未加工ファイルのディレクトリの場合は、予測時に予測環境から導出される教師ありフレームの行数です（build_supervised_frame(predict_dir) で利用できます）。

len は行数を数えます。また、出力の幅もアサートします。ターゲットが1つなら幅は1です。多出力回帰の場合は、幅に加えて、predict が DataFrame を返す場合は列名も translation.targets と一致する必要があります。行数が正しくても出力が間違っている行列は、形状の失敗です。

ソフト — 指標と交差検証の差

smoke_mae = mean_absolute_error(y_true, predictions)
assert smoke_mae < 3 * cv_mae_mean, (
    f"smoke MAE {smoke_mae:.0f} is more than 3× the CV mean "
    f"({cv_mae_mean:.0f}); predictions may be NaN-poisoned even "
    f"though the count matches."
)

指標の差は、二次的な失敗モードを検出します。予測数は正しくても、予測時に一部の特徴量が NaN となり、値が無意味になっているケースです（たとえば、エンコーダーが新しいカテゴリを見ていない、上流の履歴参照が正しく設定されていないためラグが null になっているなど）。3× の上限は最初の目安です。タスクに応じて調整してください。スモークウィンドウは1つの季節スライスなので、正当な厳しい季節のウィンドウで誤検出しないよう、上限には十分な余裕を持たせる必要があります。

ソフトアサーションはオプトインではなく、オプトアウトです。タスクに明確な指標と交差検証の比較対象がない場合（たとえば、スモーク用フィクスチャに意図的に正解データがない場合）に限り、スキップしてください。スキップする場合は、その理由をテストファイルにコメントとして残してください。

診断可能性が構築段階で保証される特性

このフィクスチャは、不具合のある構成では失敗し、正しい構成では成功するように特別に作られています。これはスモークテストにとって最も重要な特性です。フィクスチャ構築の近道を使った結果、この特性が満たされない場合、テストには意味がありません。

具体的には、予測時の env-dict には、予測対象の行だけが含まれ、予測時点で既知の特徴量に絶対必要な分を超える事前履歴バッファはありません。このため、次の2つの結果が生じます。

• mark_as_X が遅いパイプライン：特徴量は予測 env のデータだけを使い、グラフ内で計算されます。バックワードラグ／ローリングウィンドウ／ターゲットシフトでは、コールドスタートの行に NaN が入ります。マーカー前の drop_nulls（またはモデルが NaN を許容しないこと）により、それらの行は除外されます。len(predictions) < n_predict_grid_rows。テストは失敗します。
• mark_as_X が早いパイプライン：マーカーは予測グリッドノードに配置されます（build-ml-pipeline のルール2のレイヤー2）。履歴に依存する特徴量は、上流の履歴 DataOp を追加の apply_func 引数として受け取ります。予測時に、履歴ノードは利用可能な全履歴（トレーニング env が使うものと同じソースからバインドされたもの）を解決し、各特徴量ステップでの結合によって、予測グリッドのすべての行に実際の値が生成されます。len(predictions) == n_predict_grid_rows。テストは成功します。

2つの結果は決定的です。スモークテストが「不安定」になることはありません。行数が1つでもずれていれば、パイプラインに誤りがあります。

予測グリッドのサイズについては、小さいほど適切です。予測時点のグリッドとして妥当な範囲で、最小の予測ウィンドウを使ってください。予測ホライズンと同じ長さのスライス1つ（例：t+24 モデルなら1日）で失敗を明らかにできます。それより大きくしても、件数に紛れて問題が隠れるだけです。

フィクスチャの構築 — data/ がソースです

フィクスチャは、合成ジェネレーターやチェックイン済みのフィクスチャファイルではなく、実際の data/ ソースから読み込みます。実験で使用するローダーを、スモークテストでも必ず実行してください。合成フィクスチャでは目的を達成できません。

構築方法は実験のソースバインディングによって異なります（build_learner がどの環境辞書のキーを使用するか、experiments/NN_*.py を読んで確認してください）が、形は常に同じです。

1. 予測グリッドの時間範囲（predict_start、predict_end）を特定します。時系列の場合は、データのうち予測ホライズンと同じ長さの最新のウィンドウを使用します。
2. 学習用環境を特定します。最も明確な方法は、predict_start - HORIZON より厳密に前の全データを使用することです（予測ホライズンと同じ長さのエンバーゴ）。表形式の IID の場合は、予測グリッド内の行を除外するだけです。
3. 2 つの環境辞書を構築します。
   • train_env：実験でフィットバインディングに使用する形で、エンバーゴより前のデータに限定したものです。
   • predict_env：追加の履歴パディングを含まない予測グリッドの記述です（これが診断のポイントです）。パディングを追加すると、テストが誤って成功します。
4. 予測とは独立して n_predict_grid_rows を計算します。行数は予測そのものではなく、予測環境の教師あり表現から取得します。
5. 予測環境の教師あり表現から y_true を計算します（ソフトアサーションの正解データです）。

フィクスチャは、data/holdout/、data/train/ などに派生ファイルを書き込んではいけません。これらはプロジェクトのセットアップスクリプトが管理する、ワークスペースレベルの成果物です。スモークテストのフィクスチャは一時的なものです。実験のソースバインディングでディスク上の入力が必要な場合は、tmp_path（pytest 組み込みの一時ディレクトリフィクスチャ）を使用してください。

よくあるソースバインディングの形は 3 つあります。スモークテストのフィクスチャは、実験で使われている形に合わせる必要があります。

バインディングの形	予測環境の構築	n_predict_grid_rows
生ファイルのディレクトリ — build_learner が data_dir 形式の変数をバインドし、ローダーがそこからファイルをグロブ検索／読み込みします。	テスト内で、時系列スライス済みの生ファイルを含む小さな一時ディレクトリを作成します（pytest 組み込みの tmp_path を使用）。これを data_dir としてバインドします。	予測環境の教師あり表現の行数です（例：load-forecasting の len(build_supervised_frame(predict_dir))）。スライスから事前に把握できます。
予測グリッド＋生の履歴ソース — build-ml-pipeline のルール 2 にある early-mark 形式で、predict_grid と history_source／weather_source などを別々の変数として使用します。	インメモリの predict_grid 値（タイムスタンプのリスト、パネルキーのグリッドなど）とソース識別子を構築します。ファイルへの書き込みは不要です。	len(predict_grid) です。
実体化された (X, y) の IID — build_learner が X と y を直接バインドするか、{"X": ..., "y": ...} にマッピングする単一の data 環境辞書をバインドします。	フィットの前に、実体化された X から少数の行を取り分け、それに対応する y も保持します。残りを train_env に、取り分けた部分を predict_env に設定します。	len(predict_subset) です。

2 つ目の形（予測グリッド＋生の履歴ソース）については、3 つのレイヤー（ソース → 予測グリッド＋アラインメント＋mark_as_X → 履歴を上流の参照として持つ後続の特徴量）が、build-ml-pipeline のルール 2 で説明されています。コード例は build-ml-pipeline/references/layer_examples.md にあります。early-mark パイプラインの予測環境を構築する前に、そのリファレンスを読んでください。

IID フラットテーブルの問題 — スモークテストで今も確認できること

行間の依存関係がないパイプライン（行ごとの計算、学習時に学習して予測時に各行に適用するステートフルなエンコーダー、ラグ／ローリング／履歴との結合がない場合）では、スモークテストは「学習用サブセットで学習し、ホールドアウトサブセットで予測して、len(predictions) == len(predict_subset) をアサートする」だけになります。

構造上の診断特性は適用されません。テストで破れる行間の参照がないため、正しく構築されたパイプラインでもバグのあるパイプラインでも、ハードアサーションは通過します。IID の場合でも、スモークテストで検出できるものは次のとおりです。

• CV で使った入力より小さい入力で行を削除または重複させるローダーのバグ。
• learner.predict(env) の出力と predict 環境の行数との形状の不一致。DataFrame に対する len は行数を返すため、出力の幅も確認してください。ターゲットが 1 つの場合、幅は 1 です。複数出力回帰では、幅と列名が translation.targets に一致する必要があります。
• エンコーダーが predict サブセットに含まれるカテゴリを一度も見たことがない場合に、誤って NaN で汚染されること（smoke-MAE-vs-CV-mean のソフトアサーションで検出できるため、有効にしておいてください）。

IID のスモークテストは、CV の代替ではなく、健全性チェックとして扱ってください。スモークテストが CV の代替として機能するのは行間パイプラインの場合です。そこでは、構造上の診断特性が重要な保証となります。

標準的な pytest の形式

スモークテストファイルごとにテスト関数を 1 つ用意します。関数名は実験のステムと同じにして、pytest の出力だけで内容がわかるようにします。

"""Smoke test for `experiments/NN_<short_name>.py`."""

# stdlib + numpy first
import pytest

from <pkg> import PROJECT_ROOT
from <pkg>.pipeline import build_learner
# additional imports per the experiment's binding shape

DATA_DIR = PROJECT_ROOT / "data"


@pytest.fixture
def train_predict_envs(tmp_path):
    """Build a (train_env, predict_env, n_predict_grid_rows, y_true) tuple.

    Diagnostic by construction: predict_env carries only the
    rows we want predictions for, with no pre-history padding.
    """
    # ... per-experiment fixture construction ...
    return train_env, predict_env, n_predict_grid_rows, y_true


def test_NN_<short_name>(train_predict_envs):
    """Predict-time replay must produce one prediction per predict-grid row."""
    train_env, predict_env, n_predict_grid_rows, y_true = train_predict_envs

    learner = build_learner()
    learner.fit(train_env)
    predictions = learner.predict(predict_env)

    # HARD: structural correctness. n_outputs is 1 for one target.
    # Multi-output regression sets n_outputs and target_names from
    # translation.targets.
    n_outputs = 1
    target_names: list[str] = []
    assert len(predictions) == n_predict_grid_rows, (
        f"got {len(predictions)} predictions for "
        f"{n_predict_grid_rows} predict-grid rows — pipeline is "
        f"dropping cold-start rows; check `mark_as_X` placement "
        f"and that history-dependent features reference an "
        f"upstream history node, not a per-slice computation."
    )
    width = predictions.shape[1] if getattr(predictions, "ndim", 1) == 2 else 1
    assert width == n_outputs, (
        f"got {width} outputs, expected {n_outputs}"
    )
    if target_names:
        assert list(predictions.columns) == target_names, list(predictions.columns)

    # SOFT: predictions are not NaN-poisoned.
    from sklearn.metrics import mean_absolute_error
    smoke_mae = mean_absolute_error(y_true, predictions)
    # CV_MAE_MEAN is hardcoded at the top of the file from
    # `journal/NN_<short_name>.md` § Status.headline. The smoke test
    # uses only the predicting package's API (skrub/sklearn) —
    # no skore import, so it runs anywhere skrub does.
    assert smoke_mae < 3 * CV_MAE_MEAN, (
        f"smoke MAE {smoke_mae:.0f} > 3 × CV mean "
        f"({CV_MAE_MEAN:.0f}) — predictions may be NaN-poisoned."
    )

tmp_path はテストごとの一時ディレクトリを用意する pytest 組み込み機能です。実験のソースバインディングでディスク上の入力が必要な場合は、必ずこれを使用してください。

失敗時の意味

スモークテストの失敗は、メトリックの問題ではなく、パイプラインの形状の問題です。

• ハードアサーションの失敗（行数）→ パイプラインが壊れています。ビルド（§ ビルドに戻る）に戻り、X マーカーの配置と履歴依存の特徴量ステップを監査してください。モデルのチューニング、アサーションの緩和、ラッパーの追加はしないでください。形状を修正してください。
• ソフトアサーションの失敗（メトリックが大きく外れている）→ 予測値はありますが、スモークウィンドウでの値が使い物になりません。最もよくある原因は、上流の履歴ノードが予測時に正しく解決されず、ラグ列が知らないうちに NaN になることです。learner.skb.full_report() を調べ、予測時の値が学習時に確認した値と一致しないノードを探してください。
• 失敗すると done ステータスにできません。 manage-ml-backlog の record-outcome は、対応するスモークテストが通過するまで、実験を done に変更しません。evaluate-ml-pipeline も、smoke run が stop の間は（または、履歴依存パイプラインでスモークファイルが存在しない場合は）停止します。

ビルドに戻る

パイプラインの修正は build-ml-pipeline で行います。そこに戻る方法は、このスキルを読み込んだ状況によって異なります。

• サブステップ — build-ml-pipeline がこのスキルを読み込んだ場合は、そこに戻ってください。手順は引き続き読み込まれているため、ループを続行します。
• 直接デバッグ — このスキルを単独で読み込んだ場合（たとえば「スモークテストが失敗する理由は？」など）は、status.skills.model-ml-pipeline が true の場合に model-ml-pipeline を読み込み、ステムを指定してください。承認済みの設計を再開し、ビルドで修正を行います。その際は、ビルドで宣言されたモデル階層を使用します。ここから build-ml-pipeline を読み込まないでください。このスキルが読み込むサブステップは、このスキル自体と同じ階層までしか実行できません。model-ml-pipeline がない場合は、パイプラインの修正がビルドで必要であることを一文で伝え、そこで終了してください。

直接デバッグの依頼がスモークテストの失敗理由だけを尋ねている場合は、診断が回答です。ユーザーがパイプラインの修正を希望する場合にのみ、ビルドに戻ってください。

このスキルで行わないこと

• 設計メモや実験スクリプトは作成しません。これらは model-ml-pipeline および setup-workspace / build-ml-pipeline が担当します。
• skore Project には触れません。スモークテストでは project.put を呼び出しません。これはメトリクスの アーティファクトではなく、事前チェックです。CV メトリクスは evaluate-ml-pipeline から取得します。
• 「良いメトリクス」の定義は行いません。ハードアサーションは 構造に関するものです。ソフトアサーションは妥当性の確認範囲であり、 パフォーマンス目標ではありません。結果を評価するのはユーザーです。 これは、ユーザーが結果を判断するという triage-ml-task のルールに従っています。
• 「評価（推奨）／変更／停止」と尋ねることはありません。smoke run の後は、 build-ml-pipeline（親スキル）に戻るか、 直接デバッグの依頼に対して合格／不合格を報告します。

pytest を実行する

これが実行可能な証明です。テストファイルを作成または 更新した後、python -m skore_skills smoke run --stem <NN>_<short_name> を実行します。tests/smoke/test_NN_<short_name>.py で pytest を実行し、その後 JSON を出力します。action: proceed がない限り、 成功したと主張しないでください。stop / red の場合は、 パイプラインを変更するために build に戻り（§ build に戻る）、 evaluate は開始しないでください。proceed の場合、このスキルがサブステップとして 読み込まれていれば、設計の HITL のために build に戻ります。

関連スキル

• build-ml-pipeline — 親スキルです。スモークテストで検証する X-marker の配置 ルールと、合格後の HITL を担当します。スモークテストが失敗した場合は、 パイプラインの形状を修正するためにここへ戻ります。直接デバッグの場合は、 model-ml-pipeline を経由します（§ build に戻る）。 pytest が反復の中心です。smoke run が失敗 → パイプラインを変更 → 再度 smoke run。
• manage-ml-backlog — record-outcome は done を記録します。 実験を done に変更するには、スモークテストに合格する必要があります。
• evaluate-ml-pipeline — CV を担当します。ここから読み込まないでください。
• python -m skore_skills api get — スモークテストで使用する予測パッケージ API の シンボル参照です。テスト本文でインポートする関数を指定する前に 確認してください。 python -m skore_skills api get はスモークテストの依存関係ではありません。 前述の「skore をインポートしない」停止条件を参照してください。キャッシュヒットを優先： WebSearching の前に scratch/api/<lib>/<version>/ を確認し、 新しい調査結果はそこにキャッシュしてください（python -m skore_skills api get の Shape 0/3 に従ってください）。
• python -m skore_skills env stack — このスキルを使用するすべての ワークスペースで、pytest をステージライブラリとして宣言します。
• python -m skore_skills style — tests/smoke/test_NN_*.py を作成または 編集した後に必ず呼び出してください。このスキルを呼び出さずに、 マネージャー固有の ruff チェックを直接実行すると、スタックが想定する NumPyDoc の docstring 規約がひそかに抜け落ちます。ruff の D ルールは1行の要約だけでも通りますが、テストフィクスチャと テスト関数で使うべき、パラメーターの形状を型スロットに記述する方法や セクションの構成（Parameters / Returns / Notes）を教えるのは、 スキル本文だけです。

パッケージが必要ですか？

インポートが見つからない場合、status.skills.add-python-package が true であれば add-python-package を読み込んでください。 env add と未管理パッケージの確認は、そのスキルが担当します。ここでは env add を実行しないでください。 そのスキルがインストールされていない場合は、パッケージ名を示して停止してください。