Update to Pipecat Context Hub

{
  "description": "Build and verify a local Pipecat app after an explicit build request, using native local execution, installed CLI capabilities and grounded Context Hub APIs.",
  "included_files": [],
  "name": "build",
  "skill_md_contents": "---\nname: build\ndescription: Build and verify a local Pipecat app after an explicit build request, using native local execution, installed CLI capabilities and grounded Context Hub APIs.\n---\n\nA build request authorises local project work within the chosen workspace.\nAn idea/concept discussion alone authorises only exploration. Skills do not\ngrant execution permissions. This workflow requires native local shell/file\nexecution and the installed Pipecat CLI; it does not use a shell MCP adapter.\nIf either is absent, report build unavailable, retain working exploration and\noffer [required CLI setup](../setup/SKILL.md#required-workflow-clis). Pipecat CLI\nis required for building; PCH query commands do not replace it.\nCloud account access is not required for local build. Deployment is a separate\nworkflow; hand off to deploy for read-only preparation and a concrete approval\npayload. Do not upload secrets, deploy or start remote agent sessions here.\n\n## Gate and resolve choices\n\n1. Confirm this chat has native local execution using a harmless shell command.\n   Inspect `pipecat --version` and `pipecat init --help`. If unavailable, explain\n   the missing capability without installing/upgrading tools automatically. If\n   the version is older than the requested capability requires, hand off to\n   [Setup's older-CLI flow](../setup/SKILL.md#handle-an-older-pipecat-cli) and\n   present one approval-gated upgrade proposal; do not upgrade merely because a\n   newer release exists. Continue with the installed CLI when it supports the\n   requested build.\n   Use `pipecat init --list-options` only if advertised; parse its JSON and\n   retain the actual service identifiers and transport combinations. Installed\n   help/options take precedence over newer docs. Never assume `--eval`, inferred\n   bot type, config keys or flags that this version does not advertise.\n2. Resolve material user choices before generation: selected project directory\n   and name, browser versus telephony, transport, cascade versus realtime,\n   providers, client requirements, intended behaviour and target framework\n   version. Ask focused questions for missing choices; do not invent providers,\n   credentials or use a qualification fixture as user defaults. Map choices to\n   actual CLI identifiers. Explain unsupported combinations rather than\n   silently substituting them. Clarify optional recording/video/observability\n   choices when relevant. For a local build, disable Cloud file generation when\n   supported; explain if this CLI requires those files anyway.\n3. Inspect the selected output directory and the actual project-name child the\n   CLI will create, including hidden entries, without reading existing `.env`\n   files. Refuse scaffolding into any nonempty destination, existing app or\n   symlink to one. Do not delete files to make it empty or force overwrites.\n   For an existing project, adapt its current structure and dependency lock\n   within the requested scope; do not re-scaffold. A new app needs an explicitly\n   selected absent/empty directory. Recheck immediately before generation.\n\n## Dry run, scaffold and ground customization\n\nBuild one explicit argument list from supported options. On CLI 1.3.0,\nnoninteractive mode uses `--name` or `--config`; `--bot-type` is required in\nobserved probes, and `--client-framework none` means no client. These are dated\ncompatibility facts, not permanent defaults. If using JSON `--config`, discover\nits schema through installed documentation or a valid dry run; do not assume\n`--list-options` is a config schema. Inspect resolved JSON, not just exit status.\n\nRun the supported `--dry-run` with the same selections and output path as the\nplanned scaffold. Verify resolved name, bot type, transports, mode, providers,\nclient and optional features; ensure no files were created. Resolve errors or\nunexpected defaults before proceeding. If this version lacks a safe dry run,\nreport that gate unavailable instead of silently generating. Then recheck the\nempty destination and scaffold once. A failed/partial scaffold becomes an\nexisting directory: inspect and fix within it, never blindly re-run generation.\n\nUse generated layout, entrypoint, environment template, dependency constraints\nand lock rather than rewriting them from a newer example. If no version pin or\nlock is generated, say so, install using the generated constraints and retain\nthe resolved lock/version. Do not silently upgrade pins to match indexed APIs.\nRead required key **names** from generated placeholders and source; never print\nsecret values or read existing `.env` files. Credentials are supplied by the user\nthrough their local workflow, not invented or copied into reports.\n\nBefore Pipecat API customization, follow\n[Explore's CLI retrieval](../explore/SKILL.md#cli-retrieval) using the installed\nPCH command. Check status, inspect installed help, retrieve\ndefinitions/examples, and cite returned source URLs. Separate\nmultiple concepts with ` + ` or ` & `. Search/detail filters are tool-specific,\nas described in explore. Verify definitions rather than reference-only hits.\nCheck relevant deprecations. Pass the app's version where supported, but explain\nthat compatibility annotations do not select a different indexed snapshot.\nUnknown compatibility or a version mismatch needs local validation; strict\nunavailable-version requirements remain unresolved. Never refresh/reset/repair\nor change the index. Preserve generated architecture and make only the requested\nbehaviour changes justified by retrieved APIs. Record before/after Hub provenance.\n\n## Verify locally and report honestly\n\nInstall the generated project's local dependencies with its package manager,\nrespecting existing pins/lock. Inspect its documented entrypoint/help before\nlaunching. Use bounded, project-appropriate syntax/import, startup and behaviour\nchecks. Isolate checks from existing credentials (`.env` loading disabled and a\nclean environment); placeholder strings satisfy only local construction when\nappropriate, never authenticate a provider. Avoid provider API calls, microphone\nsessions or browser conversations unless separately requested and authorised.\nStop local processes after checks and record startup errors and exit codes.\n\nUse upstream eval support only if discovered in this installed CLI; otherwise\nname the explicit local verification method. Credential-free context/handler\nchecks or doubles can verify a narrow application behaviour, but cannot prove\nSTT/LLM/TTS service integration. If startup cannot run without credentials or\nnetwork, report the blocker and the checks that did run. A local HTTP health\nresponse proves server startup, not an end-to-end conversation. Imports, mocks,\nresolved configuration and generated files are distinct evidence.\n\nReturn project path, selected choices, CLI/framework versions, generated and\nresolved pins, files customized with sources, exact check outcomes and remaining\ncredential/provider/client validation. Build unavailable, partially verified,\nlocally verified and conversation-verified are different results. Missing Pipecat\nbuild CLI does not disable working PCH exploration; missing native execution or\nPCH makes grounded retrieval unavailable. Do not claim a live conversation from\nimports or mocks, or revised plugin activation from a fresh prepared copy.\n"
}