Update to Keboola

{
  "description": "Create or change a Snowflake or BigQuery SQL transformation in Keboola. Use when the user wants to turn a query into a saved transformation, build a new table from existing Keboola tables, or edit the SQL of an existing transformation.",
  "included_files": [],
  "name": "build-sql-transformation",
  "skill_md_contents": "---\nname: build-sql-transformation\ndescription: Create or change a Snowflake or BigQuery SQL transformation in Keboola. Use when the user wants to turn a query into a saved transformation, build a new table from existing Keboola tables, or edit the SQL of an existing transformation.\n---\n\n# Build a SQL transformation\n\nCreate a new SQL transformation, or update an existing one, in the one project the user confirms.\n\n## Input\n\nWhat the transformation should produce, from which tables, and whether to run it once it is saved. For an\nexisting transformation, its name or ID.\n\n## Steps\n\n1. **Pick the project.** Call `get_accessible_projects` (with `with_llm_instruction=true` on the first call in the\n   conversation). Show the projects and ask the user which one the transformation belongs in. Never pick a project\n   on your own, even when only one is listed: confirm it.\n   Do this even when the session looks scoped already or a data tool would work without it: this plugin\n   always narrows the session to the projects the user confirms. If `get_accessible_projects` fails because\n   no programmatic token is present, the login is bound to one project: confirm it with the user and skip\n   step 2.\n2. **Scope the session to that project.** Call `set_project_scope` with `project_ids=[<the confirmed id>]`. This\n   must happen before any write. If the result carries a non-null `scope_token`, pass it on every later tool call.\n   Every write below also passes the confirmed id as `project_id`: other conversations on the same login share the\n   scope, and a scope they moved makes the write fail instead of landing in another project.\n3. **Get context.** Call `get_project_info` with `project_id=<the confirmed id>`. Note the SQL dialect (Snowflake\n   or BigQuery). Python, R and DuckDB transformations are out of scope for this skill; say so and stop. If its\n   `toolset_restrictions` say only read-only tools are available, tell the user they cannot save transformations\n   in this project and stop.\n4. **Find the inputs.** Use `search` with `item_types=[\"table\"]` for the source tables, then `get_tables` with\n   `table_ids=[...]` for their `fullyQualifiedName` and column `quotedName` values.\n5. **Prototype the SQL.** Run the `SELECT` part through `query_data` with a small `LIMIT` and show the user sample\n   rows. Fix errors here, before anything is saved.\n6. **Save it.**\n   - New transformation: call `create_sql_transformation` with `project_id=<the confirmed id>`. Reference input\n     tables by fully qualified name; create output tables with the dialect's delimited plain name\n     (`\"daily_orders\"` on Snowflake, a backticked name on BigQuery), never a fully qualified one, and list the\n     names without delimiters in `created_table_names=[...]`. Give it a name and description that state its\n     purpose.\n   - Existing transformation: find it with `search` and `item_types=[\"transformation\"]`, read it with\n     `get_configs` and `configs=[...]` to get the `block_id` and `code_id` values, then call\n     `update_sql_transformation` with `project_id=<the confirmed id>`, `configuration_id=...`,\n     `parameter_updates=[...]` (operations such as `set_code` or `str_replace`) and `change_description=...`. A\n     `storage=...` value replaces all mappings: include every mapping you want to keep.\n7. **Run it, if the user asked.** Ask before running. Call `run_job` with `project_id=<the confirmed id>` and\n   the transformation's `component_id=...` and `configuration_id=...`, then poll `get_jobs` with `job_ids=[...]`\n   until the job ends. On failure, continue with the `debug-failed-job` skill.\n8. **Report.** Give the transformation name, the output tables, the job result and the links the tools returned.\n\n## Rules\n\n- No write before step 2. If the user switches projects mid-conversation, go back to step 1.\n- Confirm with the user before overwriting SQL in an existing transformation and before every `run_job`.\n- Use the dialect's delimited identifiers everywhere and never mix quoting styles in one statement.\n- A destructive schema change (dropping, renaming or retyping a column) needs the output table removed before the\n  next run. Tell the user; `query_data` runs in a read-only workspace and cannot drop or change Storage tables.\n"
}