Pipecat is an open-source Python framework for building real-time conversational agents that work with voice, video, images, and other media. It is for creating voice assistants, companions, business agents, and multi-agent systems from modular conversation pipelines.
Borrowing it
Nothing to install: this file belongs to pipecat-ai/pipecat. 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/pipecat-ai/pipecat/main/.claude/skills/pr-description/SKILL.mdgit clone --depth 1 https://github.com/pipecat-ai/pipecatWrote 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/pipecat-ai/pipecat/pr-description)<a href="https://agentmods.dev/skills/pipecat-ai/pipecat/pr-description"><img src="https://agentmods.dev/badge/skills/pipecat-ai/pipecat/pr-description/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/pipecat-ai/pipecat/pr-description"><img src="https://agentmods.dev/badge/skills/pipecat-ai/pipecat/pr-description.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.00026 | $0.01698 |
| Opus 5.5 | $0.00010 | $0.00679 |
| Sonnet 5.5 | $0.00005 | $0.00340 |
| Haiku 4.5 | $0.00003 | $0.00170 |
Grade A, and why
pr-description 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 1mo 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 — 177 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write a pull request description for a reviewer who knows the project but hasn't read the issue, the diff, or the development conversation. Establish why the change exists before explaining how it works.
If the user asks for a draft, return the text without updating GitHub. Otherwise, update the requested PR description.
Arguments
/pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]
PR_NUMBER(required): The pull request to describe.--fixes(optional): Comma-separated issue numbers this PR fixes, such as123,456.
Examples:
/pr-description 3534/pr-description 3534 --fixes 123,456
Instructions
-
Gather the change:
- Read the PR title, current description, base branch, and head branch.
- Read the PR commits and diff. Use the PR's actual base and head; don't assume
the current checkout is the PR branch or that its base is
main. - Read relevant issue details, code comments, and available conversation context to understand the problem and the reasons for the change.
- Collect issue numbers from
--fixesand explicit closing references in commit messages. Don't infer that a related issue should be closed.
-
Check the existing description. If it's already accurate, understandable without outside context, and consistent with this format, leave it alone. Otherwise, rewrite it around the final implementation rather than appending updates.
-
Establish the core explanation before choosing bullets:
- What does the affected component do?
- What limitation or need prompted this change?
- What will it do differently? Use only the context needed to understand this PR. Don't invent a problem to justify a feature or refactor.
-
Choose the distinct concerns a reviewer needs to assess. Usually these become 3 to 6 labeled bullets; use fewer for a small change. Group by behavior or system responsibility, not by file, helper function, or implementation step.
-
Read the draft without consulting the diff. If the purpose or behavior is still unclear, supply the missing context before adding more implementation detail.
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.
- 1mo ago Changed · +47 lines · +12 tokens per session 9516da775f35
- 1mo ago First seen · 130 lines · 14 tokens per session scan A 16355f5387e2
pr-description is a skill published in the GitHub repository pipecat-ai/pipecat (16,618 stars, last pushed today), licensed BSD-2-Clause. It adds 26 tokens to every session and 1,698 once invoked, about $0.0001 per session on Opus 5.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
understand-pr
Review a PR the way a seasoned maintainer would — build an independent model before seeing the diff, investigate the implementation and history, verify material claims, and return a concise briefing. Use for any PR review, self-review, or re-review.
herdr-kit-workflows
Set up and operate Herdr Kit safely: install and configure the plugin and Mastra Code integration, manage Review and Work repository scope, open primary repository workspaces, synchronize managers, materialize or dematerialize managed worktrees, and update Herdr Kit settings or shortcuts.
factory-gitlab-review
Review a GitLab merge request for a Factory work item using brokered source-control tools.
factory-gitlab-rereview
Re-review a GitLab merge request after new commits and reconcile the previous review.
triage-issue
First-contact triage for a GitHub issue.
herdr-manager-query
Query the authoritative global Herdr Review and Work Manager inventory, recommend actionable PR work, and explicitly materialize confirmed remote-only Review Manager records through the plugin's stable public CLI.