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 コマンドで正しいプロジェクトへの認証が確認されるまで、プロジェクトのファイルは開かないでください。
まず確認を行ってください：uvx logfire --non-interactive whoami（JavaScript の場合：npx logfire whoami）。すでに正しいプロジェクトとリージョン（地域）が表示されていれば、Step 2 に進んでください。そうでなければ、完全なコマンド、オプション、注意点（--non-interactive の必須性、auth がブラウザを開かない理由、LOGFIRE_TOKEN と認証情報ファイルの競合、トークンファイルのセキュリティ）の詳細については、認証と正確なプロジェクトの選択 をご覧ください。
AGENTS.md、CLAUDE.md、README.md を読み、プログラミング言語、実行環境、パッケージマネージャーをざっと確認します。その後、下の表に照らし合わせて、次にどのスキルを利用すべきか判断してください：
| 機能 | 対象範囲 | スキル |
|---|---|---|
| アプリケーション計測 | アプリケーションコードからのトレース・ログ・メトリクス・AI/エージェントのスパン — Python、JavaScript/TypeScript、Rust、またはその他の OpenTelemetry 対応言語 | logfire-instrumentation |
| インフラストラクチャ監視 | ホスト、Docker、Kubernetes、データベース/キュー/キャッシュサーバー、クラウドプロバイダーのメトリクス — アプリケーションコード不要 | logfire-infrastructure |
| 評価（評価基準データセットに対する AI/エージェント出力の自動採点） | pydantic_evals を使用した採点 |
logfire-evals |
| テレメトリーの検索・分析 | トレース・ログ・スパン・メトリクスの検索、エラーの要約、原因の追跡 | logfire-query |
| ライブ UI | プロジェクトページ、ライブビュー、トレースリンク、探索ページをブラウザで開く | logfire-ui |
| 機能フラグ | 実行時に管理される変数（logfire.var()、logfire.template_var()） |
専用スキルなし — 本体のドキュメントを参照 |
| AI ゲートウェイ | モデル呼び出しの使用上限・フェイルオーバー・ルーティング（logfire gateway） |
専用スキルなし — 本体のドキュメントを参照 |
logfire-instrumentation を既定値として使用します。Docker、Kubernetes、インフラストラクチャ、または評価ファイルが付随していても、初期セットアップの範囲は広げません。まず 1 つの代表的なアプリケーションサービスから実際のデータが流れるまで確認し、その後に合致する追加スキルを提案します。リポジトリが明らかにインフラストラクチャのみの場合は、代わりに logfire-infrastructure に直接案内します。Step 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.
Check first — uvx logfire --non-interactive whoami (JS: npx logfire whoami) — and skip to Step 2 if it already reports the right project and region. Otherwise, full command sequence, flags, and gotchas (the --non-interactive requirement, why auth won't open a browser for you, the LOGFIRE_TOKEN-vs-credentials-file conflict, token-file safety): Authenticate and Select the Exact Project.
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 | Score AI/agent output against test-case datasets with pydantic_evals |
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 による自動翻訳です。