Update to Pipecat Context Hub

{
  "description": "Prepare a Pipecat Cloud deployment with read-only checks and an exact approval payload, then execute only approved secret changes, build and deployment and verify readiness.",
  "included_files": [],
  "name": "deploy",
  "skill_md_contents": "---\nname: deploy\ndescription: Prepare a Pipecat Cloud deployment with read-only checks and an exact approval payload, then execute only approved secret changes, build and deployment and verify readiness.\n---\n\nA deployment request authorises preparation in the selected app workspace.\nBefore concrete approval, Cloud inspection is read-only. Do not create/update\nsecrets, upload source, build images locally or remotely, push to a registry,\ndeploy, start agent sessions, delete deployments or roll back. `deploy` is not\na dry run. Skills do not grant execution permissions. Exploration and local\nbuild remain available when Cloud prerequisites are missing. Pipecat CLI and\nits Cloud extension are required for deployment, separately from PCH query\nreadiness. Offer [required CLI setup](../setup/SKILL.md#required-workflow-clis)\nwhen they are absent; preparation does not install them silently.\n\n## Discover and prepare\n\n1. Confirm native local shell/file execution, selected existing app and installed\n   Pipecat/Cloud CLI versions. Inspect installed help for deploy, secret list/set,\n   organisations, regions, profiles, status and logs. Discover actual flags and\n   config schema; installed capabilities take precedence over newer docs.\n   Missing execution/CLI disables deployment only; never install an adapter or\n   upgrade tools silently. Preserve the existing bot, dependency pins and lock;\n   never re-scaffold an existing project to obtain Cloud files.\n2. Follow [Explore's CLI retrieval](../explore/SKILL.md#cli-retrieval) using the\n   installed PCH command. Check status before/after, retrieve relevant docs/API/\n   examples and retain\n   source citations. Separate multiple concepts with ` + ` or ` & `; inspect\n   installed command help before passing filters. Ground Dockerfile\n   and runtime entrypoint\n   choices, including transport/runner compatibility, in retrieved definitions.\n   Version annotations do not switch indexed snapshots. Missing/unknown evidence\n   stays unresolved; never refresh/reset/repair or change the index/version pin.\n3. Validate the selected path's supported runtime, entrypoint and deploy\n   configuration. For source builds, also validate project layout, asynchronous\n   bot entrypoint, dependency lock and Dockerfile. For source builds, verify\n   required build tools against the exact pinned base, not a mutable tag or newer\n   template.\n   If absent, supply an explicit immutable tool input (for example, digest-pinned\n   official uv binaries with the required platform and lock-format support).\n   For source builds relying on the inherited entrypoint, inspect that base's\n   config and revision-linked entrypoint source to establish its Python, PATH,\n   workdir and dependency environment. Install into the Python\n   environment the inherited entrypoint actually uses; default uv `.venv` creation\n   is insufficient when that entrypoint runs system Python. Preserve base server\n   dependencies (for example, an explicitly targeted `uv sync --inexact`, with\n   conflicts and required imports checked) and inherited CMD. For source builds\n   deliberately selecting a custom entrypoint, validate it against its own\n   runtime and dependency environment. Preserve project/lock bytes for all source\n   builds. Existing immutable registry images require verified image digest,\n   platform and relevant runtime evidence, without a rebuild, dependency\n   installation or unavailable base-source provenance.\n   Manifests/source inspection proves inputs, not a successful build or runtime.\n   Prepare only needed\n   local files, preserving existing ones. Inspect required key **names** from\n   placeholders/source without reading existing `.env` contents or printing\n   values. Distinguish required provider keys from optional settings/defaults\n   and Cloud management authentication. A local `.env` is not automatically\n   transferred to Cloud. Do not copy it into an image or build context.\n4. Check authentication through read-only organisation metadata. Never run a\n   credential-bearing Cloud metadata command directly through an agent-visible\n   execution tool: some versions expose a Daily API key. Invoke the packaged\n   `scripts/safe_cloud_metadata.py` wrapper with the matching `--kind` and pass\n   the installed read-only JSON command after `--`. Resolve `pipecat` to its\n   absolute installed path first; bare PATH-relative names are rejected to\n   prevent a shadow executable receiving `PIPECAT_TOKEN`. The wrapper only accepts\n   a CLI installed in the same Python environment as the wrapper; it rejects a\n   separate uv tool or virtualenv instead of copying unverified packages into a\n   credential-bearing subprocess. The wrapper captures raw\n   stdout/stderr inside its subprocess and emits only schema-validated allowlisted\n   fields. Treat a nonzero wrapper exit or schema mismatch as unresolved; do not\n   retry by printing raw output. Never use `auth whoami`, local auth config or\n   API-key listings. The wrapper allowlists org IDs/names, region/resource\n   metadata, agent identity/status, secret-set names and key names; it withholds\n   stderr, emails, credentials and values.\n   If an account/login is missing, hand off to\n   [Cloud account and login setup](../setup/SKILL.md#cloud-account-and-login):\n   guide signup at `https://pipecat.daily.co`, then user-run\n   `pipecat cloud auth login` on the execution host (or the supported PAT route\n   for headless execution). Let the user complete authentication;\n   successful read-only org queries already establish authentication. Do not\n   log in/out or switch the configured organisation during preparation.\n5. Resolve the user's organisation, region and agent identity explicitly; never\n   choose the first/default org or infer deployment approval. Pass explicit\n   organisation/region flags on Cloud commands where supported. Read existing\n   agent and secret-set metadata, including same-name collisions across regions.\n   Failed/unavailable metadata is unknown, never an empty existing state.\n   Inspect only supported metadata calls; do not retrieve secret values. If key\n   names cannot be inspected safely, record that prerequisite before proposing\n   updates. Propose exact add/update/unchanged key names for the selected set;\n   never overwrite unrelated keys or reuse an unrelated set automatically.\n6. Validate proposed scaling/profile/session limits against help and read-only\n   resources. Separate documented defaults, observed available profiles and\n   unapproved proposals. Validate image/base-image architecture against the\n   selected region; Daily-hosted arm64 is a dated observation, not a universal\n   default. Read-only registry manifests can establish platform and digest\n   without a build. Pin immutable base/build inputs where possible. Runtime\n   compatibility and a successful image build remain unverified until exercised.\n7. Choose a supported build path: Cloud source build, approved registry image or\n   immutable GitHub revision. A Cloud `--build-dir` operation uploads source and\n   builds/deploys, so it needs approval too; Docker is optional for that path.\n   For local source-upload builds, before approval inspect the archive produced\n   by the actual installed uploader's local preparation helper, without invoking\n   upload/build/deploy or\n   network operations. Docker `.dockerignore` negations cannot be assumed to\n   work in the CLI uploader. Prefer a fresh strict staging directory containing\n   only required regular, non-symlink source/build inputs, with verified\n   uploader-compatible explicit exclusions. Preserve original app/config bytes;\n   record any staging-only ignore-rule change separately. Exclude `.env*`,\n   credentials, `.venv`, caches, reports and unrelated files without accessing\n   secret content. Verify exact archive members and member-content hashes,\n   required Dockerfile/lock/source presence, regular file types and absence of\n   symlinks, traversal and extra paths. Record helper identity/version/provenance,\n   context and archive hashes/size, and independent staging composition; use\n   synthetic filenames/content to check exclusions. Local archive preparation\n   is allowed; image build, upload or push still requires approval. If the actual\n   archive cannot be verified safely, retain that prerequisite and stop before\n   presenting the payload as approval-ready. For an approved registry image,\n   verify its immutable image digest and platform; for an immutable GitHub\n   revision, verify the revision and immutable build inputs. These paths do not\n   require a local uploader archive.\n\n## Concrete approval boundary\n\nPrepare one reviewable payload with project/build context and immutable hashes,\nverified uploader archive members/content hashes and archive hash/size for local\nsource uploads, or immutable image digest/platform or GitHub revision/build-input\nevidence for the selected alternative path,\nCLI/framework versions, org ID/name, region, agent name and create/update action,\narchitecture/base image digest, profile or explicit resources, scaling/session\nlimits, secret-set name and exact proposed key additions/updates. Include a safe\nlocal secret-file path or supported value-transfer mechanism, execution order,\nexact commands and readiness/log checks. Values stay outside model context,\ncommand-line arguments, transcripts and committed files. Never claim credentials\nare available based on placeholder names. Missing target, metadata, credential\navailability or unsupported runtime is an explicit unresolved prerequisite.\n\nPresent this payload for approval only when required fields are concrete.\nPreparation can complete with unresolved fields; execution cannot. A pending or\ndeclined approval means zero mutations. User approval applies only to the stated\npayload; changed files/hashes, target, resources or secret actions require a new\npayload and approval. Recheck hashes and read-only target/secret metadata just\nbefore execution; stop if the approved create/update semantics have changed.\nDo not treat an earlier build request or general intent to deploy as approval.\n\n## Execute approved operations and verify\n\nAfter explicit approval of the concrete payload, transfer only approved secrets\nusing the installed supported local CLI/file mechanism. For CLI 1.3.0, discovered\n`secrets set --file` supports a local file; do not pass values as positional\narguments or echo/cat the file. An existing file with unrelated keys needs a\nlocal value-isolated transfer of only the approved keys. Do not rewrite secrets\nwhen no changes are approved. Confirm redacted result; a failure stops the build.\n\nThen execute the approved build/deploy in the selected workspace, using explicit\norg/region/config and supported flags. Capture raw results/logs locally only\nthrough a value-safe redaction/allowlist boundary; report identity, exit codes,\nbuild IDs and states without secrets/PII. Wait with bounded status checks until\nthe matching deployment reports ready or a terminal failure/timeout occurs.\nCLI exit zero or command issuance alone does not prove readiness. Inspect bounded,\nredacted build/agent diagnostics on failure. Do not delete or automatically roll\nback. An agent/provider session requires its own explicit approval unless it was\nincluded in the approved payload; ready does not prove a voice conversation.\n\nReturn the immutable approved payload, deployed org/region/agent/version identity,\nsecret action names, build/deploy/readiness outcomes, diagnostics and limitations.\nRecord cleanup instructions for that identity without running deletion. Distinguish\nsource preparation, approved execution, ready deployment and session verification;\npackage rendering or candidate-source conversations do not prove installed skill\nactivation, ChatGPT Work activation or a live deployment. Never mark live Cloud\nacceptance complete while approval or a required prerequisite remains missing.\n"
}