USP

Unlike other frameworks, Pipecat is explicitly voice-first, offering ultra-low latency real-time interaction with pluggable AI services and composable pipelines for complex agent behaviors.

Use cases

• 01Build natural, streaming voice assistants
• 02Create AI companions like coaches or meeting assistants
• 03Develop multimodal interfaces with voice, video, and images
• 04Design interactive storytelling tools with generative media
• 05Implement business agents for customer intake or support

Detected files (8)

• .claude/skills/pr-description/SKILL.mdskill
  Show content (3784 bytes)

  ---
  name: pr-description
  description: Update a GitHub PR description with a summary of changes
  ---
  
  Update a GitHub pull request description based on the changes in the PR.
  
  ## Arguments
  
  ```
  /pr-description <PR_NUMBER> [--fixes <ISSUE_NUMBERS>]
  ```
  
  - `PR_NUMBER` (required): The pull request number to update
  - `--fixes` (optional): Comma-separated issue numbers that this PR fixes (e.g., `--fixes 123,456`)
  
  Examples:
  - `/pr-description 3534`
  - `/pr-description 3534 --fixes 123`
  - `/pr-description 3534 --fixes 123,456,789`
  
  ## Instructions
  
  1. First, gather information about the PR:
     - Use GitHub plugin to get PR details (title, current description, base branch)
     - Use local git to get commits: `git log main..HEAD --oneline`
     - Use local git to get the diff: `git diff main..HEAD`
     - Parse any `--fixes` argument for issue numbers
  
  2. Check the existing PR description:
     - If it already has a complete, accurate description that reflects the changes, do nothing
     - If it's missing sections, incomplete, or outdated compared to the actual changes, proceed to update
     - If it only has the template placeholder text, generate a full description
  
  3. Analyze the changes:
     - Understand the purpose of each commit
     - Identify any breaking changes (API changes, removed features, behavior changes)
     - Look for new features, bug fixes, refactoring, or documentation changes
     - Collect issue numbers from:
       - The `--fixes` argument (if provided)
       - Commit messages (patterns like "Fixes #123", "Closes #456", "Resolves #789")
  
  4. Generate or update the PR description with these sections:
  
  ## PR Description Format
  
  ### Summary (always include)
  
  Brief bullet points describing what changed and why. Focus on the *purpose* and *impact*, not implementation details.
  
  ```markdown
  ## Summary
  
  - Added X to enable Y
  - Fixed bug where Z would happen
  - Refactored W for better maintainability
  ```
  
  ### Breaking Changes (include only if applicable)
  
  Document any changes that affect existing users or APIs.
  
  ```markdown
  ## Breaking Changes
  
  - `ClassName.method()` now requires a `param` argument
  - Removed deprecated `old_function()` - use `new_function()` instead
  ```
  
  ### Testing (include when non-obvious)
  
  How to verify the changes work. Skip for trivial changes.
  
  ```markdown
  ## Testing
  
  - Run `uv run pytest tests/test_feature.py` to verify the fix
  - Example usage: `uv run examples/new_feature.py`
  ```
  
  ### Fixes (include if issues are provided or found in commits)
  
  List issues this PR fixes. GitHub will automatically close these issues when the PR is merged.
  
  ```markdown
  ## Fixes
  
  - Fixes #123
  - Fixes #456
  ```
  
  Note: Use "Fixes #X" format (not "Closes" or "Resolves") for consistency. Each issue should be on its own line with "Fixes" to ensure GitHub auto-closes them.
  
  ## Guidelines
  
  - **Be concise** - Reviewers should understand the PR in 30 seconds
  - **Focus on why** - The diff shows *what* changed, explain *why*
  - **Skip empty sections** - Only include sections that have content
  - **Use bullet points** - Easier to scan than paragraphs
  - **Don't duplicate the diff** - Avoid listing every file or line changed
  
  ## Example Output
  
  ```markdown
  ## Summary
  
  - Added `/docstring` skill for documenting Python modules with Google-style docstrings
  - Skill finds classes by name and handles conflicts when multiple matches exist
  - Skips already-documented code to avoid unnecessary changes
  
  ## Testing
  
  /docstring ClassName
  
  ## Fixes
  
  - Fixes #123
  ```
  
  ## Checklist
  
  Before updating the PR:
  
  - [ ] Verified existing description needs updating (not already complete)
  - [ ] Summary accurately reflects the changes
  - [ ] Breaking changes are clearly documented (if any)
  - [ ] No unnecessary sections included
  - [ ] Description is concise and scannable
  

• .claude/skills/changelog/SKILL.mdskill
  Show content (2886 bytes)

  ---
  name: changelog
  description: Create changelog files for important commits in a PR
  ---
  
  Create changelog files for the important commits in this PR. The PR number is provided as an argument.
  
  ## Instructions
  
  1. Skip changelog for: documentation-only, internal refactoring, test-only, CI changes.
  
  2. First, check what commits are on the current branch compared to main:
     ```
     git log main..HEAD --oneline
     ```
  
  3. For each significant change, create a changelog file in the `changelog/` folder using the format:
     Allowed types: `added`, `changed`, `deprecated`, `removed`, `fixed`, `security`, `performance`, `other`
     - `{PR_NUMBER}.added.md` - for new features
     - `{PR_NUMBER}.added.2.md`, `{PR_NUMBER}.added.3.md` - for additional entries of the same type
     - `{PR_NUMBER}.changed.md` - for changes to existing functionality
     - `{PR_NUMBER}.fixed.md` - for bug fixes
     - `{PR_NUMBER}.deprecated.md` - for deprecations
     - `{PR_NUMBER}.removed.md` - for removed features
     - `{PR_NUMBER}.security.md` - for security fixes
     - `{PR_NUMBER}.performance.md` - for performance improvements
     - `{PR_NUMBER}.other.md` - for other changes
  
  4. Each changelog file should at least contain a main single line starting with `- ` followed by a clear description of the change. No line wrapping.
  
  5. If the change is complicated, changelog files can have indented lines after the main line with additional details or code samples.
  
  6. Use ⚠️ emoji prefix for breaking changes.
  
  7. **Write changes in user-facing terms first.** Lead with what users of the framework will notice: new APIs, changed behavior, new parameters, fixed bugs they might have hit, etc. Implementation details (internal refactoring, how something is wired up under the hood) can be included as secondary context after the user-facing description, but should never be the *only* content of a changelog entry when there is a user-visible effect.
  
     **Good** (user-facing first, implementation detail as context):
     ```
     - Turn completion instructions now persist correctly across full context updates when using `system_instruction`. Previously they were injected as a context system message, which caused warning spam and didn't survive context updates.
     ```
  
     **Bad** (implementation detail only, no user-facing framing):
     ```
     - Fixed turn completion instructions being injected as a context system message instead of using `system_instruction`.
     ```
  
     Ask yourself: "If I'm a developer building on Pipecat, what would I notice changed?" Start there.
  
  ## Example
  
  For PR #3519 with a new feature and a bug fix:
  
  `changelog/3519.added.md`:
  ```
  - Added `SomeNewFeature` for doing something useful.
  ```
  
  `changelog/3519.fixed.md`:
  ```
  - Fixed an issue where something was not working correctly in some user-visible scenario. The root cause was an internal implementation detail.
  ```
  

• .claude/skills/pr-submit/SKILL.mdskill
  Show content (1015 bytes)

  ---
  name: pr-submit
  description: Create and submit a GitHub PR from the current branch
  ---
  
  Submit the current changes as a GitHub pull request.
  
  ## Instructions
  
  1. Check the current state of the repository:
     - Run `git status` to see staged, unstaged, and untracked changes
     - Run `git diff` to see current changes
     - Run `git log --oneline -10` to see recent commits
  
  2. If there are uncommitted changes relevant to the PR:
     - Ask the user if they want a specific prefix for the branch name (e.g., `alice/`, `fix/`, `feat/`)
     - Create a new branch based on the current branch
     - Commit the changes using multiple commits if the changes are unrelated
  
  3. Push the branch and create the PR:
     - Push with `-u` flag to set upstream tracking
     - Create the PR using `gh pr create`
  
  4. After the PR is created:
     - Run `/changelog <pr_number>` to generate changelog files, then commit and push them
     - Run `/pr-description <pr_number>` to update the PR description
  
  5. Return the PR URL to the user.
  

• .claude/skills/cleanup/SKILL.mdskill
  Show content (7399 bytes)

  # Code Cleanup Skill
  
  The **Code Cleanup Skill** reviews, refactors, and documents code changes in your current branch, ensuring alignment with **Pipecat's architecture, coding standards, and example patterns**.
  It focuses on **readability, correctness, performance, and consistency**, while avoiding breaking changes.
  
  ---
  
  ## Skill Overview
  
  This skill analyzes all changes introduced in your branch and performs the following actions:
  
  1. **Analyze Branch Changes**
     - Review uncommitted changes and outgoing commits
  2. **Refactor for Readability**
     - Improve clarity, naming, structure, and modern Python usage
  3. **Enhance Performance**
     - Identify safe, conservative optimization opportunities
  4. **Add Documentation**
     - Apply Pipecat-style, Google-format docstrings
  5. **Ensure Pattern Consistency**
     - Match existing Pipecat services, pipelines, and examples
  6. **Validate Examples**
     - Ensure examples follow foundational patterns (e.g. `07-interruptible.py`)
  
  ---
  
  ## Usage
  
  Invoke the skill using any of the following commands:
  
  - "Clean up my branch code"
  - "Refactor the changes in my branch"
  - "Review and improve my branch code"
  - `/cleanup`
  
  ---
  
  ## What This Skill Does
  
  ### 1. Analyze Branch Changes
  
  The skill retrieves all uncommitted changes and outgoing commits to understand:
  
  - New files added
  - Modified files
  - Code additions and deletions
  - Overall scope and intent of changes
  
  ---
  
  ### 2. Code Refactoring
  
  #### Readability Improvements
  
  - Replace tuples with named classes or dataclasses
  - Improve variable, method, and class naming
  - Extract complex logic into well-named helper methods
  - Add missing type hints
  - Simplify nested or complex conditionals
  - Replace deprecated methods and features
  - Normalize formatting to match Pipecat style
  
  #### Performance Enhancements
  
  - Identify inefficient loops or repeated work
  - Suggest appropriate data structures
  - Optimize async workflows and I/O
  - Remove redundant operations
  
  > Performance changes are conservative and non-breaking.
  
  ---
  
  ### 3. Documentation
  
  Documentation follows **Google-style docstrings**, consistent with Pipecat conventions.
  
  #### Class Documentation
  
  ```python
  class ExampleService:
      """Brief one-line description.
  
      Detailed explanation of the class purpose, responsibilities,
      and important behaviors.
  
      Supported features:
  
      - Feature 1
      - Feature 2
      - Feature 3
      """
  ```
  
  #### Method Documentation
  
  ```python
  def process_data(self, data: str, options: Optional[dict] = None) -> bool:
      """Process incoming data with optional configuration.
  
      Args:
          data: The input data to process.
          options: Optional configuration dictionary.
  
      Returns:
          True if processing succeeded, False otherwise.
  
      Raises:
          ValueError: If data is empty or invalid.
      """
  ```
  
  #### Pydantic Model Parameters
  
  ```python
  class InputParams(BaseModel):
      """Configuration parameters for the service.
  
      Parameters:
          timeout: Request timeout in seconds.
          retry_count: Number of retry attempts.
          enable_logging: Whether to enable debug logging.
      """
  
      timeout: Optional[float] = None
      retry_count: int = 3
      enable_logging: bool = False
  ```
  
  ---
  
  ### 4. Pattern Consistency Checks
  
  #### Service Classes
  
  - Correct inheritance (`TTSService`, `STTService`, `LLMService`)
  - Consistent constructor signatures
  - Frame emission patterns
  - Metrics support:
    - `can_generate_metrics()`
    - TTFB metrics
    - Usage metrics
  - Alignment with similar existing services
  
  #### Examples
  
  Validated against `examples/07-interruptible.py`:
  
  - Proper `create_transport()` usage
  - Correct pipeline structure
  - Task setup and observers
  - Event handler registration
  - Runner and bot entrypoint consistency
  
  ---
  
  ### 5. Specific Implementation Patterns
  
  #### Service Implementation
  
  ```python
  class ExampleTTSService(TTSService):
  
      def __init__(self, *, api_key: Optional[str] = None, **kwargs):
          super().__init__(**kwargs)
          self._api_key = api_key or os.getenv("SERVICE_API_KEY")
  
      def can_generate_metrics(self) -> bool:
          return True
  
      async def run_tts(self, text: str) -> AsyncGenerator[Frame, None]:
          try:
              await self.start_ttfb_metrics()
              yield TTSStartedFrame()
              # ... processing ...
              yield TTSAudioRawFrame(...)
          finally:
              await self.stop_ttfb_metrics()
  ```
  
  ---
  
  #### Example Structure Pattern
  
  ```python
  transport_params = {
      "daily": lambda: DailyParams(...),
      "twilio": lambda: FastAPIWebsocketParams(...),
      "webrtc": lambda: TransportParams(...),
  }
  
  async def run_bot(transport: BaseTransport, runner_args: RunnerArguments):
      stt = DeepgramSTTService(...)
      tts = SomeTTSService(...)
      llm = OpenAILLMService(...)
  
      context = LLMContext(messages)
      user_aggregator, assistant_aggregator = LLMContextAggregatorPair(...)
  
      pipeline = Pipeline([...])
      task = PipelineTask(pipeline, params=..., observers=[...])
  
      @transport.event_handler("on_client_connected")
      async def on_client_connected(transport, client):
          await task.queue_frames([LLMRunFrame()])
  
      runner = PipelineRunner(handle_sigint=runner_args.handle_sigint)
      await runner.run(task)
  
  async def bot(runner_args: RunnerArguments):
      """Main bot entry point compatible with Pipecat Cloud."""
      transport = await create_transport(runner_args, transport_params)
      await run_bot(transport, runner_args)
  ```
  
  ---
  
  ## Execution Flow
  
  1. Fetch uncommitted and outgoing changes
  2. Categorize files (services, examples, tests, utilities)
  3. Analyze each file:
     - Readability
     - Performance
     - Documentation
     - Pattern consistency
  4. Generate actionable recommendations
  5. Apply Pipecat standards
  
  ---
  
  ## Examples
  
  ### Before: Tuple Usage
  
  ```python
  def get_audio_info(self) -> Tuple[int, int]:
      return (48000, 1)
  ```
  
  ### After: Named Class
  
  ```python
  class AudioInfo:
      """Audio configuration information.
  
      Parameters:
          sample_rate: Sample rate in Hz.
          num_channels: Number of audio channels.
      """
  
      sample_rate: int
      num_channels: int
  
  def get_audio_info(self) -> AudioInfo:
      return AudioInfo(sample_rate=48000, num_channels=1)
  ```
  
  ---
  
  ### Before: Missing Documentation
  
  ```python
  class NewTTSService(TTSService):
      def __init__(self, api_key: str, voice: str):
          self._api_key = api_key
          self._voice = voice
  ```
  
  ### After: Fully Documented
  
  ```python
  class NewTTSService(TTSService):
      """Text-to-speech service using NewProvider API.
  
      Streams PCM audio and emits TTSAudioRawFrame frames compatible
      with Pipecat transports.
  
      Supported features:
      - Text-to-speech synthesis
      - Streaming PCM audio
      - Voice customization
      - TTFB metrics
      """
  
      def __init__(self, *, api_key: str, voice: str, **kwargs):
          """Initialize the NewTTSService.
  
          Args:
              api_key: API key for authentication.
              voice: Voice identifier to use.
              **kwargs: Additional arguments passed to the parent service.
          """
          super().__init__(**kwargs)
          self._api_key = api_key
          self.set_voice(voice)
  ```
  
  ---
  
  ## Notes
  
  - Non-breaking improvements only
  - Backward compatibility preserved
  - Conservative performance changes
  - Google-style docstrings
  - Pattern checks follow recent Pipecat code
  

• .claude/skills/code-review/SKILL.mdskill
  Show content (6942 bytes)

  ---
  name: code-review
  description: Automated code review for pull requests using multiple specialized agents
  disable-model-invocation: true
  allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*)
  ---
  
  Provide a code review for the given pull request.
  
  **Agent assumptions (applies to all agents and subagents):**
  
  - All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
  - Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
  
  To do this, follow these steps precisely:
  
  1. Launch a haiku agent to check if any of the following are true:
     - The pull request is closed
     - The pull request is a draft
     - The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
     - Claude has already commented on this PR (check `gh pr view <PR> --comments` for comments left by claude)
  
     If any condition is true, stop and do not proceed.
  
  Note: Still review Claude generated PR's.
  
  2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
     - The root CLAUDE.md file, if it exists
     - Any CLAUDE.md files in directories containing files modified by the pull request
  
  3. Launch a sonnet agent to view the pull request and return a summary of the changes
  
  4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:
  
     Agents 1 + 2: CLAUDE.md compliance sonnet agents
     Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.
  
     Agent 3: Opus bug agent (parallel subagent with agent 4)
     Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
  
     Agent 4: Opus bug agent (parallel subagent with agent 3)
     Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.
  
     **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
     - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
     - The code will definitely produce wrong results regardless of inputs (clear logic errors)
     - Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken
  
     Do NOT flag:
     - Code style or quality concerns
     - Potential issues that depend on specific inputs or state
     - Subjective suggestions or improvements
  
     If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
  
     In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.
  
  5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.
  
  6. Filter out any issues that were not validated in step 5. This step will give us our list of high signal issues for our review.
  
  7. If issues were found, skip to step 8 to post comments.
  
     If NO issues were found, post a summary comment using `gh pr comment` (if `--comment` argument is provided):
     "No issues found. Checked for bugs and CLAUDE.md compliance."
  
  8. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
  
  9. Post inline comments for each issue using `gh pr review` with inline comments. For each comment:
     - Provide a brief description of the issue
     - For small, self-contained fixes, include a committable suggestion block
     - For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block
     - Never post a committable suggestion UNLESS committing the suggestion fixes the issue entirely. If follow up steps are required, do not leave a committable suggestion.
  
     **IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.**
  
  Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
  
  - Pre-existing issues
  - Something that appears to be a bug but is actually correct
  - Pedantic nitpicks that a senior engineer would not flag
  - Issues that a linter will catch (do not run the linter to verify)
  - General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
  - Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
  
  Notes:
  
  - Use gh CLI to interact with GitHub (e.g., fetch pull requests, create comments). Do not use web fetch.
  - Create a todo list before starting.
  - You must cite and link each issue in inline comments (e.g., if referring to a CLAUDE.md, include a link to it).
  - If no issues are found, post a comment with the following format:
  
  ---
  
  ## Code review
  
  No issues found. Checked for bugs and CLAUDE.md compliance.
  
  ---
  
  - When linking to code in inline comments, follow the following format precisely, otherwise the Markdown preview won't render correctly: `https://github.com/OWNER/REPO/blob/FULL_SHA/path/to/file.py#L10-L15`
    - Requires full git sha
    - You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
    - Repo name must match the repo you're code reviewing
    - # sign after the file name
    - Line range format is L[start]-L[end]
    - Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to `L4-7`)
  

• .claude/skills/update-docs/SKILL.mdskill
  Show content (11709 bytes)

  ---
  name: update-docs
  description: Update documentation pages to match source code changes on the current branch
  ---
  
  Update documentation pages to reflect source code changes on the current branch. Analyzes the diff against main, maps changed source files to their corresponding doc pages, and makes targeted edits.
  
  ## Arguments
  
  ```
  /update-docs [DOCS_PATH]
  ```
  
  - `DOCS_PATH` (optional): Path to the docs repository root. If not provided, ask the user.
  
  Examples:
  - `/update-docs /Users/me/src/docs`
  - `/update-docs`
  
  ## Instructions
  
  ### Step 1: Resolve docs path
  
  If `DOCS_PATH` was provided as an argument, use it. Otherwise, ask the user for the path to their docs repository.
  
  Verify the path exists and contains `server/services/` subdirectory.
  
  ### Step 2: Create docs branch
  
  Get the current pipecat branch name:
  ```bash
  git rev-parse --abbrev-ref HEAD
  ```
  
  In the docs repo, create a new branch off main with a matching name:
  ```bash
  cd DOCS_PATH && git checkout main && git pull && git checkout -b {branch-name}-docs
  ```
  
  For example, if the pipecat branch is `feat/new-service`, the docs branch becomes `feat/new-service-docs`.
  
  All doc edits in subsequent steps are made on this branch.
  
  ### Step 3: Detect changed source files
  
  Run:
  ```bash
  git diff main..HEAD --name-only
  ```
  
  Filter to files that could affect documentation:
  - `src/pipecat/services/**/*.py` (service implementations)
  - `src/pipecat/transports/**/*.py` (transport implementations)
  - `src/pipecat/serializers/**/*.py` (serializer implementations)
  - `src/pipecat/processors/**/*.py` (processor implementations)
  - `src/pipecat/audio/**/*.py` (audio utilities)
  - `src/pipecat/turns/**/*.py` (turn management)
  - `src/pipecat/observers/**/*.py` (observers)
  - `src/pipecat/pipeline/**/*.py` (pipeline core)
  
  Ignore `__init__.py`, `__pycache__`, test files, and files that only contain type re-exports.
  
  ### Step 4: Map source files to doc pages
  
  For each changed source file, find the corresponding doc page. Read the mapping file at `.claude/skills/update-docs/SOURCE_DOC_MAPPING.md` and apply its tiered lookup: tier 1 (known exceptions) → tier 2 (pattern matching) → tier 3 (search fallback). **First match wins.**
  
  ### Step 5: Analyze each source-doc pair
  
  For each mapped pair:
  
  1. **Read the full source file** to understand current state
  2. **Read the diff** for that file: `git diff main..HEAD -- <source_file>`
  3. **Read the current doc page** in full
  
  Identify what changed by comparing source to docs:
  
  - **Constructor parameters**: Compare `__init__` signature to the Configuration section's `<ParamField>` entries
  - **InputParams fields**: Compare `InputParams(BaseModel)` class fields to the InputParams table
  - **Event handlers**: Compare `_register_event_handler` calls and event handler definitions to Event Handlers section
  - **Class names / imports**: Check if Usage examples reference correct names
  - **Behavioral changes**: Check if Notes section needs updating
  
  ### Step 6: Make targeted edits
  
  For each doc page that needs updates, edit **only the sections that need changes**. Preserve all other content exactly as-is.
  
  #### Rules
  
  - **Never remove content** unless the corresponding source code was removed
  - **Never rewrite sections** that are already accurate
  - **Match existing formatting** — if the page uses `<ParamField>` tags, use them; if it uses tables, use tables
  - **Keep descriptions concise** — match the tone and length of surrounding content
  - **Preserve CardGroup, links, and examples** unless they reference removed functionality
  - **Don't touch frontmatter** unless the class was renamed
  
  #### Section-specific guidance
  
  **Configuration** (constructor params):
  - Use `<ParamField path="name" type="type" default="value">` format if the page already uses it
  - Add new params in logical order (required first, then optional)
  - Remove params that no longer exist in source
  - Update types/defaults that changed
  
  **InputParams** (runtime settings):
  - Use markdown table format: `| Parameter | Type | Default | Description |`
  - Match the field names and types from the `InputParams(BaseModel)` class
  - Include the default values from the source
  
  **Usage** (code examples):
  - Update import paths, class names, and parameter names
  - Only modify examples if they would break or be misleading with the new API
  - Don't rewrite working examples just to add new optional params
  
  **Notes**:
  - Add notes for new behavioral gotchas or breaking changes
  - Remove notes about limitations that were fixed
  - Keep existing notes that are still accurate
  
  **Event Handlers**:
  - Update the event table and example code
  - Add new events, remove deleted ones
  - Update handler signatures if they changed
  
  **Overview / Key Features / Prerequisites**:
  - Only update if the PR fundamentally changes what the service does (new capability, removed capability, renamed class)
  - Most PRs will NOT need changes to these sections
  
  ### Step 7: Update guides
  
  Guides at `DOCS_PATH/guides/` reference specific class names, parameters, imports, and code patterns. After completing reference doc edits, check if any guides need updates too.
  
  For each changed source file, collect the class names, renamed parameters, and changed imports from the diff. Search the guides directory:
  ```bash
  grep -rl "ClassName\|old_param_name" DOCS_PATH/guides/
  ```
  
  For each guide that references changed code:
  1. Read the full guide
  2. Update class names, parameter names, import paths, and code examples that are now incorrect
  3. **Don't rewrite prose** — only fix the specific references that changed
  4. Leave guides alone if they reference the service generally but don't use any changed APIs
  
  Guide directories:
  - `guides/learn/` — conceptual tutorials (pipeline, LLM, STT, TTS, etc.)
  - `guides/fundamentals/` — practical how-tos (metrics, recording, transcripts, etc.)
  - `guides/features/` — feature-specific guides (Gemini Live, OpenAI audio, WhatsApp, etc.)
  - `guides/telephony/` — telephony integration guides (Twilio, Plivo, Telnyx, etc.)
  
  ### Step 8: Identify doc gaps
  
  After processing all mapped pairs, check for two kinds of gaps:
  
  **Missing pages**: Source files that had no doc page mapping (neither tier 1, 2, nor 3) and are not marked as "(skip)". For each, tell the user:
  - The source file path
  - The main class(es) it defines
  - Whether a new doc page should be created
  
  **Missing sections**: Mapped doc pages that are missing standard sections compared to the source. For example, a transport page with no Configuration section, or a service page with no InputParams table when the source defines `InputParams(BaseModel)`. Flag these and offer to add the missing sections.
  
  If the user wants a new page, do all three of the following:
  
  #### 8a: Create the doc page
  
  Create the new `.mdx` file using this template structure:
  ```
  ---
  title: "Service Name"
  description: "Brief description"
  ---
  
  ## Overview
  
  [Description from class docstring or source analysis]
  
  <CardGroup cols={2}>
    [Cards for API reference and examples if available]
  </CardGroup>
  
  ## Installation
  
  ```bash
  pip install "pipecat-ai[package-name]"
  ```
  
  ## Prerequisites
  
  [Environment variables and account setup]
  
  ## Configuration
  
  [ParamField entries for constructor params]
  
  ## InputParams
  
  [Table of InputParams fields, if the service has them]
  
  ## Usage
  
  ### Basic Setup
  
  ```python
  [Minimal working example]
  ```
  
  ## Notes
  
  [Important caveats]
  
  ## Event Handlers
  
  [Event table and example code]
  ```
  
  #### 8b: Add to docs.json
  
  Add the new page path to `DOCS_PATH/docs.json` in the correct navigation group. The path format is `server/services/{category}/{provider}` (without the `.mdx` extension).
  
  Find the matching group in the navigation structure:
  - **STT** → `"group": "Speech-to-Text"` under Services
  - **TTS** → `"group": "Text-to-Speech"` under Services
  - **LLM** → `"group": "LLM"` under Services
  - **S2S** → `"group": "Speech-to-Speech"` under Services
  - **Transport** → `"group": "Transport"` under Services
  - **Serializer** → `"group": "Serializers"` under Services
  - **Image generation** → `"group": "Image Generation"` under Services
  - **Video** → `"group": "Video"` under Services
  - **Memory** → `"group": "Memory"` under Services
  - **Vision** → `"group": "Vision"` under Services
  - **Analytics** → `"group": "Analytics & Monitoring"` under Services
  
  Insert the new entry **alphabetically** within the group's `pages` array. For example, adding a new STT service "foo":
  ```json
  {
    "group": "Speech-to-Text",
    "pages": [
      "server/services/stt/assemblyai",
      "server/services/stt/aws",
      ...
      "server/services/stt/foo",
      ...
    ]
  }
  ```
  
  #### 8c: Add to supported-services.mdx
  
  Add a new row to the correct category table in `DOCS_PATH/server/services/supported-services.mdx`.
  
  Use this format:
  ```
  | [DisplayName](/server/services/{category}/{provider}) | `pip install "pipecat-ai[package]"` |
  ```
  
  To determine the correct values:
  - **DisplayName**: Use the service's human-readable name (e.g., "ElevenLabs", "AWS Polly", "Google Gemini")
  - **package**: Look at the service's `pyproject.toml` extras or the import pattern in the source code. For example, if the service is in `src/pipecat/services/foo/`, the package is typically `foo`.
  - If no pip dependencies are required, use `No dependencies required` instead.
  
  Insert the new row **alphabetically** within the table. Match the column alignment of the existing rows.
  
  ### Step 9: Output summary
  
  After all edits are complete, print a summary:
  
  ```
  ## Documentation Updates
  
  ### Updated reference pages
  - `server/services/stt/deepgram.mdx` — Updated Configuration (added `new_param`), InputParams (updated `language` default)
  - `server/services/tts/elevenlabs.mdx` — Updated Event Handlers (added `on_connected`)
  
  ### Updated guides
  - `guides/learn/speech-to-text.mdx` — Updated code example (renamed `old_param` → `new_param`)
  
  ### New service pages
  - `server/services/tts/newprovider.mdx` — Created page, added to docs.json (Text-to-Speech), added to supported-services.mdx
  
  ### Unmapped source files
  - `src/pipecat/services/newprovider/tts.py` — NewProviderTTSService (no doc page exists)
  
  ### Skipped files
  - `src/pipecat/services/ai_service.py` — internal base class
  ```
  
  ## Guidelines
  
  - **Be conservative** — only change what the diff warrants. Don't "improve" docs beyond what changed in source.
  - **Read before editing** — always read the full doc page before making changes so you understand the existing structure.
  - **Preserve voice** — match the writing style of the existing doc page, don't impose a different tone.
  - **One PR at a time** — this skill operates on the current branch's diff against main. Don't look at other branches.
  - **Parallel analysis** — when multiple source files map to different doc pages, analyze and edit them in parallel for efficiency.
  - **Shared source files** — files like `services/google/google.py` are shared bases. Check which services import from them and update all affected doc pages.
  
  ## Checklist
  
  Before finishing, verify:
  
  - [ ] All changed source files were checked against the mapping table
  - [ ] Each doc page edit matches the actual source code change (not guessed)
  - [ ] No content was removed unless the corresponding source was removed
  - [ ] New parameters have accurate types and defaults from source
  - [ ] Formatting matches the existing page style
  - [ ] Guides referencing changed APIs were checked and updated
  - [ ] New service pages were added to `docs.json` in the correct group, alphabetically
  - [ ] New service pages were added to `supported-services.mdx` in the correct table, alphabetically
  - [ ] Unmapped files were reported to the user
  

• .claude/skills/docstring/SKILL.mdskill
  Show content (7698 bytes)

  ---
  name: docstring
  description: Document a Python module and its classes using Google style
  ---
  
  Document a Python module or class using Google-style docstrings following project conventions. The argument can be a class name or a module path.
  
  ## Instructions
  
  1. Determine what to document based on the argument:
  
     **If a module path is provided** (e.g. `src/pipecat/audio/vad/vad_analyzer.py`):
     - Use that file directly
  
     **If a class name is provided** (e.g. `VADAnalyzer`):
     - Search for `class ClassName` in `src/pipecat/`
     - If multiple files contain that class name, list all matches with their file paths, ask the user which one they want to document, and wait for confirmation
  
  2. Once the file is identified, read the module to understand its structure:
     - Identify all classes, functions, and important type aliases
     - Understand the purpose of each component
  
  4. Apply documentation in this order:
     - Module docstring (at top, after imports)
     - Class docstrings
     - `__init__` methods (always document constructor parameters)
     - Public methods (not starting with `_`)
     - Dataclass/config classes with field descriptions
  
  5. Skip documentation for:
     - Private methods (starting with `_`)
     - Simple dunder methods (`__str__`, `__repr__`, `__post_init__`)
     - Very simple pass-through properties
     - **Already documented code** - If a class, method, or function already has a complete docstring that follows the project style, do not modify it. A docstring is complete if it has:
       - A one-line summary
       - Args section (if it has parameters)
       - Returns section (if it returns something meaningful)
     - Only add or improve documentation where it is missing or incomplete
  
  ## Module Docstring Format
  
  ```python
  """[One-line description of module purpose].
  
  [Optional: Longer explanation of functionality, key classes, or use cases.]
  """
  ```
  
  Example:
  ```python
  """Neuphonic text-to-speech service implementations.
  
  This module provides WebSocket and HTTP-based integrations with Neuphonic's
  text-to-speech API for real-time audio synthesis.
  """
  ```
  
  ## Class Docstring Format
  
  ```python
  class ClassName:
      """One-line summary describing what the class does.
  
      [Longer description explaining purpose, behavior, and key features.
      Use action-oriented language.]
  
      [Optional: Event handlers, usage notes, or important caveats.]
      """
  ```
  
  Example:
  ```python
  class FrameProcessor(BaseObject):
      """Base class for all frame processors in the pipeline.
  
      Frame processors are the building blocks of Pipecat pipelines, they can be
      linked to form complex processing pipelines. They receive frames, process
      them, and pass them to the next or previous processor in the chain.
  
      Event handlers available:
  
      - on_before_process_frame: Called before a frame is processed
      - on_after_process_frame: Called after a frame is processed
  
      Example::
  
          @processor.event_handler("on_before_process_frame")
          async def on_before_process_frame(processor, frame):
              ...
  
          @processor.event_handler("on_after_process_frame")
          async def on_after_process_frame(processor, frame):
              ...
      """
  ```
  
  Note: When listing event handlers, do NOT use backticks. Include an `Example::` section (with double colon for Sphinx) showing the decorator pattern and function signature for each event.
  
  ## Constructor (`__init__`) Format
  
  ```python
  def __init__(self, *, param1: Type, param2: Type = default, **kwargs):
      """Initialize the [ClassName].
  
      Args:
          param1: Description of param1 and its purpose.
          param2: Description of param2. Defaults to [default].
          **kwargs: Additional arguments passed to parent class.
      """
  ```
  
  Example:
  ```python
  def __init__(
      self,
      *,
      api_key: str,
      voice_id: Optional[str] = None,
      sample_rate: Optional[int] = 22050,
      **kwargs,
  ):
      """Initialize the Neuphonic TTS service.
  
      Args:
          api_key: Neuphonic API key for authentication.
          voice_id: ID of the voice to use for synthesis.
          sample_rate: Audio sample rate in Hz. Defaults to 22050.
          **kwargs: Additional arguments passed to parent InterruptibleTTSService.
      """
  ```
  
  ## Method Docstring Format
  
  ```python
  async def method_name(self, param1: Type) -> ReturnType:
      """One-line summary of what method does.
  
      [Longer description if behavior isn't obvious.]
  
      Args:
          param1: Description of param1.
  
      Returns:
          Description of return value.
  
      Raises:
          ExceptionType: When this exception is raised.
      """
  ```
  
  Example:
  ```python
  async def put(self, item: Tuple[Frame, FrameDirection, FrameCallback]):
      """Put an item into the priority queue.
  
      System frames (`SystemFrame`) have higher priority than any other
      frames. If a non-frame item is provided it will have the highest priority.
  
      Args:
          item: The item to enqueue.
      """
  ```
  
  ## Dataclass/Config Format
  
  ```python
  @dataclass
  class ConfigName:
      """One-line description of configuration.
  
      [Explanation of when/how to use this config.]
  
      Parameters:
          field1: Description of field1.
          field2: Description of field2. Defaults to [default].
      """
  
      field1: Type
      field2: Type = default_value
  ```
  
  Example:
  ```python
  @dataclass
  class FrameProcessorSetup:
      """Configuration parameters for frame processor initialization.
  
      Parameters:
          clock: The clock instance for timing operations.
          task_manager: The task manager for handling async operations.
          observer: Optional observer for monitoring frame processing events.
      """
  
      clock: BaseClock
      task_manager: BaseTaskManager
      observer: Optional[BaseObserver] = None
  ```
  
  ## Enum Documentation Format
  
  ```python
  class EnumName(Enum):
      """One-line description of the enum purpose.
  
      [Longer description of how the enum is used.]
  
      Parameters:
          VALUE1: Description of VALUE1.
          VALUE2: Description of VALUE2.
      """
  
      VALUE1 = 1
      VALUE2 = 2
  ```
  
  ## Writing Style Guidelines
  
  - **Concise and professional** - No casual language or filler words
  - **Action-oriented** - Start with verbs: "Processes...", "Manages...", "Converts..."
  - **Purpose before implementation** - Explain WHY before HOW
  - **Clear parameter descriptions** - Include type hints, defaults, and purpose
  - **No redundant type info** - Type hints are in the signature, don't repeat in description
  - **Use backticks for code references** - Wrap class names, method names, event names, parameter names, and code snippets in backticks
  
  Good: "Neuphonic API key for authentication."
  Bad: "str: The API key (string) that is used for authenticating with Neuphonic."
  
  Good: "Triggers `on_speech_started` when the `VADAnalyzer` detects speech."
  Bad: "Triggers on_speech_started when the VADAnalyzer detects speech."
  
  ## Deprecation Notice Format
  
  When documenting deprecated code:
  
  ```python
  """[Description].
  
  .. deprecated:: X.X.X
      `ClassName` is deprecated and will be removed in a future version.
      Use `NewClassName` instead.
  """
  ```
  
  ## Checklist
  
  Before finishing, verify:
  
  - [ ] Module has a docstring at the top (after copyright header and imports)
  - [ ] All public classes have docstrings
  - [ ] All `__init__` methods document their parameters
  - [ ] All public methods have docstrings with Args/Returns/Raises as needed
  - [ ] Dataclasses use "Parameters:" section for field descriptions
  - [ ] Enums document each value in "Parameters:" section
  - [ ] Writing is concise and action-oriented
  - [ ] No documentation added to private methods (starting with `_`)
  - [ ] Existing complete docstrings were left unchanged
  

• .claude-plugin/marketplace.jsonmarketplace
  Show content (708 bytes)

  {
    "name": "pipecat-dev-skills",
    "owner": {
      "name": "Pipecat"
    },
    "metadata": {
      "description": "Development workflow skills for contributing to the Pipecat project",
      "version": "1.0.0"
    },
    "plugins": [
      {
        "name": "pipecat-dev",
        "description": "Development workflow skills for contributing to the Pipecat project",
        "version": "1.0.0",
        "source": "./",
        "skills": [
          "./.claude/skills/changelog",
          "./.claude/skills/cleanup",
          "./.claude/skills/code-review",
          "./.claude/skills/docstring",
          "./.claude/skills/pr-description",
          "./.claude/skills/pr-submit",
          "./.claude/skills/update-docs"
        ]
      }
    ]
  }
  

README

claude plugin marketplace add pipecat-ai/skills

claude plugin marketplace add pipecat-ai/pipecat
claude plugin install pipecat-dev@pipecat-dev-skills

uv run pytest

uv run pytest tests/test_name.py