Update to Altertable

{
  "description": "Adds or changes Altertable Product Analytics instrumentation in application code. Use for SDK setup, event tracking, user identification, traits, consent, session reset, page or screen tracking, and identity aliasing.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 135
    }
  ],
  "name": "instrument-product-analytics",
  "skill_md_contents": "---\nname: instrument-product-analytics\ndescription: \"Adds or changes Altertable Product Analytics instrumentation in application code. Use for SDK setup, event tracking, user identification, traits, consent, session reset, page or screen tracking, and identity aliasing.\"\n---\n\n# Instrument Product Analytics\n\nImplement the smallest durable instrumentation change using the project's installed Altertable SDK and types as the API authority.\n\n## Workflow\n\n1. Inspect the application stack, installed package and version, shared client initialization, authentication lifecycle, consent model, and existing event conventions.\n2. Read the current Product Analytics ingestion guide with `search_docs` or at [Product Analytics ingestion](https://altertable.ai/docs/ingest-data/product-analytics).\n3. Define the stable event name, identity context, and only the properties needed for filtering, grouping, or decisions.\n4. Instrument the successful business outcome at its source of truth.\n5. Exercise success, failure, anonymous-to-known, logout, and consent paths relevant to the change.\n6. When runtime access is available, verify a non-production event in the intended environment.\n\nUse the direct Product Analytics HTTP API only when an SDK is unavailable or intentionally unsuitable. Direct requests must include the target environment; use SDK batching and retry behavior rather than rebuilding it when available.\n\n## Identity Rules\n\n- Track server-owned outcomes such as completed billing changes from the backend.\n- Identify a known user when authenticated state is established or restored.\n- Use a stable identifier rather than mutable profile data such as email.\n- Reset client identity on logout so the next person's events are not joined to the prior user.\n- Use aliasing only for an explicit identifier merge or migration; ordinary login and signup use identification.\n- Preserve established anonymous-ID behavior across page reloads and sessions.\n\n## Safety\n\n- Never send secrets, payment details, passwords, or regulated sensitive data as properties or traits.\n- Do not hardcode environment credentials.\n- Do not broaden tracking beyond the requested behavior or bypass consent.\n- Do not initialize a second client when the application already has one.\n- Do not rename an established event or property without checking downstream consumers.\n- Confirm successful actions emit once and failed or cancelled actions do not emit success events.\n\nUse the `analyze-product-behavior` skill to inspect events already stored in Altertable.\n"
}