Pydantic Logfire（Pythonの設定ツール Pydantic が提供する観測・監視プラットフォーム）へのエントリーポイント（入り口）です。 次のような場合に使用: - ユーザーが「Logfire をセットアップしたい」「プロジェクトに Logfire を追加したい」「Logfire をきちんと設定してほしい」と依頼する場合 - 「できるだけ多くのデータを送信してほしい」と要望される場合 - Logfire について言及されるものの、具体的な範囲が不明な場合 - アプリケーションコードの計測、インフラの監視、AI の動作評価といった複数の領域にまたがる場合 ただし、ユーザーの要望が「計測」「監視」「評価」のいずれか１つに明確に限定されている場合は、このスキルではなく、その特定領域のスキルを直接取得してください。このスキルは内容の重複を避け、適切なスキルへ誘導する役割に専念します。
Entry point for Pydantic Logfire — an observability, monitoring, and evals platform. Use this skill when the user asks to "set up Logfire", "add Logfire to my project", "get me set up properly with Logfire", "send as much data as would be useful", mentions Logfire without a specific scope, or their request spans more than one of instrumenting application code / monitoring infrastructure / evaluating AI behavior. If the request is clearly scoped to exactly one of those, fetch that specific skill directly instead of this one — this skill exists to route, not to duplicate their content.
Logfire は OpenTelemetry（監視用の技術標準）上に構築された観測プラットフォームであり、いくつかの異なる機能領域を持っています。このスキルは認証、案内、ルーティングを行い、実際に必要な機能領域向けの専門スキルへ導きます。インストール・設定・確認の詳細な手順はこのファイル内では扱いません。
短い進捗報告で利用者に情報を与えながらも、通常の可逆的なセットアップ手順（戻せる変更）は承認を得ずに進めてください。確認作業、スコア報告、実行結果の検証は必要ありません。一時停止する場面は以下に限ります：ブラウザでの認証、検査後に判断が難しいアプリ・プロジェクト、本番環境の監視データやコストの大幅な増加、デプロイ・インフラの変更、破壊的または関連のない作業。その場合は具体的な質問を1つだけ出してください。確認のない状態で、チェック結果、スコア、実行状況を「完了」と報告してはいけません。
認証を最初に行う必要があります。その後の全ての作業が、正しい Logfire プロジェクトへの有効で確認済みの接続に依存しているためです。接続が間違ったプロジェクトだった場合、リポジトリのセットアップは無駄になるか、最悪の場合、意図しないプロジェクトに黙って接続されてしまいます。whoami コマンドで正しいプロジェクトへの認証が確認されるまで、プロジェクトファイルを開く、読む、実行しないでください。この段階ではまだリポジトリの内容を知る必要がありません。
プロジェクト認証と選択のリファレンス を使って、提供された Logfire URL から CLI ターゲットを導出し、確認済みの CLI パスで whoami チェックを実行してください。uv のない JavaScript/TypeScript プロジェクトの場合は、リポジトリ内の実行可能ファイルが誤って実行される可能性があるため、plain npx ではなく npm の外部プレフィックス機能を使用してください。そのコマンドが既に正しいプロジェクトと --region または --base-url のターゲット設定を返していればステップ2へ進みます。そうでない場合は、そのリファレンスで認証とプロジェクト選択の全手順を完了してください。
AGENTS.md、CLAUDE.md、README.md を読んで、プログラミング言語、実行環境、パッケージマネージャーを把握します。その後、以下の表と照らし合わせて、次に何を準備するか判断してください：
| 機能領域 | 対象 | スキル |
|---|---|---|
| アプリケーション計測 | アプリケーションコードからのトレース、ログ、メトリクス、AI・エージェントのスパン — Python、JavaScript/TypeScript、Rust、またはその他の OpenTelemetry 対応言語 | logfire-instrumentation |
| インフラ監視 | ホスト、Docker、Kubernetes、データベース・キュー・キャッシュサーバー、クラウドプロバイダーのメトリクス — アプリケーションコードは対象外 | logfire-infrastructure |
| 評価 | Python または Node.js での AI・エージェント評価の設定と実行（テストケースデータセット対象） | logfire-evals |
| テレメトリ照会 | トレース・ログ・スパン・メトリクスの検索、エラーの集約、根本原因の特定 | logfire-query |
| ライブUI | プロジェクトページ、ライブビュー、トレースリンク、Explore ページをブラウザで開く | logfire-ui |
| 機能フラグ | 実行時に管理される変数（logfire.var()、logfire.template_var()） |
専用スキルなし — 製品の公式ドキュメントを参照 |
| AI ゲートウェイ | モデル呼び出しの利用額上限、フェイルオーバー、ルーティング（logfire gateway） |
専用スキルなし — 製品の公式ドキュメントを参照 |
特定のスコープがない場合（例：「このリポジトリに Logfire を一通りセットアップ」）、通常のアプリケーションコードは logfire-instrumentation を最初に使います。Docker、Kubernetes、インフラ、評価関連のファイルが付属していても、初期セットアップの対象範囲は拡げません。まず1つの代表的なアプリケーションサービスを確認済みの初データまで進め、その後、追加の適合スキルを提案します。リポジトリが明らかにインフラのみの場合は、logfire-infrastructure に直接ルーティングしてください。
既にスコープが定まっている場合（「Postgres サーバーを監視したい」「このエージェント用に評価をセットアップ」）→ 表の照合をスキップし、そのスキルを直接準備してください。
隣同士の機能領域の間で判断が難しい場合（例：「Postgres を見張りたい」は Collector レベルのインフラメトリクスか、アプリレベルの照会計測か）→ 推測せず、1つの確認質問を出してください。間違ったスキルを読み込むと、利用者が求めていない仕事の説明文を読む時間が無駄になります。
ステップ2で判定したスキルを今から準備してください。インストール・計測・確認の実際の手順はそこに含まれます。各スキルには独自の認証ステップがあり、最初に whoami チェックを実行します。これにより、ここで解決したのと同じプロジェクトとリージョンであることが確認されます（引き継ぎではなく確認です）。その後、認証コマンドの残りはスキップされます。各スキルは独立して準備できるように設計されているため、このハブを通じてか、単独で準備されるかに関わらず構成は機能します。
これらのスキル内のどの段階でも、トークン、ログ、ハードコード、コミット、または画面出力をしてはいけません。唯一の例外は、.logfire/logfire_credentials.json の token キーをプログラムで読み取り、ネイティブ SDK に対応していないアプリケーションに書き込みトークンを渡す場合です。この場合も表示してはいけません。詳細は auth.md を参照してください。
Logfire is an observability platform built on OpenTelemetry, with several distinct product surfaces. This skill authenticates, orients, and routes you to the specific skill for the surface you actually need — don't try to cover install/instrument/verify detail from within this file.
Keep the user informed with short updates, but proceed through ordinary, reversible setup without asking approval — no clean tree, branch, commits, or plan needed, and no commands the user could run only because you chose not to. Pause only for: browser auth, a genuinely ambiguous app/project after inspection, materially increasing production telemetry or cost, deploy/infra changes, or destructive/unrelated work — then ask one concrete question. Never report a check, a score, or a run as verified without having actually confirmed it in this session.
Auth comes first because everything after it depends on having a valid, confirmed connection to the exact right Logfire project: instrumenting or inspecting the repo before that is either wasted if the connection turns out wrong, or worse, ends up silently wired to the wrong project. Do not open, read, or run any project file until whoami confirms you're authenticated to the right project — nothing about this step requires knowing what's in the repo yet.
Use Authenticate and Select the Exact Project to derive the CLI target from the supplied Logfire URL and run its target-aware whoami check with a verified CLI path — for JS/TS projects without uv, use the external-prefix npm fallback instead of plain npx, which can execute a repository-local binary. Skip to Step 2 if that already reports the right project and resolved --region or --base-url target; otherwise, continue through the full authentication and project-selection sequence there.
Read AGENTS.md/CLAUDE.md/README.md and skim the language, runtime, and package manager. Then match what you find against the table below to decide what to fetch next:
| Surface | Covers | Skill |
|---|---|---|
| App instrumentation | Traces, logs, metrics, and AI/agent spans from application code — Python, JavaScript/TypeScript, Rust, or any OpenTelemetry language | logfire-instrumentation |
| Infrastructure monitoring | Hosts, Docker, Kubernetes, database/queue/cache servers, cloud-provider metrics — no application code | logfire-infrastructure |
| Evals | Set up and run AI/agent evaluations against test-case datasets in Python or Node.js | logfire-evals |
| Querying telemetry | Search traces/logs/spans/metrics, summarize errors, find root cause | logfire-query |
| Live UI | Open project pages, the live view, trace links, or the Explore page in a browser | logfire-ui |
| Feature flags | Runtime-managed variables (logfire.var(), logfire.template_var()) |
no dedicated skill yet — see the product's own docs |
| AI Gateway | Spend caps, failover, and routing for model calls (logfire gateway) |
no dedicated skill yet — see the product's own docs |
logfire-instrumentation for ordinary application code. Incidental Docker, Kubernetes, infrastructure, or eval files do not expand the initial setup: get one representative application service to verified first data, then offer the matching additional skill(s). If the repository is clearly infrastructure-only, route directly to logfire-infrastructure instead.Fetch the skill(s) identified in Step 2 now, for the actual install/instrument/verify steps. Each one's own authenticate step still runs its own whoami check first — that's what confirms it's the same project and region resolved here, not an assumption carried over — and only then skips the rest of its auth commands. They're independently fetchable on purpose, so this composes whether someone reaches a specific skill through this hub or on its own.
Never print, log, hard-code, commit, or echo a token, in any of these skills, at any point. The one exception — reading .logfire/logfire_credentials.json's token key programmatically to hand a non-native-SDK application its write token, never to display it — is in auth.md.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。