Logfire Agent Rules

An open-source Python SDK for the Logfire observability platform, built on OpenTelemetry.

Overview

Logfire's CLAUDE.md covers the open-source SDK and docs, not the closed-source service. It calls for realistic telemetry tests, points documentation work to the right files, and checks CI or review findings against the repository's actual configuration.

Verification by change type Behavioral framing Pointing at the source of truth

Documents

├── 
├──  · symlink → CLAUDE.md
├── dev-docs
│   └── 
└── docs
    └── integrations
        └── agent-frameworks
            └──

Techniques in this file

01 / Verification by change type

Find the real enforcement point

Coverage has a 100% CI gate even though the local report configuration does not set a failure threshold. The guide names the workflow step to prevent a successful local command from being mistaken for proof.

111Coverage must be 100%. The bar is the `uv run coverage report --fail-under 100` step of the `coverage` job in [`.github/workflows/main.yml`](.github/workflows/main.yml), not `pyproject.toml` — `[tool.coverage.report]` sets no `fail_under`, so reading `pyproject.toml` suggests there is no bar and a plain `coverage report` exits 0 on a regression.

02 / Verification by change type

Explain why matrix-wide coverage differs from local coverage

CI combines observations across test jobs, so a branch missed on one machine may be exercised elsewhere. The file prefers targeted local investigation and lets the combined CI result define complete coverage.

113Let CI measure it rather than running the suite under coverage locally: CI combines coverage across the whole test matrix, so a line reached only by another matrix job looks missed on one machine, and a local number is both slow to get and misleading. When the `coverage` job fails it names the file and the missing lines and branches; cover those and push again. Reach for a local run only to check a specific file you are iterating on, with `uv run coverage run -m pytest <the relevant tests>` followed by `uv run coverage report --include='*/<file>.py'`.

03 / Behavioral framing

Preserve intentional warnings in production

Warnings-as-errors should be addressed in tests when the warning is deliberate. The file tells agents to expect or narrowly filter the warning instead of removing a useful user-facing signal.

91Emitting a warning is safe even though the test suite converts warnings to errors. When a warning is intentional, update affected tests to expect it or narrow their warning filters instead of suppressing the warning in production code. Suppress a warning at a call site only when it would be a known duplicate or is intentionally irrelevant there.

04 / Behavioral framing

Verify a review finding against active rules

The review section gives a concrete example of a generally valid Ruff concern that does not apply because the rule is disabled here. It asks agents to inspect governing configuration before accepting or dismissing feedback.

135A reviewer can be right about Python in general and wrong about this repository. For example, a reviewer may report a Ruff `S106` violation (hardcoded password passed as an argument). `[tool.ruff.lint]` in `pyproject.toml` selects `E4`, `E7`, `E9` and `F`, plus an `extend-select` list that does not contain `S`, and `uv run ruff check --select S106` reports many pre-existing hits. The rule is not enabled, so there is nothing to fix. Check the configuration that governs a finding before you accept it.

05 / Pointing at the source of truth

Separate source-relative links from published routes

The docs workflow uses a navigation manifest to define public routes. It requires source-relative links and rendered preview checks, avoiding deployment prefixes that would be wrong in repository source.

20checkout. Verify the page and any anchor in a rendered preview, and never include the21deployment-specific `/docs` prefix in source links.

Ideas for your repo

Point to the command that actually enforces a quality gate.
Explain when a combined CI metric cannot be reproduced on one machine.
Handle expected warnings in tests without hiding them in production.
Check review claims against enabled rules and local configuration.
Distinguish documentation source paths from published URLs.