Pydantic AI is a typed Python SDK for building AI agents that can use different language models and interfaces, including voice, image generation, and embeddings. Developers use it for applications ranging from structured data extraction to long-running multi-agent work. The catalogue entries provide workflows and configuration for its coding-agent and harness features.
Borrowing it
Nothing to install: this file belongs to pydantic/pydantic-ai. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/pydantic/pydantic-ai/main/.agents/skills/poweruser-feature-audit/SKILL.mdgit clone --depth 1 https://github.com/pydantic/pydantic-aiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pydantic/pydantic-ai/poweruser-feature-audit)<a href="https://agentmods.dev/skills/pydantic/pydantic-ai/poweruser-feature-audit"><img src="https://agentmods.dev/badge/skills/pydantic/pydantic-ai/poweruser-feature-audit/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pydantic/pydantic-ai/poweruser-feature-audit"><img src="https://agentmods.dev/badge/skills/pydantic/pydantic-ai/poweruser-feature-audit.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00100 | $0.02461 |
| Opus 5 | $0.00050 | $0.01230 |
| Sonnet 5 | $0.00020 | $0.00492 |
| Haiku 4.5 | $0.00010 | $0.00246 |
Grade A, and why
poweruser-feature-audit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 130 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Power-User Feature Audit
Audit a large new-feature PR the way a demanding production user would encounter the feature: by first learning what the underlying APIs, protocols, and real-world integrators require, and only then checking whether the implementation lives up to that. The output is a set of review items for the PR author, each backed by evidence and precedent.
The core discipline is ordering. If you read the implementation first, it anchors your expectations and you end up reviewing the code against itself. So the knowledge base is built entirely from external sources, the ideal test suite is designed from that knowledge base, and only then is the PR opened and compared against it. Gaps between the ideal and the actual are the findings.
When To Use
- A big feature PR lands (realtime/voice APIs, image generation, a new provider protocol, a new subsystem) and you want an independent assessment, not a line-by-line review.
- The feature wraps an external API or protocol whose semantics, edge cases, and operational pitfalls are documented outside this repo.
- You want to know whether the implementation would satisfy a power user pushing it hard in production, and where technical users would need trade-off flexibility.
Not for general code review of a diff (use /review-branch if available), and not for completing a narrow fix (use complete-partial-pr). This skill deliberately ignores code style, naming, and diff mechanics — its lens is behavioral completeness and operational robustness.
Operating Principles
- Bias ordering is a hard gate. No reading of the PR diff, the implementation, or its tests until the ideal test-suite design is written (phase 4). Only the scoping subagent reads the PR before that, and it returns scope facts, never approach.
- Every phase persists its artifacts under
local-notes/<feature>-audit/. Each phase must be independently valuable and resumable: a single session often completes only scoping + research, and a later session (or a different agent) picks up from the files. - Sources or it didn't happen. Every research claim carries a specific source link. Findings without sources cannot become review items.
- Independently verify before anything is author-facing. The driving agent re-verifies every load-bearing subagent claim against the PR's current HEAD itself. Subagents propose; the driver confirms.
- Nothing posts without the user. The skill ends at drafted review items. Posting is a separate, human-gated step, usually in a later session.
- Delegate token-heavy writing. Research documents, gap tables, and comment drafts are written by subagents; the driver writes the prompts and specs, reads the results, and synthesizes.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 130 lines · 100 tokens per session scan A c8022b205a94
poweruser-feature-audit is a skill published in the GitHub repository pydantic/pydantic-ai (19,845 stars, last pushed today), licensed MIT. It adds 100 tokens to every session and 2,461 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
review-prs
Review a GitHub pull request in the googleapis/mcp-toolbox repo against the team's reviewer checklist: PR title/description conventions, linked issue, logic errors and unhandled edge cases, breaking changes, test coverage, docs updates, security (input handling), and new dependencies. Use whenever a maintainer asks…
test-generator
Generate pytest test cases for Python functions and classes.
qa-review
QA review for code changes — test coverage analysis, edge case identification, test plan generation, regression detection, test health tracking over time.
fable-judge
Adversarial verification of finished work. Treats any 'done' claim as a set of claims to verify by re-running everything yourself. Use when someone reports work complete and you must gate it: load this before trusting a completion report. Subcommands: suite runs a trap suite against any skill/model.
Pair Programming
AI-assisted pair programming with multiple modes (driver$navigator$switch), real-time verification, quality monitoring, and comprehensive testing. Supports TDD, debugging, refactoring, and learning sessions. Features automatic role switching, continuous code review, security scanning, and performance optimization with…
python-testing
Python testing best practices using pytest including fixtures, parametrization, mocking, coverage analysis, async testing, and test organization. Use when writing or improving Python tests.