pipecat: Skill for Claude Code

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

3. 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

4. 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

"""[One-line description of module purpose].

[Optional: Longer explanation of functionality, key classes, or use cases.]
"""

Example:

"""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.
"""