pydantic/logfire/logfire-setup

Set Up Logfire

Route each explicitly requested surface to its specialist below; leave installation and verification to those specialists. Do not expand an otherwise scoped request.

Proceed through ordinary, reversible setup with short updates without asking approval; no clean tree, branch, commits, or plan is required. Pause for browser auth, unresolved app/project ambiguity, material production cost or telemetry increases, deploy/infra changes, or destructive/unrelated work, then ask one concrete question. Report only verification observed in this session.

Step 1: Authenticate and Select the Exact Project

If the request is already scoped to frontend observability, application Gateway, coding-agent setup, querying, or opening the UI, load that specialist from the table below first. Its credential requirements differ from ordinary SDK instrumentation; do not create a project write token merely to route the request.

For ordinary SDK instrumentation, confirm the exact project with whoami before inspecting or running application files.

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.

Step 2: Understand the Repo

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:

• With no specific scope, get one representative application service to verified first data. Incidental Docker/eval files do not expand the task. Route infrastructure-only repositories to logfire-infrastructure.
• A request already scoped to one surface ("monitor my Postgres server", "set up evals for this agent") → fetch that skill directly, skipping the rest of this table.
• Genuinely ambiguous between two adjacent surfaces (e.g. "watch my Postgres" could mean Collector-level infrastructure metrics or app-level query instrumentation)? Ask one clarifying question rather than guessing — loading the wrong skill wastes the user's time reading instructions for a job they didn't ask for.

Step 3: Fetch the Right Skill(s)

Load the selected skill and follow its credential workflow. SDK specialists verify the project with whoami; CLI specialists preserve prepared handoffs, and query/UI skills can use existing native MCP access. Do not force one authentication method across all surfaces.

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.