Combine all service research reports for a selected date into a local Markdown digest. Add up to five highlights to help maintainers prioritize updates, review proposed changes, and spot research errors.
Render the digest for one provider-research date from every report on disk, topped with authored highlight bullets; publishing is scripts/provider-watch/publish.py's job, run outside this skill
Review the instructions the agent will receive before you install.
Render digests/<date>.md in the reports checkout from every report carrying the date, topped with highlight bullets you author. The digest is a function of the reports on disk, not of any one research run — re-running this skill after further same-date research replaces the digest with a fresh view of the whole date. Everything stays local — this skill publishes nothing; pushing the digest and opening the digest issue are scripts/provider-watch/publish.py --finalize's job, run afterwards by whoever invoked this.
/provider-research-digest [--date YYYY-MM-DD]
--date YYYY-MM-DD — the date to digest. Defaults to today.Record RUN_DATE as --date if given, else today's date (YYYY-MM-DD), and pick a scratch directory outside the repo (your session scratchpad if you have one, else mktemp -d -t provider-research-digest). The reports checkout is always ./_reports in this repo (gitignored). If it is missing, gh repo clone pipecat-ai/provider-watch-reports _reports; if it exists and has a remote, git -C _reports pull --ff-only — the digest must see every report published for the date, not a stale checkout. Stop with a clear error if no _reports/reports/*/*/<RUN_DATE>.md exists.
uv run python scripts/provider-watch/digest.py --reports _reports --date <RUN_DATE> --out <scratch>/digest-draft.md
Read the draft: it aggregates every unit's summary, PRs, changes to consider and errors for the date.
Write up to 5 highlight bullets to <scratch>/highlights.md from the draft: what a maintainer should look at first — services broken out of the box, PRs and branches worth reviewing first, long-open gaps that finally moved, providers that errored. Judge from the whole date, not from whichever units were researched most recently, and skip bullets when nothing stands out. Match the draft's conventions (unit ids and code in backticks, report paths where a pointer helps).
uv run python scripts/provider-watch/digest.py --reports _reports --date <RUN_DATE> --highlights <scratch>/highlights.md --out _reports/digests/<RUN_DATE>.md
uv run python scripts/provider-watch/publish.py --date <RUN_DATE> --finalize — publishes everything on disk for the date, digest included: pushes branches, reports and the digest, and opens (or updates) the digest issue.Authorization headers, or raw API keys.publish.py — print its command instead.digest.py; author only the highlights, and do not hand-edit the rendered sections.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create changelog files for significant changes in a pull request, a proposed code change. Describe effects users will notice and organize entries by PR number and change type, such as features or fixes.
Review and improve code changes on the current branch using Pipecat conventions. Refine names and structure, add type hints and documentation, check example patterns, and make conservative performance improvements while preserving compatibility.
Review GitHub pull requests with specialized agents that check for clear bugs and violations of project instructions in CLAUDE.md. Validate bug findings before posting focused comments on the affected lines, with fix suggestions where appropriate.
Add or improve Google-style docstrings, the explanations embedded in Python code, for modules and classes. Document constructor arguments, public methods, configuration fields, and enum values while preserving existing documentation that already meets the project’s conventions.
Draft or update GitHub pull request descriptions using the actual changes and related context. Explain the problem, changed behavior, and review concerns in plain language, including breaking changes and explicit issue-closing references when applicable.
Submit current work as a GitHub pull request, handling relevant uncommitted changes and reviewing prose before pushing. After creating the PR, run companion skills to generate changelog files, update the description, and return its URL.