Kelet 統合

すぐに計画モードに入ります。 スキルの最初のアクション: EnterPlanMode を呼び出し、分析 → マッピング → シグナル → 計画のシーケンス全体を読み取り専用で実行します。ユーザーが実装承認で最終的な実装計画を承認した後にのみ ExitPlanMode を呼び出します。

北極星: 優れた開発者体験、可能な限り最短での価値実現。 開発者は Kelet が自動統合されたと感じるはずです — 開発者からの入力を最小限にし、最大の価値を即座にコンソールで確認できるようにします。

Kelet は例外を発生させません。 すべての SDK エラーは抑制されます — 設定が間違っていても、正しく動作している統合とまったく同じように見えます。

コードを書く前にライブドキュメントを取得: GET https://docs-ai.kelet.ai/chat?q=<質問> （推奨）または https://kelet.ai/docs/llms.txt を取得してインデックスを確認します。

オンボーディング

ウェルカムバナーで開始: 🕵️ Kelet へようこそ — AI 探偵。Kelet はトレースとシグナルを取り込み、障害をクラスタリングし、修正案を提案する推論エージェントです。コードの前にこれらの概念を教えてください — 箇条書きでは探偵のメタファーを維持してください:

トレース = 現場。 kelet.configure() 後にすべての LLM 呼び出しとツール使用が自動記録されます。
シグナル = 情報提供。 👎、編集、中止 — 探偵に調査に値するものを示します。確定ではありません: 👎 は ここから調べ始める を意味します。
シンセティック = 法医学ツール。 トレースデータからの自動シグナル。コードは不要です。
セッション = 事件ファイル。 1 つの作業単位でグループ化されたトレース。
プロジェクト = 管轄区域。 エージェントユースケースごとに 1 つ。間違ったプロジェクト = RCA で見えなくなります。
次: サイレント分析 + ≤3 回の AskUserQuestion 呼び出し（理想的には 2 回）

統合モード

軽量（デフォルト）: 可能な限り少ないコード変更 — 理想的には kelet.configure() のみ。必要な場合のみ agentic_session() を追加（セッションを参照）、管理されたシンセティック（コードゼロ）、および既存のフックに簡単に配線できる場合にのみ最大 1～2 のコード化されたシグナル。開発者が「拡張」、「シグナルを追加」、「深く掘り下げる」と言わない限り、これをデフォルトにします。

フル: すべてのシグナルレイヤー + VoteFeedback UI + 完全な障害モードマッピング。

迷ったら軽量に。コード変更が増えるごとに、開発者にとってはコストになります。

プレゼンテーションスタイル

トーン: 温かみがあり、専門的。概念をメカニズムの前に。各チェックポイントはバナーで開始: <絵文字> <フェーズ> — 1 単語、大文字、それ以外はなし。フェーズ: MAPPING、SIGNALS、PLAN、IMPLEMENT、VERIFY。

進捗トラッカー — 正確にこれらのラベル:

📍  Mapping 🔄 → Signals ○ → Plan ○ → Implement ○ → Verify ○

内部作業（例: 0a、0b、1、サブステップ）は表示しません。ユーザーはフェーズが ✅ に変わったときにのみ進捗を確認できます。

主要ルール

簡潔に — 決して繰り返さない。 すべてのトークンは時間を消費します。各事実を 1 回述べ、データを系統的に収集し、既に説明したことを再説明しないでください。
入力には常に AskUserQuestion を使用 — 自由形式のテキストは不可。リストには multiSelect: true を使用します。
AskUserQuestion の呼び出しは合計で最大 3 回（理想的には 2 回）。 推測できる場合は尋ねないでください。
事前チェック（予算外）: トリガーメッセージにアプリの説明がない場合、ファイルを読む前に「あなたの AI アプリは何をし、ユーザーはどのように操作しますか？」と尋ねます。
最初にサイレント分析。 チェックポイント 1 と 2 では計画モードを維持し、実装承認でのみ ExitPlanMode を呼び出します。
Kelet が既に依存関係にある場合: セットアップをスキップし、要求された内容に集中します。分析パスと Verify は引き続き適用されます。
アプリの視覚スタイルに合わせます。 追加される UI（VoteFeedback ボタン、コピーボタン、再試行など）は、任意のインラインスタイルや絵文字のデフォルトではなく、アプリの既存の CSS クラス、デザイントークン、コンポーネントパターンを使用する必要があります。子コンポーネントを作成する前に、スタイルシートと既存のコンポーネントを読んでください。

質問スロット:

チェックポイント 1 — プロジェクト/ワークフローマップを確認
チェックポイント 2 — 計画を確認 + キーとプロジェクト名を収集
デプロイメントが本当に不明で、シークレットを安全に進められない場合のみ

これらの間でのマイクロ確認は行いません。

分析パス（サイレント）

🧠 何かを尋ねる前にすべてを読んでください。開発者はクイズ形式ではなく、確認されるべきです。

静かに読みます — まだ質問はありません。以下をカバー:

依存関係 — AI フレームワーク、UI スタック、パッケージマネージャー
エントリーポイント — configure() を配置する場所
LLM 呼び出しサイト — フロー、オーケストレーションパターン
セッション追跡 — 会話 ID、リクエスト ID、Redis キー、DB カラム。セマンティクスを評価: 候補 ID はリセット/新しい会話で変更されますか？そうでない場合、不一致を表面化します。references/implementation.md を参照。
既存のフィードバック UI — サムズ、評価、編集、再試行、コピーボタン。これらに配線し、置き換えないでください。
デプロイメントインフラ — 尋ねる前にスキャン: helm/、charts/、.github/workflows/、vercel.json、railway.json、render.yaml、fly.toml、docker-compose.yml、Procfile、*.tf、template.yaml

スタイリング、認証、無関係なビジネスロジックはスキップします。エージェントフロー内の他のリポジトリ/サービスにフラグを立てます — 開発者はそこでもこのスキルを実行する必要があります。

プロジェクトマップを構築:

ユースケース: [エージェントが行うこと]
フロー → Kelet プロジェクト:
  - フロー "X" → プロジェクト "X"
ユーザー向け: はい/いいえ
スタック: [サーバー] + [LLM フレームワーク]
設定: .env / .envrc / k8s
デプロイメント: [プラットフォーム | 見つかりません]
モード: 軽量 | フル

ASCII アーキテクチャ図を作成し、データフローとセッション ID がどこを通過するかを示します。

チェックポイント 1: マッピング確認

図 + プロジェクトマップ + 統合モード + 簡単なワークフロー概要（ステップ、エージェントの観点からの成功/失敗の様子）を提示。

AskUserQuestion: 「この図、マップ、ワークフロー概要はあなたのシステムを正確に表していますか？見落としているものはありますか？」

セッションセマンティクスが本当にあいまいな場合 — この質問に含め、別のスロットを使用しないでください。

修正によりフロー数、フレームワーク、またはセッション構造が変更された場合 — 分析パスをやり直します。確認されるまでシグナル分析に進まないでください。

シグナル分析パス（内部推論）

🧠 この推論をユーザーに表示しないでください。最終的な提案はチェックポイント 2 で表面化します。

調査官が手がかりを仕掛けるように考えてください: もし後で何かがうまくいかなかった場合、どのようなブレッドクラムが原因の追跡に役立つでしょうか？ 障害を予測するのではなく、事後にそれらを明らかにする瞬間を計装します。

唯一のフィルター: Kelet はこの手がかりをセッショントレースから導出できますか？ → シンセティック（コードゼロ）。人間のアクションや外部イベントが必要ですか？ → コード化されたシグナル。

シンセティック（プラットフォーム、顧客コード不要):

この特定のユースケースに対して意味のある品質シグナルをキャプチャする評価者を選択します。アンカー: タスク完了。このアプリにとって「良い」と「悪い」の様子を反映する 1～2 を追加します。ディメンションごとに 1 つの評価者 — ディメンションを複製するとノイズが増幅されます。プリセットリストについては references/signals.md を参照してください。

コード化 — フロントエンド（軽量: 最大 0～2):

ほとんどの場合フロントエンド — 人間が AI 出力に反応します。コンシューマーが別のシステムであるか、フィードバックがエンドポイント経由で到着する場合（例: /approve）にのみサーバーサイド。

Vote → VoteFeedback、編集 → useFeedbackState、行動イベント → useKeletSignal
kind: FEEDBACK · EDIT · EVENT · METRIC · ARBITRARY — source: HUMAN · LABEL · SYNTHETIC
React UI スキャン: AI 出力の編集入力 → useFeedbackState；クリップボードへのコピー、再試行、セッションリセット → useKeletSignal。コピーは、AI テキストをレンダリングするアプリには常に提案する価値があります — まだボタンが存在しなくても、自然なアフォーダンスであり、強力な暗黙のシグナルです。最大 1～2 提案します。

コード化 — サーバーサイド: ブラウザ UI がないか、フィードバックがエンドポイント駆動の場合のみ。

チェックポイント 2 に備える: シグナル提案 + プロジェクト名の提案 + 「表示される内容」のプレビュー。

チェックポイント 2: 計画確認 + 入力収集

シグナル調査結果 + 完全な軽量計画を提示。開発者に設計を依頼しないでください — 提案します。

まだ計画モード — まだ ExitPlanMode を呼び出さないでください。

単一の AskUserQuestion （multiSelect: true）、次のように構成:

提案されたシンセティック評価者 (multiSelect) — 各提案された評価者をオプションとしてリストし、開発者がプロジェクトに含めるものを明示的に選択できるようにします。「なし」もオプションとして含めます。
計画承認 — 「計画の残りは正しいですか？」
キー + プロジェクト名 （不足しているもののみ）:
- KELET_API_KEY (sk-kelet-...) — console.kelet.ai/api-keys で取得。シンセティックの自動作成に必要です。
- 公開可能キー (pk-kelet-...) — VoteFeedback が計画に含まれている場合のみ。
- プロジェクト名: 最初に作成 console.kelet.ai → トップナビ → 新規プロジェクト。名前が間違っている = サイレントルーティング障害；サーバーはヒント付きで 404 を返し、それを表面化します。
API キーモード （シンセティック評価者が選択された場合のみ）:
- 「シークレットキーを貼り付け (sk-kelet-...）」 → プライマリ自動作成。
- 「自分で取得します」 → 停止: 「console.kelet.ai/api-keys でキーを取得し（10 秒）、続行するためにここに貼り付けてください。」
- 「ここにシークレットを貼り付けられません」 → ディープリンクフォールバック。

評価者の作成

プライマリ（キー貼り付け済み): curl の前に、そのまま印刷:

⏳ 評価者を作成しています。これには 1～3 分（場合によっては最大 5 分）かかります — Kelet は LLM を使用して各設定を生成し、重複排除パスを実行します。お待ちください。キャンセルしないでください。

次に、references/signals.md § プライマリ: API 呼び出しごとに実行します。

200 の場合: ✅ Kelet は {project} を監視しています。最初の評価者結果は約 3 分後に https://console.kelet.ai/{project}/signals で確認できます

フォールバック（貼り付け不可): references/signals.md に従って base64 マークダウンリンクを構築します。

表示される内容

テーブルを表示 — 提案された計画内のアイテムの行のみ:

実装後	Kelet コンソールで表示
`kelet.configure()`	トレース内の LLM スパン: モデル、トークン、レイテンシ、エラー
`agentic_session()`	セッションビュー: RCA 用にグループ化された完全な会話
VoteFeedback	シグナル: 👍/👎 正確なトレースに関連付け
編集シグナル (`useFeedbackState`)	シグナル: ユーザーが修正した内容 — モデルエラーを明らかに
プラットフォームシンセティック	シグナル: 自動品質スコア

開発者が明示的に要求し、かつプラットフォームが実装できない場合にのみ source=SYNTHETIC コードを記述します — なぜプラットフォームが処理できないかを説明し、先に進む前に確認を求めます。

実装承認

例外: デプロイメントが未知としてフラグ付けされ、シークレットを安全に処理できない場合、質問スロット 3 を使用します: 「どのようにデプロイしますか？シークレットはどのように管理されますか？」 → references/deployment.md に従います。デプロイメントが特定されたか、無関係な場合はスキップします。

完全な実装計画を提示し、ExitPlanMode を呼び出して承認を求め、その後実装します。

API キー

2 種類 — 決して混在させない:

シークレット (KELET_API_KEY、sk-kelet-...): サーバーのみ。SDK はどちらのキータイプもエラーなく受け入れます — 間違ったキーを使用するとサイレント障害になります。
公開可能 (VITE_KELET_PUBLISHABLE_KEY / NEXT_PUBLIC_KELET_PUBLISHABLE_KEY、pk-kelet-...): フロントエンドのみ。

設定に書き込み: .env → KEY=value · .envrc → export KEY=value · K8s → シークレットマニフェスト。.gitignore に追加。プロジェクト名をハードコードしないでください — 常に環境変数を使用します。アプリにサーバーとフロントエンドの両方がある場合、両方の env ファイルにキーを書き込みます — シークレットキーはサーバー .env に、公開可能キーは frontend/.env に（または Vite/Next が読み取る場所）。本番環境については references/deployment.md に従います。

セッション

セッション = 1 つの作業単位。新しいコンテキスト = 新しいセッション。

agentic_session() は不要 （自動計測): LangChain/LangGraph · LlamaIndex · CrewAI · Haystack · Google ADK (kelet[google-adk] 推奨) · pydantic-ai · DSPy · Langfuse · Langroid · OpenInference/OpenLLMetry を使用するもの

⚠️ オーバーライド — 最初に以下の REQUIRED ブロックを読んでください。 上記のリストは、フレームワークがセッション ID も所有していることを前提としています（短命なインプロセス実行）。アプリが自身でセッション ID を生成する場合（Redis、DB、サーバー発行の UUID）、または複数のリクエストにわたって LLM 呼び出しを調整する場合、agentic_session(session_id=...) はフレームワークに関係なく必須です — フレームワークはあなたの ID を知らず、スパンはリンクされなくなります。迷ったらラップします。

⚠️ ベア LiteLLM — トレースは自動キャプチャされますが、LiteLLM はセッション/エージェントコンテキストをそのスパンに伝播しません。LiteLLM が直接呼び出される場合（Google ADK などの他のサポートフレームワークを介さない）、呼び出しを agentic_session() （およびオプションで kelet.agent()）でラップしてグループ化します。LiteLLM が別の計装フレームワーク下で実行される場合、親スパンがコンテキストを提供します — ラップは不要です。

リストにない場合 — 省略する前に調査します。

agentic_session(session_id=...) 必須 （省略すると両方ともサイレント):

アプリがセッション ID を所有 (Redis、DB、サーバー生成): フレームワークはそれを知らない → VoteFeedback リンケージが壊れます
ループを所有 (エージェント A → エージェント B、Temporal、カスタムオーケストレーター): 全体的なセッション ID を設定するフレームワークがない → スパンがリンクされていないトレースとして表示されます。TS: agenticSession({ sessionId }, callback)。

⚠️ Vercel AI SDK — サポートされているフレームワークですが、セッション ID を設定しません: ルートレベルで agenticSession() を使用します。

ユーザー ID ≠ セッション ID。 安定した識別子（電話、メール、user_id）はセッションよりも長持ちします。アプリに安定したユーザー ID がある場合: 会話ごとに UUID を生成して kelet_session_id とし、リセット時に再生成します。識別子を静かに評価します: PII 以外（内部ユーザー ID、不透明な UUID）→ 尋ねずに user_id= として配線します。明らかな PII（電話、メール）→ 省略しますが、目立つように指摘します: 「⚠️ user_id= は設定されていません — あなたのユーザー識別子は PII（電話/メール）です。PII 以外のユーザー ID がある場合は、ここに渡してユーザーごとの RCA を有効にします。」本当にあいまいな場合 → チェックポイント 1 に統合し、別のスロットを使用しないでください。

署名については references/api.md を参照。スタックごとの注意点については references/stack-notes.md を参照。

実装リファレンス

references/implementation.md を参照。

デプロイメントリファレンス

references/deployment.md を参照。

シグナルリファレンス

references/signals.md を参照。

API リファレンス

references/api.md を参照。

スタックノート

references/stack-notes.md を参照。

Kelet スキル

Kelet スキルとは？

お気に入りのAIに質問する

ドキュメント