provider-watch

Research AI providers behind Pipecat services and generate dated reports and draft PR branches.

15.1k|2.6k|Updated Dec 27, 2023
One-click install
npx skills add https://github.com/pipecat-ai/pipecat --skill provider-watch
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: provider-watch
Source: https://github.com/pipecat-ai/pipecat/tree/main/.claude/skills/provider-watch
Command: npx skills add https://github.com/pipecat-ai/pipecat --skill provider-watch

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Pipecat integrates dozens of speech and LLM providers whose models, defaults, and APIs change constantly; this Skill automates the recurring audit that detects new models, deprecations, and unexposed API parameters before users hit breakage.

Core Features & Use Cases

  • Per-unit research sweeps: Spawns one researcher subagent per provider/service unit (e.g. cartesia/tts) that probes live APIs, compares catalogues against Pipecat's code, and writes a dated gap report.
  • Draft PR proposals: Researchers leave committed branches for clear-cut changes like default model bumps or new Settings fields, which publish.py turns into draft PRs.
  • Digest and decision tracking: Aggregates run results into a dated digest issue and maintains per-unit decisions.md files so rejected items are not re-proposed.
  • Use Case: Run a weekly sweep across all providers to discover that Cartesia released sonic-4, verify its latency against the current default, and get a ready-to-review branch bumping the default.

Quick Start

Run /provider-watch --only deepgram,groq --limit 2 --concurrency 1 to smoke-test a small research sweep and review the generated reports and branches locally.

Frequently Asked Questions about provider-watch

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a provider research sweep for Pipecat services?

Invoke /provider-watch with optional filters like --only deepgram,groq to select providers, --limit N for test runs, and --concurrency N to control parallel researchers. Each unit gets a researcher subagent that writes a dated report and optionally a branch.

How does provider-watch decide when to propose a PR?

A change qualifies only when it is a default model bump, allowlist addition, retired-string fix, or simple pass-through Settings field, verified by a live probe with latency not worse than the current default. Everything else is recorded as a gap with action 'consider' for maintainer review.

Does provider-watch push code or open PRs automatically?

Only with the --publish flag, and only through scripts/provider-watch/publish.py, which pushes branches, opens up to 8 draft PRs per run, and files the digest issue. Without --publish the run is a dry run and everything stays local.

What credentials and tools does provider-watch require?

It requires the gh CLI authenticated for GitHub operations, uv for running inventory and probe scripts, and provider API keys in the environment for live probing. Missing credentials cause the affected unit's report to record an error naming the missing variable, never its value.

How does provider-watch avoid re-proposing rejected changes?

Each unit has a decisions.md file recording maintainer decisions from digest issue comments and closed-unmerged PRs. Researchers read it before reporting and exclude any item a decision in force covers, appending new decisions as they are found.