Update to Paprika for Kubernetes

{
  "description": "Connect or reconnect the Paprika plugin using the client's native OAuth flow, discover its read tools, and verify fleet access. Use only when the user asks to set up Paprika, sign in, or change granted scopes.",
  "included_files": [],
  "name": "paprika-setup",
  "skill_md_contents": "---\nname: paprika-setup\ndescription: Connect or reconnect the Paprika plugin using the client's native OAuth flow, discover its read tools, and verify fleet access. Use only when the user asks to set up Paprika, sign in, or change granted scopes.\n---\n\n# Connect Paprika\n\nUse the user-selected Paprika instance and its configured HTTPS `/mcp` endpoint.\nThe review example is `https://paprika-demo.benebsworth.com/mcp`; users select\ntheir own deployment during setup. Do not treat the example as their fleet.\nIf Paprika tools are already available, call `fleet_status` once to verify\naccess. If authentication is required, open the client's native MCP OAuth\nconnection flow and let the user sign in and grant scopes there. Do not ask for\npasted credentials, bearer tokens, kubeconfigs, or secrets; do not store them\nin the package or chat.\n\nStart with `paprika:read` for fleet/application inspection. Add `paprika:write`\nonly when the user wants delivery actions. Scope grants and Paprika's RBAC are\nboth required; write access does not imply read access.\n\nFor the Codex CLI, add the selected HTTPS endpoint with `codex mcp add`\nunder a distinct connection name, then use `codex mcp login` with\n`--scopes paprika:read`. Obtain the endpoint from the user’s existing\nconfiguration or their explicit choice; never substitute another instance.\n\nFor a user-requested write connection, use the native consent flow with both\nscopes (or `codex mcp login paprika_hosted --scopes paprika:read,paprika:write`).\nIn desktop clients use their MCP/plugin connection UI. If plugin installation\nor reloading is needed, follow the host's supported flow; adding a raw MCP\nendpoint alone may not load these packaged skills or an interactive view.\n\nAfter connection, discover tools and call `fleet_status` once. Report the\nreturned fleet data or the actual error. Offer `open_fleet` when available in\na host supporting MCP Apps. If the deployed server lacks the new tools or the\nhost lacks Extensions support, retain normal read tools and state what remains\nunverified. Editing this source package does not update the remote deployment.\n\n## Connection diagnostics\n\nInstallation, account-owned cloud registration, OAuth, callable tools and a successful API read are separate checks. Verify the intended host account through supported native identity UI; a service email may differ. A connected computer or local CLI does not prove cloud access. If authoritative host evidence confirms a mismatched registration, say \"This MCP was registered for another account. Connect it in this account.\" Otherwise mark account binding unverified; missing tools alone are not proof of expired credentials. When the user requests a new or renewed connection, use native OAuth with the requested permissions, then verify an actual read in the intended cloud chat. A 403 is a denied operation; do not expand scopes or create credentials to repair it. Do not extract tokens, copy another account’s App ID, broaden grants, or enable tracing to test setup.\n"
}