Update to Logtura

{
  "description": "Configure and operate the open-source Logtura CLI, library, and forwarder for Cloudflare, Fly.io, Railway, Vercel, Supabase, and supported destinations. Use for standalone log forwarding, source and filter changes, forwarder deployment, delivery verification, or provider contributions. A Logtura account is optional; use website synchronization only when the user requests a linked deployment.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 87
    },
    {
      "relative_path": "references/contributing.md",
      "size_in_bytes": 1280
    },
    {
      "relative_path": "references/linked-service.md",
      "size_in_bytes": 3038
    },
    {
      "relative_path": "references/provider-capabilities.json",
      "size_in_bytes": 5949
    },
    {
      "relative_path": "references/providers/cloudflare.md",
      "size_in_bytes": 1896
    },
    {
      "relative_path": "references/providers/fly.md",
      "size_in_bytes": 1641
    },
    {
      "relative_path": "references/providers/railway.md",
      "size_in_bytes": 1622
    },
    {
      "relative_path": "references/providers/supabase.md",
      "size_in_bytes": 1722
    },
    {
      "relative_path": "references/providers/vercel.md",
      "size_in_bytes": 1440
    },
    {
      "relative_path": "references/standalone.md",
      "size_in_bytes": 2823
    },
    {
      "relative_path": "references/verify-and-recover.md",
      "size_in_bytes": 2037
    }
  ],
  "name": "logtura",
  "skill_md_contents": "---\nname: logtura\ndescription: Configure and operate the open-source Logtura CLI, library, and forwarder for Cloudflare, Fly.io, Railway, Vercel, Supabase, and supported destinations. Use for standalone log forwarding, source and filter changes, forwarder deployment, delivery verification, or provider contributions. A Logtura account is optional; use website synchronization only when the user requests a linked deployment.\nlicense: Apache-2.0\nmetadata:\n  requires: Local shell, Node.js 22+, Logtura CLI 0.3.6+; provider credentials for discovery; Docker or Fly for deployment.\n---\n\n# Logtura onboarding\n\nTake the user's project from source selection to verified log delivery. Logtura's\nCLI, library, and forwarder work without a Logtura account. Website login is only\nneeded when the user chooses a service-linked deployment.\n\n## Choose the workflow\n\n- For a new standalone installation, read [standalone.md](references/standalone.md).\n- For an existing website deployment, read [linked-service.md](references/linked-service.md)\n  before editing. Preserve the deployment and graph identities.\n- For delivery verification or recovery, read [verify-and-recover.md](references/verify-and-recover.md).\n- Read the relevant provider recipe when setting up or connecting that host:\n  [Cloudflare](references/providers/cloudflare.md), [Fly](references/providers/fly.md),\n  [Railway](references/providers/railway.md), [Vercel](references/providers/vercel.md),\n  or [Supabase](references/providers/supabase.md).\n- [provider-capabilities.json](references/provider-capabilities.json) is the bundled\n  release's catalog. Prefer `logtura providers list --json` from the installed CLI\n  when it is newer. For contributing an unsupported provider, read\n  [contributing.md](references/contributing.md).\n\n## Establish the starting point\n\nInspect the project and any existing `logt.yaml` or `logtura.yaml`. Identify the\nrequested source hosts/resources, destination, and existing forwarder. Keep the\nuser's chosen platform and mode. Reuse working credentials and project setup.\n\nCheck `logtura --help` and required tools. If the CLI is missing, install\n`@logtura/cli` (0.3.6 or later) using the project's package manager or run its `logtura` executable\nthrough that package manager. Node.js 22+ is required. Installing this skill does\nnot install the CLI. CLI package versions can be inspected through the package\nmanager; don't assume Logtura implements `--version`.\n\nFor a new project, follow the provider's native setup flow first. Record the\nactual account/project/environment/resource IDs from its output and Logtura\ndiscovery. Creating a source project and deploying the Logtura forwarder are\nseparate operations: source support for Railway or Vercel does not imply a\n`logtura deploy railway` or `logtura deploy vercel` command.\n\n## Configure and validate\n\nUse shorthand CLI commands for a standalone shorthand config. A pulled\n`kind: logtura.deployment` document is a portable graph: use graph edit/selection\ncommands, not shorthand `connect`/`source add` commands.\n\nReview discovered sources and retain only the requested selections. Configure\nthe destination and filters deliberately; don't forward every discovered\nresource merely because discovery returned it. Validate before generating the\nbundle. Use `-c <file>` when operating on a nondefault config.\n\nPrefer secure prompts or existing environment variables to tokens in command\narguments. Commit environment references rather than secrets. Bundles and\nprivate graph-edit payloads can contain secrets; preserve their file permissions\nand don't attach them to issues, transcripts, or public artifacts.\n\nKeep IDs when changing an existing configuration. Renaming a label or adding a\nsite must not create a second deployment, replace unrelated selections, or reset\nthe runtime checkpoint. See the linked workflow for manifest synchronization.\n\n## Deploy and prove delivery\n\nChoose an available forwarder target. The CLI has a native Fly deployment path;\na standalone generated Docker bundle can run on a Docker host. Follow the user's\nexisting deployment method when updating a forwarder.\n\nEmit a uniquely identifiable test event from the selected source, verify it\narrives at the destination, and inspect component errors/metrics. Building a\nvalid bundle or seeing a successful deploy response does not prove delivery.\nTest filters with both a matching and a nonmatching event when changing them.\n\nFor linked deployments, verify both the accepted website configuration and the\nforwarder's applied configuration/heartbeat. A successful `push` does not by\nitself prove that a self-managed process is running the new bundle.\n\nUse the CLI's pending-operation status and recovery paths after interruption.\nRetry only when it is safe to resume the recorded operation. Don't repeat\nproject creation or deployment creation to work around a missing receipt.\n\n## Report the result\n\nReport source selections, destination, config location, forwarder/deployment\nidentity, and actual verification evidence. Include any missing credential,\nunsupported capability, or unverified live-provider step. Do not claim a live\nhost workflow was tested when only a fixture or generated config was checked.\n\nThe skill follows the user's task authorization and the client's permissions.\nIt does not authorize unrelated resource creation, purchases, or messages to\nothers. Continue already-authorized work without adding repetitive approvals.\n"
}