Update to Keboola

{
  "description": "Create or change a Keboola flow that runs extractors, transformations and writers in order, optionally on a schedule. Use when the user wants to orchestrate, chain or schedule existing Keboola configurations.",
  "included_files": [],
  "name": "build-flow",
  "skill_md_contents": "---\nname: build-flow\ndescription: Create or change a Keboola flow that runs extractors, transformations and writers in order, optionally on a schedule. Use when the user wants to orchestrate, chain or schedule existing Keboola configurations.\n---\n\n# Build a flow\n\nCreate a flow from existing configurations, or change an existing flow, in the one project the user confirms.\n\n## Input\n\nWhich configurations to run, in what order, and whether the flow needs a schedule. For an existing flow, its name\nor 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) and ask the user which project the flow belongs in. Never pick a project on your own: 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>`. It says whether conditional\n   flows are enabled in the project, and its `toolset_restrictions` say whether the user's role may set schedules.\n   If they say only read-only tools are available, tell the user they cannot create flows in this project and stop.\n4. **Collect the tasks.** Find every configuration the flow should run with `search`\n   (`item_types=[\"configuration\", \"transformation\"]`) and confirm the list with the user. Each task needs a\n   component ID and a configuration ID; use `get_configs` with `configs=[...]` when a search hit does not show\n   them. Do not create the configurations here; a missing SQL transformation is built with the\n   `build-sql-transformation` skill first. A data app is the exception: find it with `get_data_apps` and add it\n   as a `keboola.data-app-control` task with `configData: {\"parameters\": {\"appId\": \"<data_app_id>\"}}` and no\n   configuration ID.\n5. **Load the schema.** Call `get_flow_schema` with `flow_type=\"keboola.flow\"` when conditional flows are enabled,\n   otherwise `flow_type=\"keboola.orchestrator\"`. Call `get_flow_examples` with the same type if you have not seen\n   one in this conversation.\n6. **Show the plan.** List the phases, the tasks in each phase and their order. Tasks in one phase run in\n   parallel; phases run in order. Wait for the user to agree.\n7. **Create or update.**\n   - New flow: call `create_conditional_flow` with `project_id=<the confirmed id>` for `keboola.flow`, or\n     `create_flow` with `project_id=<the confirmed id>` for `keboola.orchestrator`. Give every phase and task an\n     `id` and a `name`.\n   - Existing flow: find it with `search` and `item_types=[\"flow\"]`, read it with `get_flows` and\n     `flow_ids=[...]`, then call `modify_flow` with `project_id=<the confirmed id>`, its\n     `configuration_id=...`, the `flow_type=...` it already has, a `change_description=...` and only the fields\n     that change.\n8. **Schedule, if asked.** Call `modify_flow` with `project_id=<the confirmed id>` and `schedules=[...]` for the\n   schedule the user asked for. Confirm the cron expression and time zone with the user first. If\n   `toolset_restrictions` from step 3 say the role cannot set schedules, tell the user and skip this step.\n9. **Run, if asked.** Ask before running. Call `run_job` with `project_id=<the confirmed id>`, the flow's\n   `component_id=...` and `configuration_id=...`, then follow it with `get_jobs`. On failure, continue with the\n   `debug-failed-job` skill.\n10. **Report.** Give the flow name, its phases, the schedule 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- Add retries, conditions or `continueOnFailure` only when the user asks for them; a failed task already stops\n  the flow.\n- Do not change the type of an existing flow.\n"
}