Update to Altertable

{
  "description": "Loads data into Altertable through the CLI, HTTP API, DataFrame tooling, object storage, or generated pipelines. Use for file upload, append, upsert, overwrite, bucket synchronization, or deciding between ingestion and an external catalog.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 104
    }
  ],
  "name": "ingest-data",
  "skill_md_contents": "---\nname: ingest-data\ndescription: \"Loads data into Altertable through the CLI, HTTP API, DataFrame tooling, object storage, or generated pipelines. Use for file upload, append, upsert, overwrite, bucket synchronization, or deciding between ingestion and an external catalog.\"\nmetadata:\n  author: Altertable\n---\n\n# Ingest Data\n\nChoose the ingestion path based on where the data lives, whether it must be copied, and how the workflow will run. Read current instructions with `search_docs` when the Altertable MCP server is available; otherwise use [Ingest data](https://altertable.ai/docs/ingest-data).\n\n## Choose the Path\n\n| Situation | Preferred path |\n| --- | --- |\n| Local CSV, JSON, or Parquet file | CLI `upload` |\n| Event-style JSON object or batch | CLI or HTTP `append` |\n| File matched to existing rows by primary key | CLI or HTTP `upsert` |\n| Pandas, Polars, or Ibis data already in memory | DataFrame integration through DuckDB |\n| Files continuously arriving in object storage | Bucket synchronizer |\n| Repeatable extraction and loading from a source | Generated or maintained dlt pipeline |\n| Existing database, warehouse, or object catalog should stay in place | External catalog; query it without copying |\n\nPrefer the Altertable CLI for terminal scripts and CI because profiles handle authentication and `--agent` provides structured output. If the CLI is missing, follow the conditional setup in `use-altertable`. See the [CLI guide](https://altertable.ai/docs/developer-tooling/cli) for installation and authentication, and the [CLI repository](https://github.com/altertable-ai/altertable-cli) for releases and the complete command contract.\n\nPrefer the HTTP API for application-controlled ingestion. Use an SDK when it already handles retries, batching, and the relevant data structure.\n\n## Write Semantics\n\n- `append` adds records and can create or evolve an event-style destination according to the current API behavior.\n- `upload --mode create` creates a destination from a file.\n- `upload --mode append` adds file rows to an existing table.\n- `upload --mode overwrite` replaces table contents; use it only when replacement is explicit.\n- `upsert` matches existing rows by the supplied primary key and requires a stable, unique key.\n\nInspect the current CLI help or API schema before constructing a request. Do not guess flags, payload limits, supported formats, or asynchronous behavior from an old example.\n\n## Workflow\n\n1. Confirm the organization, environment, destination `catalog.schema.table`, source format, expected row count, and desired write semantics.\n2. Inspect the existing destination schema when it exists. Check names, types, nullability, primary-key suitability, and column ordering behavior.\n3. Decide whether federation through an external catalog is preferable to copying the data.\n4. Execute the smallest bounded write. Never expose credentials in commands, logs, or chat.\n5. For asynchronous append, upload, upsert, synchronization, or pipeline work, poll the returned job or task identifier until terminal state.\n6. Verify row counts, schema, representative non-sensitive values, and duplicate behavior with a bounded query.\n\nWhen generating a dlt workflow, use the documented `generate_dlt_pipeline` tool if available, inspect its output, request secrets through the platform's secret flow, and test against a non-production destination first.\n\n## Guardrails\n\n- Do not infer overwrite intent from “refresh,” “reload,” or a filename collision.\n- Do not use mutable business attributes as an upsert key.\n- Do not load sensitive fields merely because they exist in the source.\n- Keep large writes in batches that fit current transaction and memory limits.\n- Preserve source timestamps and stable identifiers needed for idempotency.\n- Report partial or rejected rows rather than treating an accepted job as verified data.\n"
}