Update to Keboola

{
  "description": "Find out why a Keboola job failed and propose a fix. Use when the user says a Keboola job, extractor, transformation, writer or flow failed or errored, or asks why their pipeline is red.",
  "included_files": [],
  "name": "debug-failed-job",
  "skill_md_contents": "---\nname: debug-failed-job\ndescription: Find out why a Keboola job failed and propose a fix. Use when the user says a Keboola job, extractor, transformation, writer or flow failed or errored, or asks why their pipeline is red.\n---\n\n# Debug a failed job\n\nFind the failed job, read its error and logs, explain the cause, and fix it only after the user agrees.\n\n## Input\n\nA job ID, a configuration or flow name, or just \"my last job failed\". Ask for nothing more until step 4 shows\nwhether it is needed.\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) and ask the user which project the job ran in. Do not guess.\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 in step 7. If the result carries a non-null `scope_token`, pass it on every later\n   tool call. Every write in step 7 also passes the confirmed id as `project_id`: other conversations on the same\n   login share the scope, and a scope they moved makes the write fail instead of landing in another project.\n3. **Find the job.**\n   - Known job ID: go to step 4.\n   - Known configuration or flow name: find its ID with `search` (`item_types=[\"configuration\", \"transformation\",\n     \"flow\"]`), then call `get_jobs` with `job_ids=[]`, `status=\"error\"`, `component_id=...` and `config_id=...`.\n   - Nothing known: call `get_jobs` with `job_ids=[]`, `status=\"error\"` and `limit=10`, and ask the user which job\n     they mean if more than one is recent.\n4. **Read the failure.** Call `get_jobs` with `job_ids=[\"<id>\"]`, `include_logs=true` and\n   `log_event_types=[\"error\", \"warn\"]`. If the error event is not enough, call again with a larger\n   `log_tail_lines=...` and no event type filter.\n5. **Read what ran.** Call `get_configs` with `configs=[...]` for the job's configuration. For a flow job, call\n   `get_flows` with `flow_ids=[...]` and find the failed task, then repeat steps 3 and 4 for that task's job.\n6. **Explain.** Name the cause in one or two sentences and quote the error line. Typical causes: an SQL error in\n   a transformation (check columns with `get_tables` and reproduce the failing `SELECT` with `query_data`), a\n   missing input table, expired credentials of an extractor or writer, or a schema change in the output table.\n   Use `docs_query` for component-specific errors. Propose a fix.\n7. **Fix, only on request.** Ask before changing anything.\n   - SQL transformation: `update_sql_transformation` with `project_id=<the confirmed id>`, its\n     `configuration_id=...`, the `parameter_updates=[...]` and a `change_description=...`.\n   - Flow: `modify_flow` with `project_id=<the confirmed id>`, its `configuration_id=...`, the `flow_type=...` it\n     already has and a `change_description=...`.\n   - Another component: `get_components` for its schema. When the fix belongs in a configuration row, call\n     `update_config_row` with `project_id=<the confirmed id>`, `component_id=...`, `configuration_id=...`,\n     `configuration_row_id=...` and a `change_description=...`. Otherwise call `update_config` with\n     `project_id=<the confirmed id>`, `component_id=...`, `configuration_id=...` and a `change_description=...`.\n   - Expired OAuth credentials need the user: create a link with `create_oauth_url`,\n     `project_id=<the confirmed id>`, `component_id=...` and `config_id=...`, and ask them to reauthorize.\n\n   Then, with the user's consent, call `run_job` with `project_id=<the confirmed id>`, `component_id=...` and\n   `configuration_id=...`, and check the new job with `get_jobs`. If the server refuses a write because the user's\n   role is read-only, give the user the proposed fix to pass to a project admin.\n\n## Rules\n\n- No write before step 2, and no write at all without the user's go-ahead.\n- Never rerun a job just to see whether it fails again; read the logs first.\n- Report what the logs say. If they do not show a cause, say so and list what you checked.\n"
}