chore: sync skills from upstream

[github-actions]

Automated sync of skill content from upstream source repositories.

Upstream sources

• logfire-setup: pydantic/logfire@ffffe8c (logfire/.agents/skills/logfire-setup)
• logfire-instrumentation: pydantic/logfire@ffffe8c (logfire/.agents/skills/logfire-instrumentation)
• logfire-infrastructure: pydantic/logfire@ffffe8c (logfire/.agents/skills/logfire-infrastructure)
• logfire-evals: pydantic/logfire@ffffe8c (logfire/.agents/skills/logfire-evals)
• building-pydantic-ai-agents: pydantic/pydantic-ai@716f2ae (pydantic_ai_slim/pydantic_ai/.agents/skills/building-pydantic-ai-agents)
• pydantic-ai-harness: pydantic/pydantic-ai-harness@c897c4e (pydantic_ai_harness/.agents/skills/pydantic-ai-harness)
• pydantic: pydantic/pydantic@2261ae1 (.agents/skills/pydantic)

Review the diff against the listed upstream commits before merging.

[adtyavrdhn]

CC @DouweM

Could you have a look to make sure the skills are valid? I'll hold off on this meanwhile

[macroscopeapp]

🟡 Medium references/auth.md:19

The executable authentication sequence always targets the EU region, so following it for a US project authenticates against the wrong region and prevents subsequent project selection from finding the intended project. Use the region determined above instead of hard-coding eu.

Suggested change

	uvx logfire --non-interactive --region eu auth
	uvx logfire --non-interactive --region <region> auth

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/logfire/skills/logfire-instrumentation/references/auth.md around line 19:

The executable authentication sequence always targets the EU region, so following it for a US project authenticates against the wrong region and prevents subsequent project selection from finding the intended project. Use the region determined above instead of hard-coding `eu`.

[macroscopeapp]

🟠 High logfire-instrumentation/SKILL.md:54

Copying this Python snippet verbatim raises NameError for app, so the application is never instrumented. Include the app creation in the example (or explicitly state that app must already exist).

- import logfire
+ from fastapi import FastAPI
+ import logfire
+
+ app = FastAPI()

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/logfire/skills/logfire-instrumentation/SKILL.md around line 54:

Copying this Python snippet verbatim raises `NameError` for `app`, so the application is never instrumented. Include the app creation in the example (or explicitly state that `app` must already exist).

Evidence trail:
plugins/logfire/skills/logfire-instrumentation/SKILL.md:54-62 at commit 1cc5a72. The snippet calls `logfire.instrument_fastapi(app)` without any preceding definition of `app`.

[macroscopeapp]

🟡 Medium logfire-instrumentation/SKILL.md:201

The final report instruction mislabels AI/LLM and agent-framework coverage as Step 4, even though that work belongs to Step 3; following it produces a misleading report and omits the actual Step 4 service-metadata/metrics coverage. Update the instruction to distinguish Steps 3 and 4.

Suggested change

Close with a final report built from real values you just confirmed, not a template — org, project, and region from `whoami`; the service name(s) actually seen; what Step 4 covered (AI/LLM content level, agent framework if any); and, if you ran Step 3's optional `logfire run --summary`, what it detected. **Include the project's URL** (from `whoami` or `projects status`) as a direct link to the Live view, so the user can see their own traces arrive without having to ask where to look. A report with a placeholder in it means a step above was skipped, not finished.

Close with a final report built from real values you just confirmed, not a template — org, project, and region from `whoami`; the service name(s) actually seen; what Steps 3-4 covered (AI/LLM content level, agent framework if any, and service metadata/metrics); and, if you ran Step 3's optional `logfire run --summary`, what it detected. **Include the project's URL** (from `whoami` or `projects status`) as a direct link to the Live view, so the user can see their own traces arrive without having to ask where to look. A report with a placeholder in it means a step above was skipped, not finished.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/logfire/skills/logfire-instrumentation/SKILL.md around line 201:

The final report instruction mislabels AI/LLM and agent-framework coverage as Step 4, even though that work belongs to Step 3; following it produces a misleading report and omits the actual Step 4 service-metadata/metrics coverage. Update the instruction to distinguish Steps 3 and 4.

[macroscopeapp]

🟠 High logfire-instrumentation/SKILL.md:186

Step 5 always fails before auditing telemetry because the synced CLI has no projects status subcommand or --json option, and the fallback also fails because read-tokens ... create does not accept --save. These commands therefore produce argparse errors and cannot save a read token as the instructions promise; update the flow to use commands and flags supported by the synced CLI.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/logfire/skills/logfire-instrumentation/SKILL.md around line 186:

Step 5 always fails before auditing telemetry because the synced CLI has no `projects status` subcommand or `--json` option, and the fallback also fails because `read-tokens ... create` does not accept `--save`. These commands therefore produce argparse errors and cannot save a read token as the instructions promise; update the flow to use commands and flags supported by the synced CLI.

[macroscopeapp]

🟠 High references/ORCHESTRATION-AND-INTEGRATIONS.md:91

Custom AbstractToolset leaves do not raise the documented UserError; they pass the durability runtime guard and execute unwrapped, so side-effecting tools can run uncheckpointed and repeat writes or other external actions during workflow replay. The guard only recognizes FunctionToolset, MCPToolset, and DynamicToolset, so narrow this guidance to the recognized toolset types and explicitly document the custom-leaf behavior (or fix the guard).

-Pass every executing toolset that needs durable wrapping to the agent constructor. In particular, construct a `DynamicToolset` with an explicit `id` and pass it to `Agent(toolsets=[...])`; the `@agent.toolset` decorator registers after the engine's durable units were created. Toolsets that arrive later — via the decorator, `run(toolsets=...)`, `override(toolsets=...)`, or a per-run capability — are never wrapped for durable execution: under the `*Durability` capability, using one inside a workflow or flow raises a `UserError` (DBOS still accepts a `FunctionToolset`, whose tools it runs inline either way). The deprecated wrapper agents don't run this check — inside a workflow or flow they run the toolset list frozen at wrap time, so a toolset registered that late is silently left out. A toolset added at run time also cannot reuse a construction-time toolset's `id`.
+Pass every executing toolset that needs durable wrapping to the agent constructor. In particular, construct a `DynamicToolset` with an explicit `id` and pass it to `Agent(toolsets=[...])`; the `@agent.toolset` decorator registers after the engine's durable units were created. Toolsets that arrive later — via the decorator, `run(toolsets=...)`, `override(toolsets=...)`, or a per-run capability — are never wrapped for durable execution: under the `*Durability` capability, using a `MCPToolset` or `DynamicToolset` inside a workflow or flow raises a `UserError` (DBOS still accepts a `FunctionToolset`, whose tools it runs inline either way). Custom `AbstractToolset` leaves are not recognized by this guard and execute unwrapped. The deprecated wrapper agents don't run this check — inside a workflow or flow they run the toolset list frozen at wrap time, so a toolset registered that late is silently left out. A toolset added at run time also cannot reuse a construction-time toolset's `id`.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/ai/skills/building-pydantic-ai-agents/references/ORCHESTRATION-AND-INTEGRATIONS.md around line 91:

Custom `AbstractToolset` leaves do not raise the documented `UserError`; they pass the durability runtime guard and execute unwrapped, so side-effecting tools can run uncheckpointed and repeat writes or other external actions during workflow replay. The guard only recognizes `FunctionToolset`, `MCPToolset`, and `DynamicToolset`, so narrow this guidance to the recognized toolset types and explicitly document the custom-leaf behavior (or fix the guard).

[adtyavrdhn]

Confirmed. Fixed upstream in pydantic/pydantic-ai#8086 by documenting the exact recognized runtime toolset types and warning that custom executing AbstractToolset leaves run unwrapped. Leaving this thread open until that PR merges and the autosync updates this line.

[macroscopeapp]

Thanks for confirming. The current autosync has not incorporated that upstream wording yet. Would you like me to prepare the equivalent update here, or wait for the autosync?

[macroscopeapp]

🟠 High building-pydantic-ai-agents/SKILL.md:270

The example waits indefinitely when input transcription is disabled or fails, because no user SpeechPart end event arrives even after RealtimeTurnCompleteEvent; the still-open session therefore never exits at the documented turn boundary. Break on RealtimeTurnCompleteEvent alone instead of requiring user_turn_complete.

Suggested change

	if turn_complete and user_turn_complete:
	if turn_complete:

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @plugins/ai/skills/building-pydantic-ai-agents/SKILL.md around line 270:

The example waits indefinitely when input transcription is disabled or fails, because no user `SpeechPart` end event arrives even after `RealtimeTurnCompleteEvent`; the still-open session therefore never exits at the documented turn boundary. Break on `RealtimeTurnCompleteEvent` alone instead of requiring `user_turn_complete`.

[adtyavrdhn]

Confirmed. Fixed upstream in pydantic/pydantic-ai#8086 by breaking directly on RealtimeTurnCompleteEvent, without requiring a user transcription event that may be late or absent. Leaving this thread open until that PR merges and the autosync updates this example.

[macroscopeapp]

Thanks for confirming. The current sync still has the affected condition. Would you like me to prepare the same fix here, or should we wait for the upstream autosync?

[macroscopeapp]

Macroscope skipped reviewing this pull request. Per-PR cost limit exceeded (workspace setting).

Reviews on this PR have cost $26.97 so far. This review would add an estimated $4.41, bringing the total to $31.38 — above your per-PR limit of $30.00.

Tip

To get this pull request reviewed, you can:

1. Comment @macroscope-app on this PR to request a manual review (monthly spend limits still apply).
2. Exclude large or generated files from review by adding a pattern to your .macroscope/ignore.md — note that creating this file replaces Macroscope's built-in default ignores rather than extending them.
3. Raise your cost limit in your workspace billing settings.

^{Turn off this reminder going forward}