pp-bambu

Bambu Lab — Printing Press CLI

前提条件：CLI をインストールする

このスキルは bambu-pp-cli バイナリを使用します。**このスキルのコマンドを実行する前に、CLI がインストールされていることを必ず確認してください。**インストールされていない場合は、先にインストールしてください。

1. Printing Press インストーラーを使用してインストールします。バイナリの既定のインストール先は、macOS/Linux では $HOME/.local/bin、Windows では %LOCALAPPDATA%\Programs\PrintingPress\bin です。

   npx -y @mvanhorn/printing-press-library install bambu --cli-only
   

2. 次のコマンドで確認します：bambu-pp-cli --version
3. 報告されたインストール先ディレクトリが、このスキルを実行するエージェント／ランタイムの $PATH に含まれていることを確認します。

npx によるインストールに失敗した場合（Node がない、オフラインなど）は、代わりに Go から直接インストールしてください（Go 1.26.6 以降が必要です）。インストール先は $GOPATH/bin（既定値は $HOME/go/bin）なので、代わりにそのディレクトリを $PATH に追加します。

go install github.com/mvanhorn/printing-press-library/library/devices/bambu/cmd/bambu-pp-cli@latest

インストール後に --version が「command not found」と表示される場合、ランタイムから $PATH 上のバイナリディレクトリが見えていません。確認が成功するまで、スキルのコマンドを実行しないでください。

Bambu のプリント状況を監視し、更新情報を Discord、Webhook、その他の自動化先に投稿するよう、エージェントやコードを設定する場合に使用します。ライブ MQTT ステータス、現在のジョブに正確に対応する 3MF の重量とプレビュー、プロバイダーに依存しない開始／完了イベント、ローカル履歴には通常のローカルアクセスを使用します。Developer Mode、LAN Only Mode、Bambu Cloud、プリンター制御、ファーム管理は意図的にサポート対象外です。

この CLI を使用する場面

エージェントや自動化で、進捗、完了予定時刻、AMS/HMS の状態、正確なプレートメタデータ、モデルのプレビュー、開始／完了ペイロードなど、Bambu のプリントに関する構造化されたローカル情報が必要な場合にこの CLI を使用します。プリンター制御、LAN Only Mode、Developer Mode、カメラウォール、ファーム管理には、Bambuddy またはその他の制御を目的としたプロジェクトを使用してください。

使用しない場面

次の用途にはこの CLI を使用しないでください。

• プリンター制御、プリントの送信、動作、加熱、ファームウェア、カメラ制御、AMS への書き込みには使用しないでください。
• Developer Mode、LAN Only Mode、Bambu Cloud、リモートリレー、ファーム管理のワークフローでは使用しないでください。
• スライス、メッシュ修復、MakerWorld の閲覧、スプール在庫管理には使用しないでください。
• ローカルアクセスコードをフラグ、ログ、成果物、チャットメッセージ、MCP 呼び出しに含めないでください。

独自の機能

これらの機能は、この API の他のツールでは利用できません。

ライブでの判断に役立つ履歴

• job eta — 同じジョブの過去の実行で見られた誤差パターンを使って、プリンターの完了予測を補正します。

  このプリンターで実際に観測された履歴に基づく完了時刻が必要な自動化やユーザーに適しています。

  bambu-pp-cli job eta --agent
  

• history failure-correlations — ジョブの失敗との関連が特に強いプリンター、フィラメント、プレート、ファームウェア、速度、温度の条件を順位付けします。

  1 件のジョブを調べるだけでなく、繰り返し発生する失敗を根拠に基づいて切り分ける場合に適しています。

  bambu-pp-cli history failure-correlations --since 30d --agent
  

• job timeline — 1 件のプリントについて、段階、一時停止、レイヤー、温度回復、エラーを順序付きのタイムラインとして再構成します。

  1 件のプリントで、どこで速度が落ちたか、一時停止したか、回復したか、失敗したかを説明する場合に適しています。

  bambu-pp-cli job timeline --latest --agent
  

• job repeats — 同じプレートの繰り返し実行について、所要時間、一時停止、材料、エラー、結果を比較します。

  繰り返し行われるプリントが安定して再現可能かどうかを判断する場合に適しています。

  bambu-pp-cli job repeats "Colored Accents" --agent
  

材料を考慮した運用

• ams runway — アクティブな AMS トレイの材料で、現在のプレートに必要な残り重量をまかなえるかを推定します。トレイの推定値や複数材料のマッピングが曖昧な場合は、明示的に不明として出力します。

  長時間のプリントを無人で実行する前や、どのスプールに対処する必要があるかを判断する場合に適しています。

  bambu-pp-cli ams runway --agent
  

インテグレーションの回復力

• printer field-diff — 選択した期間にわたる、最初と最新の永続化済み MQTT スキーマを比較し、追加、削除、型が変更されたフィールドを示します。

  ローカルに永続化された観測データの間で、レポートの構造変化を調べる場合に適しています。

  bambu-pp-cli printer field-diff --since 7d --agent
  

コマンドリファレンス

observations — LAN のステータスコマンドとイベントコマンドから収集された、ローカルに永続化された、機密情報を除去済みのプリンター観測データです。

• bambu-pp-cli observations — ローカルに永続化されたプリンター観測データを一覧表示します。

適切なコマンドを見つける

実行したい操作は分かっていても、どのコマンドを使えばよいか分からない場合は、CLI に直接尋ねてください。

bambu-pp-cli which "<capability in your own words>"

which は、自然言語による機能の問い合わせを、この CLI の厳選された機能インデックスから最も適したコマンドに対応付けます。終了コード 0 は少なくとも 1 つ一致したことを示し、終了コード 2 は確信を持って一致するものがなかったことを示します。その場合は --help を参照するか、より具体的な問い合わせを使用してください。

手書きの拡張機能

これらのコマンドは仕様の作成者によって宣言されており、個別に手書きで配線する必要があります。ジェネレーターはこれらの Cobra 登録を出力しません。見つけやすいようにここに記載しています。また、verify-skill の未知のコマンドのチェックでジェネレーター管理のパスと判定されないよう、意図的に ## Command Reference の外に配置しています。

• bambu-pp-cli discover — SSDP とシリアル番号によるフィルタリングを使用して、プライベート LAN 上の Bambu プリンターを検出します。
• bambu-pp-cli profile — 秘密情報を安全に扱う複数プリンターのプロファイルと環境変数の優先順位を管理します。
• bambu-pp-cli printer status — 最新の正規化された MQTT pushall ステータススナップショットを取得します。
• bambu-pp-cli printer raw — 不明なファームウェアフィールドを含む、マスキング済みの MQTT レポート全体を返します。
• bambu-pp-cli events watch — 印刷の開始時と終了時のライフサイクルペイロードを、プロバイダーに依存しない NDJSON 形式で出力します。
• bambu-pp-cli events monitor — 1 件の印刷を監視し、そのイベントログとプレビューアセットを自動的に保持します。
• bambu-pp-cli printer watch — 正規化されたプリンターのスナップショットと、再起動に対応したライフサイクル遷移をストリーミングします。
• bambu-pp-cli printer temperatures — ベッド、チャンバー、ノズル、AMS の現在温度と目標温度を表示します。
• bambu-pp-cli printer fans — 利用可能なパーツ冷却、補助、チャンバー、ヒートブレイク、エアダクトファンの状態を表示します。
• bambu-pp-cli printer capabilities — モデルに応じたライト、速度、ネットワーク、ドア、ストレージ、ファームウェア、ノズル、ツールの機能を表示します。
• bambu-pp-cli ams status — AMS のユニット、トレイ、素材、色、RFID、湿度、温度、残量の推定値を表示します。
• bambu-pp-cli ams active — Bambu のトレイ仕様に基づいて、アクティブな AMS トレイまたは外部スプールを特定します。
• bambu-pp-cli ams services — AMS の乾燥サービスとフィラメントバックアップサービスの読み取り専用状態を表示します。
• bambu-pp-cli printer health — 正規化された HMS メッセージと印刷エラーを履歴とともに表示します。
• bambu-pp-cli job current — 現在のジョブ ID、プレートの進捗状況、ETA、レイヤー、ステージ、速度、ファイル、時間情報を表示します。
• bambu-pp-cli job objects — 現在のジョブで印刷可能なオブジェクトとスキップされたオブジェクトの識別情報を表示します。
• bambu-pp-cli job metadata — FTPS 経由で、現在のジョブに正確に対応する、サイズ制限付きの 3MF プレート、オブジェクト、素材のメタデータを読み取ります。
• bambu-pp-cli job thumbnail — 検証済みの現在のプレートのプレビュー画像を、指定した出力パスに書き込みます。
• bambu-pp-cli printer services — キュー、アップロード、アップグレード、カメラ、タイムラプスの運用フラグを表示します。
• bambu-pp-cli files list — 証明書を検証する暗黙的 FTPS 経由で、プリンター上のファイルを一覧表示します。
• bambu-pp-cli files download — サイズ制限付きのプリンターファイルを、指定した安全なローカルパスにダウンロードします。
• bambu-pp-cli history — ローカルに保存されたジョブ、結果、所要時間、遷移、観測データを照会します。
• bambu-pp-cli maintenance — 使用状況に基づくメンテナンスの期限状態、予測、完了記録を管理します。
• bambu-pp-cli analytics — ローカルの観測データストアを使用して、プリンターとジョブの分析を実行します。
• bambu-pp-cli job eta — 校正済みの完了時刻と過去の誤差範囲を予測します。
• bambu-pp-cli ams runway — 現在のプレートに必要なフィラメントに対する、装填済みフィラメントの余剰または不足を推定します。
• bambu-pp-cli job repeats — 同じ印刷可能なジョブの保存済み実行を比較します。
• bambu-pp-cli printer field-diff — ファームウェアレポートのフィールドの追加、削除、型変更、古さを検出します。
• bambu-pp-cli history failure-correlations — 失敗したジョブを、プリンター、フィラメント、プレート、ファームウェア、速度、温度の状況と関連付けます。
• bambu-pp-cli job timeline — 1 件の印刷について、ステージ、一時停止、レイヤー、熱回復、エラーを再構成します。

レシピ

自動化対応のプリントイベント

bambu-pp-cli events monitor --agent

プリントを開始する前に実行します。このコマンドはプリントを1件待ち、利用可能な埋め込み3MFプロジェクト／プロファイルのタイトル、オブジェクト名、重量、プレビューを含む開始ペイロードをストリーミングし、終端ペイロードを受信すると終了します。また、同じNDJSONとプレビューがあればそれも、タイムスタンプ付きの非公開データディレクトリに保存します。対応する終端ペイロードでは、付加情報を含む識別情報が再利用され、添付ファイルは繰り返されません。job.name は埋め込み3MFプロジェクトのタイトルを優先し、それがない場合は、印刷可能なオブジェクトが1つだけなら拡張子を除いた名前を使用します。job.source_name はプリンターのラベルを保持し、job.project_name、job.profile_name、job.objects は明示的に保持されます。ローカルのBambu Studioウィンドウのファイル名は、プリンター側の3MFでは送信されないため、LAN MQTT/FTPS経由では取得できません。別のプログラムで特定の保存先が必要な場合に限り、--output-dir を使用してください。ディスプレイから開始されたジョブでは、プリンター内のGコードのみが取得され、3MFメタデータが含まれない場合があります。

events watch は、独自のライフサイクルとアセットストレージを管理する長時間稼働のコンシューマー向けの、より低レベルなプリミティブです。

多くのジョブにわたって監視を続けるデーモンやボットでは、無期限に動作するウォッチャーに必ず明示的な運用期間を指定してください。

bambu-pp-cli events watch --agent --asset-dir <dir> --timeout 24h

現在のプリント状況を簡潔にまとめる

bambu-pp-cli printer status --agent --select state,job.name,job.percent,job.estimated_finish_at,job.current_layer,job.total_layers,ams_active

通知やエージェントに必要なフィールドだけを残します。

フィラメントの残量を確認する

bambu-pp-cli ams runway --agent

現在のプレートを完了できるだけの材料が装填されているかを推定します。

最新のプリントについて説明する

bambu-pp-cli job timeline --latest --agent

工程、一時停止、レイヤーの進捗、温度の回復、エラーを再構成します。

繰り返し発生する失敗の状況を調べる

bambu-pp-cli history failure-correlations --since 30d --agent

失敗したジョブを、プリンター、フィラメント、プレート、ファームウェア、速度、温度の状況別にグループ化します。

認証の設定

プリンターのネットワーク設定からBAMBU_SERIALとBAMBU_ACCESS_CODEを設定します。BAMBU_HOSTは任意です。検出機能がDHCPの変更に追従するためです。マルチキャストSSDPがローカルネットワークを通過できない場合に限り、BAMBU_HOSTを設定してください。CLIは通常のローカルアクセスのみを使用し、プリンターのCAを検証したうえで、ピア証明書のCNが設定済みのシリアル番号と一致するかを確認します。

bambu-pp-cli doctor を実行して設定を検証します。

エージェントモード

任意のコマンドに --agent を追加します。次のオプションに展開されます：--json --compact --no-input --no-color --yes。

• パイプ処理可能 — stdoutにはJSON、stderrにはエラーが出力されます

• フィルタリング可能 — --select でフィールドを絞り込めます。ドット区切りのパスはネストした構造をたどり、配列は各要素をたどります。冗長なAPIのコンテキストを小さく保つために重要です。

  bambu-pp-cli observations --agent --select id,name,status
  

• プレビュー可能 — --dry-run でリクエストを送信せずに表示します

• オフライン対応 — 同期／検索コマンドは、利用可能な場合にローカルのSQLiteストアを使用できます

• 非対話型 — プロンプトは表示されず、すべての入力をフラグで指定します

• 読み取り専用 — このCLIを、作成、更新、削除、公開、コメント、賛成投票、招待、注文、送信、その他の変更を伴うリクエストに使用しないでください

レスポンスエンベロープ

ローカルストアまたはAPIから読み取るコマンドは、出力をデータの出所を示すエンベロープでラップします。

{
  "meta": {"source": "live" | "local", "synced_at": "...", "reason": "..."},
  "results": <data>
}

データには .results を解析し、ライブデータかローカルデータかを確認するには .meta.source を参照してください。人が読める N results (live) の概要がstderrに出力されるのは、stdoutがターミナルで、かつ機械処理用の形式フラグ（--json、--csv、--compact、--quiet、--plain、--select）が設定されていない場合のみです。パイプ／エージェントのコンシューマーと、形式を明示した実行では、stdoutにJSONのみが出力されます。

パスと状態

エージェントは、CLI のパスリゾルバーをランタイム契約の一部として扱う必要があります。

• 1 回の実行には --home <dir> を使用するか、BAMBU_HOME=<dir> を設定して、4 種類すべてのパスを 1 つのルート配下に移動します。

• 特定の種類のパスだけを別の場所にする必要がある場合に限り、種類ごとの環境変数 BAMBU_CONFIG_DIR、BAMBU_DATA_DIR、BAMBU_STATE_DIR、BAMBU_CACHE_DIR を使用します。

• 解決の優先順位は、種類ごとの環境変数、--home、BAMBU_HOME、XDG（XDG_CONFIG_HOME、XDG_DATA_HOME、XDG_STATE_HOME、XDG_CACHE_HOME）、プラットフォームのデフォルトの順です。

• config には config.toml やプロファイルなどの設定が含まれます。data には credentials.toml、data.db、Cookie、認証用サイドカーが含まれます。state には永続化されたクエリ、ジョブ、teach.log が含まれます。cache には再生成可能な HTTP／キャッシュファイルが含まれます。

• 保存されたシークレットは、data ディレクトリ内の credentials.toml にあります。既存のレガシーな config.toml のシークレットは互換性のために読み込まれ、最初の認証書き込み時に config.toml から削除されます。

• bambu-pp-cli doctor --fail-on warn を実行すると、パスと認証情報の保存場所に関する警告を確認できます。agent-context は、解決済みのディレクトリが必要なエージェント向けに、スキーマ v4 の paths ブロックを公開します。

• MCP の場合は、MCP ホストの設定でパスの移動先を指定します。MCP バイナリは CLI フラグを継承しません。

  {
    "mcpServers": {
      "bambu": {
        "command": "bambu-pp-mcp",
        "env": {
          "BAMBU_HOME": "/srv/bambu"
        }
      }
    }
  }
  

パスの優先順位：継承された種類ごとの環境変数は、その種類について明示的な --home より優先されます。インストール先を永続的に移動する場合は BAMBU_HOME または種類ごとの環境変数を使用し、--home は 1 回の実行に限って使用します。環境変数を解除しても、移動は元に戻りません。BAMBU_HOME を解除する前にファイルを手動で移動してください。そうしないと、doctor は以前のルートに残された認証情報を見つけられません。

自動学習

この CLI には、自己記録型の学習ループが組み込まれています。CLI が自身の記録を管理します。すべての実行がローカルに記録され、フラグの失敗後に修正して再試行すると、flag_alias 候補が自動的に導出され、プレイブックのないクエリファミリーに対して teach を実行すると、セッションの記録から playbook_candidate が自動生成されます。あなたが判断するのは、recall を最初に実行し、提示された候補に基づいて行動し、最終回答を teach し、修正を確認したら playbook amend を実行することだけです。失敗を手動で記録する必要はありません。

ステップ 1：あらゆる探索の前に recall

新しいユーザーの質問に対して、list／search／drill コマンドを実行する前に、次を実行します。

bambu-pp-cli recall "<user's question>" --agent

応答エンベロープ：

{
  "query": "...",
  "normalized": "<normalized form>",
  "query_entities": ["..."],
  "found": true | false,
  "match_score": 0.0,
  "results": [
    { "resource_id": "...", "resource_type": "...", "venue": "...",
      "confidence": 2, "entity_match": "exact|partial|unknown",
      "source": "taught|preseed|pattern", "warnings": ["..."] }
  ],
  "mismatches": [ /* only when --debug-mismatches */ ],
  "warnings": [ /* top-level */ ],
  "candidates": [
    { "id": 12, "class": "flag_alias | playbook_candidate",
      "summary": "...", "sightings": 3, "last_seen": "...",
      "rationale": "...",
      "next_action": ["<trial command>", "bambu-pp-cli learnings confirm 12"] }
  ],
  "playbook": {
    "query_family": "...",
    "playbook": {
      "steps": [ { "cmd": "<command with {slot} substitution>", "purpose": "..." } ],
      "entity_slots": ["$ENTITY"],
      "expected_tool_calls": 3
    },
    "slots_resolved": { "$ENTITY": { "token": "<live token>", "canonical": "<canonical>" } },
    "notes": "<workarounds + gotchas for this query family>"
  },
  "notes": "<duplicate surface for non-playbook callers>"
}

空ストアのショートサーキット：ストアに学習内容、プレイブック、候補がまだない場合（recall で何も見つからず、learnings list と learnings candidates がどちらも空の場合）、すべてのクエリに負荷をかけないよう、このセッションの残りでは recall を省略します。何かを教えた後は、再び recall を最初に実行します。

ステップ 2：判断ツリー

candidates、playbook、notes、results[0]、警告の順に確認します。

if Candidates present (warnings include "candidates_present"):
    -> candidates are try-then-confirm, never facts. Follow each candidate's
       two-step next_action verbatim: run the trial command first, then run
       `learnings confirm <id>` only after the trial verified the behavior.
       Reject a wrong candidate with `learnings reject <id>`.
    -> NEVER re-teach something recall surfaced as a candidate; confirm or
       reject that candidate instead of teaching a duplicate.
    -> candidates ride alongside playbooks and resource hits, not instead of
       them; continue with the branches below after acting on them.

if Playbook present:
    -> READ Playbook.notes verbatim FIRST (workarounds + gotchas the CLI surface doesn't expose)
    -> replay Playbook.steps in order, substituting Playbook.slots_resolved entries
       for the entity slot tokens. If a step's slot is unresolved, fall back to
       discovery for that step only.
    -> the Playbook's expected_tool_calls is a budget; if you find yourself running
       materially more, record the divergence via `bambu-pp-cli playbook amend`
       at end-of-session.

elif Notes present (no Playbook):
    -> read Notes verbatim before any discovery step; they carry known gotchas
       for this query family even when no structured choreography exists yet.

elif Found AND Results[0].EntityMatch == "exact" AND Results[0].Confidence >= 2:
    -> skip discovery; fetch live data for Results[*].ResourceID in parallel

elif Found AND Results[0].EntityMatch == "partial":
    -> candidate hint, NOT a hit; read the resource title to validate before trusting

elif (any row in Mismatches[] when --debug-mismatches was passed):
    -> treat as cold start; the stored learning is for a different entity
       (different canonical resolved from query_entities)

else:  // Found == false, no playbook, no notes
    -> cold start; run discovery normally; teach the answer afterward (Step 4).
       If the family has no playbook yet, that teach auto-synthesizes a
       playbook candidate from this session's journal - you do not need to
       record one by hand.

プレイブックと Notes は、リソースごとのパスとは独立しています。recall の応答には、プレイブックと Results[] のヒットの両方が含まれる場合があります。その場合は両方を使用します。プレイブックは実行する手順を示し、リソースのヒットは特定のステップを省略するために使えます。デフォルトでは mismatches を省略し、コールドスタート時の予想外の動作を調査する場合に限り --debug-mismatches を渡します。

候補の判断について：learnings confirm <id> は候補を適用する前に、候補のペイロード全体を表示します。表示されたペイロードが、検証した動作と一致することを確認してください。learnings reject <id> は導出シグネチャをトゥームストーン化し、同じ候補が再び表示されないようにします。エンベロープに含まれるのは、今すぐ対応する価値のある少数の候補だけです。bambu-pp-cli learnings candidates では、未処理候補の全件を確認できます。

グレースフルデグラデーション：learnings confirm が不明なコマンドの場合、古いバイナリを操作しています。候補に関する案内は無視し、プロトコルの残りに従ってください。

ステップ 3：warnings は必ず確認する

• low_confidence：confidence<2 の行が存在します。ヒントとして扱い、発見をスキップする根拠にはしないでください。
• resource_not_in_store：学習で参照されたリソースがローカルストアにありません。マッチバリデーターがエンティティを分類できなかったため、直接取得して再評価してください。
• cross_alias_match（結果ごと）：その行は別のエイリアスで学習され、entity_lookups を通じてライブクエリの正規形と一致しました（例：「USA」での学習が「United States」の検索に適合）。resource_id を信頼してください。
• similar_shape_different_entity:<canonical>（トップレベル）：構造的に一致する行はありますが、その正規形エンティティはライブクエリのものとは異なります。コールドスタートとして扱われます。この警告にはヒントとして競合する正規形が含まれますが、その行は「結果」に昇格されません。
• ambiguous_alias（トップレベル）：1 つのクエリエンティティが複数の正規形に解決されました（例：「Cards」→Arizona Cardinals と St. Louis Cardinals）。リソースを確定する前に、コンテキストに基づいて曖昧さを提示してください。
• candidates_present（トップレベル）：エンベロープに candidates セクションが含まれています。ほかの処理に進む前に、ステップ 2 の候補分岐で処理してください。
• lookup_refresh_available（トップレベル）：クエリ内のエンティティにルックアップ行がまだありませんが、同期済みデータから追加できる可能性があります。bambu-pp-cli sync を実行してエンティティのルックアップを更新してください。
• トップレベルの no_learnings_for_query_family：Jaccard の下限を超える行がテーブルにありません。完全なコールドスタートです。

ステップ 4：回答を確定した後は、必ず teach & を実行する

ティーチングは無条件です。ストアで回答できなかったクエリを解決した後、最終的なリソースのマッピングをバックグラウンドで学習させてください。呼び出し回数のしきい値は設けず、学習する「価値」があったかどうかも判断しません。ティーチングはこのループの要です。プレイブックがないファミリーに対するプレイブックの合成を開始し、同じ参照対象を指す言い回しは 1 つのファミリーにまとめられるため、ほぼ重複するティーチングでストアが分断されることはありません。ユーザー向けの回答を組み立てた後、出力する前に、シェルの & を使って実行し、呼び出しがすぐに戻るようにしてください。

bambu-pp-cli teach --query "<user's question>" --resource-type <type> --resource <id1> --resource <id2>
# (append shell `&` to background it)

成功時は何も出力されません。エラーは、解決済みの状態ディレクトリ内にある teach.log にのみ記録されます。最も具体的なリソースを学習させてください。ユーザーの質問が広範で、具体的な回答を見つけるために親レコードをたどった場合は、親ではなく末端の ID を学習させます。CLI は検索時にシード済みの entity_lookups を使ってエイリアス間の解決を行うため、あるエイリアス（例：「Niners」）で学習させると、別のエイリアス（例：「49ers」、「San Francisco」）での今後のクエリにも自動的に対応します。

PII に関するルール：識別子を削除した構造的な質問を学習させてください。学習させるクエリやメモには、名前、メールアドレス、電話番号、アカウント ID、その他の個人識別子を絶対に含めないでください。CLI は学習クエリをスキャンして、明らかなメールアドレスや電話番号の形式を検出すると警告しますが、処理はブロックしません。警告に頼るのではなく、学習前に削除してください。

ステップ 5：プレイブック — オプションのフラグ、自動合成

セッションにプレイブックが「ふさわしい」かどうかを判断する必要はありません。プレイブックがないファミリーに対して teach を実行すると、セッションのジャーナルから playbook_candidate が自動合成され、次のセッションで確認または却下されます。明示的なプレイブックフラグを付けるのは、そのまま記録する価値のある手順をすでに把握している場合に限ります。CLI では見つからなかった回避策（気付かれずに破棄されるフラグ、未公開のパラメーター、ページネーションの工夫、ペイロードに関する注意点など）が該当します。統合された一度の呼び出し形式を優先してください。リソースに関する学習内容とプレイブックを、同じ teach 呼び出しで記録します。

# Common case: record both the resource learning AND the playbook in one call.
bambu-pp-cli teach \
  --query "<user's question>" \
  --resource <id> \
  --playbook-file ~/playbooks/<shape>.json \
  --playbook-notes-file ~/playbooks/<shape>-notes.md
# (append shell `&` to background it)

# Alternate: playbook-only (no resource to record alongside).
bambu-pp-cli teach-playbook \
  --query "<user's question>" \
  --playbook-file ~/playbooks/<shape>.json \
  --notes-file ~/playbooks/<shape>-notes.md

プレイブックファイルは steps、entity_slots、expected_tool_calls を含む JSON です。ノートファイルは注意点をそのまま記載した Markdown です。ファイルを扱わない呼び出し元（MCP のみのエージェント）は、同じ内容をインラインで渡します。統合された teach 形式では --playbook-json と --playbook-notes を、teach-playbook では --playbook-json と --notes を使用します。統合された teach 形式では、プレイブックのフラグはオプションです。リソースのみを教える場合は、フラグをすべて省略してください。単独の teach-playbook 形式では、プレイブックとノートのフラグの少なくとも一方を設定する必要があります。両方が空の場合は拒否されます。プレイブックは、構造上のクエリファミリー（エンティティを取り除いたもの）に基づいて管理されます。そのため、あるエンティティ形状のクエリから学習したレシピは、同じ形状を持つほかのすべてのクエリに適用されます。呼び出し時には slots_resolved が、実際のクエリの正規形を割り当てます。

今後の呼び出しでプレイブックが見つかった場合は、それを確かな情報源として扱ってください。slots_resolved による置換を適用して手順を再実行し、すでに手順書に記載されている探索は省略して、どの手順よりも先に notes を読んでください。

ステップ 6：デバッグ応答で修正点を特定した場合は、playbook amend & を実行する

デバッグプロトコルへの応答で、ノートやプレイブックに反映すべき具体的な修正点（回避策、未公開のエンドポイント形式、古いフィールド名、確認されたスキーマの変化、空のペイロードへのフォールバックなど）を特定した場合は、ユーザー向けの応答を出す前に playbook amend を実行してください。teach と同様に、実行後の完了を待たずに進めます。

bambu-pp-cli playbook amend \
  --query "<exact recall query string>" \
  --add-note "<your concrete correction>"
# (append shell `&` to background it)

修正する価値があるもの：このセッションで実際に確認した動作で、将来の自分が知っていると役立つものです。修正する価値がある例：

• フラグを気付かれずに破棄したり、順序を誤って処理したりする CLI の仕様に対する回避策。
• 未公開のエンドポイント形式（レスポンスが {meta, results} でラップされている、ペイロードがドキュメントの説明よりもさらに 2 階層深いなど）。
• 確認されたスキーマの変化（フィールド名の変更、シーズン間でのインデックスのずれ、API が返すカテゴリラベルの小文字化など）。

ノートに記載しないもの：

• ユーザーの質問に対する、年やエンティティに固有の回答。これは応答であり、学習内容ではありません。
• プレイブックが実行時にすでに取得するチーム、選手、行ごとのデータ。
• 既存のノートの内容を言い換えた記述。

amend コマンドは、ファミリーの既存のノートにタイムスタンプ付きのマーカー（[amend YYYY-MM-DDTHH:MMZ]: <text>）を追記します。複数の amend は蓄積され、監査履歴を確認できます。ファミリーにプレイブックがまだ存在しない場合、amend はノートのみのプレイブックを作成するため、コールドスタート時の修正も反映されます。

amend ノートにおける PII の取り扱い

将来の Printing Press のバージョンで、playbook amend のノートが共有知識として上流に提供される可能性があります。遡及的な削除を行わずに上流への提供を続けられるよう、ユーザーを特定できる情報を含めないでください。

• 含めてはいけないもの：ユーザーのファイルシステム上のパス、個人用の API キーやトークン、ユーザーのメールアドレス、ユーザーの GitHub ハンドル、単一ユーザーに紐付いた特定のクエリ履歴。
• 含めてもよいもの：エンドポイントの形式、未公開のフィールド名、API の注意点、確認されたスキーマの変化、CLI の仕様に対する回避策、汎用的なページネーションや再試行の方法。

修正点がユーザー固有のコンテキストでのみ意味を持つ場合は、プレイブックの amend ではなく、個人用のノートに記録してください。

ループの測定

bambu-pp-cli learnings stats は、ローカルの learn_events テーブルから、リコールのヒット率、teach-to-reuse、プレイブック解決率、候補の確認/却下件数を報告します。率は分母が存在するまで null です。すべてはこのマシン上に留まります。これを使って、この CLI にとってループがその維持に見合う成果を上げているかを確認してください。

学習の無効化

• 単一のコマンドで --no-learn を指定すると、recall と teach の書き込みパスの両方が短絡されます。累積された学習の影響を受けてはならない決定論的なエージェントフローやテストに使用してください。
• 環境変数で BAMBU_NO_LEARN=true を設定すると、パイプラインがグローバルに無効化されます。

エージェントフィードバック

あなた（またはエージェント）がこの CLI について何かおかしいと気づいたときは、それを記録してください:

bambu-pp-cli feedback "the --since flag is inclusive but docs say exclusive"
bambu-pp-cli feedback --stdin < notes.txt
bambu-pp-cli feedback list --json --limit 10

エントリは、解決されたデータディレクトリ配下に feedback.jsonl としてローカルに保存されます。BAMBU_FEEDBACK_ENDPOINT が設定されており、かつ --send が渡されるか BAMBU_FEEDBACK_AUTO_SEND=true である場合を除き、決して POST されることはありません。デフォルトの動作はローカルのみです。

バグレポートではなく、あなたが驚いたことを書いてください。短く、具体的に、1 行で。それが複利的に積み上がる部分です。

出力の配信

すべてのコマンドは --deliver <sink> を受け付けます。出力は stdout に加えて（または stdout の代わりに）指定されたシンクに送られるため、エージェントは手動でパイプすることなくコマンドの結果をルーティングできます。3 つのシンクがサポートされています:

シンク	効果
stdout	デフォルト。stdout にのみ書き込みます
file:<path>	出力を <path> にアトミックに書き込みます（tmp + rename）
webhook:<url>	出力ボディを URL に POST します（application/json、--compact の場合は application/x-ndjson）

未知のスキームは、サポートされているセットを明示した構造化エラーで拒否されます。Webhook の失敗は非ゼロを返し、URL と HTTP ステータスを stderr にログ出力します。

名前付きプロファイル

プロファイルは、フラグ値の保存済みセットであり、呼び出しをまたいで再利用されます。スケジュールされた、または定期的なエージェントが、実行ごとに異なる入力を行いながら同じ保存済みフラグを再利用する場合に使用してください。

bambu-pp-cli profile save briefing --json
bambu-pp-cli --profile briefing observations
bambu-pp-cli profile list --json
bambu-pp-cli profile show briefing
bambu-pp-cli profile delete briefing --yes

明示的なフラグは常にプロファイルの値より優先されます。プロファイルの値はデフォルトより優先されます。agent-context は、利用可能なすべてのプロファイルを available_profiles の下に一覧表示するため、イントロスペクションを行うエージェントは実行時にそれらを発見できます。

プリンタープロファイル

一般的な 1 台のプリンター構成では、BAMBU_SERIAL と BAMBU_ACCESS_CODE を使用します。複数のプリンターの場合は、名前と環境変数の参照のみを保存し、グローバルの --printer セレクターを使用します:

export OFFICE_BAMBU_SERIAL="<office-printer-serial>"
export OFFICE_BAMBU_ACCESS_CODE="<office-local-access-code>"
bambu-pp-cli profile printer-add --name office --serial-env OFFICE_BAMBU_SERIAL --access-code-env OFFICE_BAMBU_ACCESS_CODE
bambu-pp-cli profile printer-list --agent
bambu-pp-cli events monitor --printer office --agent
bambu-pp-cli profile printer-delete --name office

プリンタープロファイルはシリアルやアクセスコードを保存しません。--printer はライブコマンド、プリンタースコープの履歴、および observations に適用されます。自由形式の search と sql には、明示的に永続化された printer_key 述語が必要です。

終了コード

コード	意味
0	成功
2	使用法エラー（引数が正しくない）
3	リソースが見つからない
4	認証が必要
5	API エラー（上流の問題）
7	レート制限（待機して再試行）
10	設定エラー

引数の解析

$ARGUMENTS を解析します:

1. 空、help、または --help → bambu-pp-cli --help の出力を表示します
2. install で始まる → mcp で終わる → MCP インストール。それ以外 → 上記の前提条件を参照してください
3. それ以外 → 直接使用（--agent を付けて CLI コマンドとして実行）

MCP サーバーのインストール

1. MCP サーバーをインストールします:

   go install github.com/mvanhorn/printing-press-library/library/devices/bambu/cmd/bambu-pp-mcp@latest
   

2. Claude Code に登録します:

   claude mcp add bambu-pp-mcp -- bambu-pp-mcp
   

3. 確認: claude mcp list

直接使用

1. インストールされているか確認します: which bambu-pp-cli 見つからない場合は、インストールを提案します（このスキルの冒頭にある前提条件を参照してください）。
2. ユーザーのクエリを、上記の「独自の機能」と「コマンドリファレンス」から最適なコマンドに一致させます。
3. --agent フラグを付けて実行します:

   bambu-pp-cli <command> [subcommand] [args] --agent
   

4. 曖昧な場合は、サブコマンドのヘルプを詳しく調べます: bambu-pp-cli <command> --help。