Update to Apilio

{
  "description": "Build a new Apilio automation from a plain-language description (\"turn the heating down when nobody is home\", \"notify me at 7am on weekdays\"). Use when the user wants to create, extend, or restructure a logicblock.",
  "included_files": [],
  "name": "build-automation",
  "skill_md_contents": "---\nname: build-automation\ndescription: Build a new Apilio automation from a plain-language description (\"turn the heating down when nobody is home\", \"notify me at 7am on weekdays\"). Use when the user wants to create, extend, or restructure a logicblock.\n---\n\n# Building an Apilio automation\n\nAn automation is a **logicblock**: a set of conditions combined by boolean logic, plus\nactions that run when the result is true (`positive`) or false (`negative`).\n\nConditions and the logicblock are created separately, and conditions must exist first —\n`create_logicblock` links them by UUID.\n\n## Workflow\n\n1. **Discover what exists.** `list_devices` (optionally `service:`), then\n   `get_device_attributes` on the device you need — it returns the attribute IDs that\n   conditions require and the `available_actions` that actions accept. Use\n   `list_variables` for user-defined variables.\n\n2. **Restate the automation as events + guards before creating anything.** Present the plan\n   and wait for approval.\n\n3. **Create the conditions.** `create_device_condition` for device state,\n   `create_time_condition` for schedules and time windows. Keep each returned UUID.\n\n4. **Create the logicblock.** `create_logicblock`, passing the UUIDs in the parameter\n   matching each condition's type: `condition_uuids` (variable conditions),\n   `timecondition_uuids`, `tuyacondition_uuids` (device conditions).\n\n5. **Add the actions.** `add_tado_action`, `add_ewelink_action`, `add_apilio_action`,\n   `add_alexa_action`, `add_ifttt_action`, or `add_action_to_logicblock` for an email\n   notification. Each takes `action_group: \"positive\" | \"negative\"`.\n\n6. **Read it back** with `get_logicblock` and summarise it for the user.\n\n## Decisions that matter\n\n**Mark every condition that is an event, and only those.** `triggering: true` means \"when\nthis condition's *result* flips, re-evaluate the logicblock\". Conditions that merely qualify\nwhen the automation may act — guards — stay `triggering: false`.\n\n- No triggering condition → the automation never fires on its own.\n- A guard marked triggering → the automation fires on changes the user didn't ask about.\n- An event left non-triggering → that event is silently missed.\n\nFor \"turn on the fan when the temperature goes above 25°C but only in the evening\", the\ntemperature condition is the event and the evening time frame is a guard. But for \"notify me\nwhen motion is detected or the door opens\", **both** conditions are events and both must\ntrigger — otherwise one of them never fires the automation.\n\n(`trigger_on_content_update` is a separate, noisier setting: it re-evaluates on every value\nupdate rather than only when the condition's result changes.)\n\nTime *events* (`timeevent_absolute`, `timeevent_at_sunrise`, `timeevent_at_sunset`) are\nalways triggering — that is what they are for. Time *frames* (`timeframe_*`) are usually\npre-conditions.\n\n**Prefer one logicblock over several.** Combine conditions with\n`condition_logic: \"complex\"` and a `condition_expression` using AND, OR, XOR, NOR, NAND —\ne.g. `OR(motion_detected,AND(door_open,evening_hours))`, where the names are the condition\nnames. Nested expressions are a premium feature; the response reports\n`complex_conditions_available`. Fall back to `condition_logic: \"and\"` when it isn't\navailable.\n\n**Use the negative branch instead of an inverse logicblock.** \"Heating on when home, off\nwhen away\" is one logicblock with a positive and a negative action, not two logicblocks.\n\n## Limits and gaps\n\n- Max 15 conditions and 20 actions per logicblock; condition and logicblock names are max\n  50 characters and unique per user.\n- Tuya, Philips Hue and HTTP actions cannot be created over MCP. Add an email notification\n  action as a placeholder and tell the user to swap it in the Apilio web app.\n- Variable conditions cannot be created over MCP either — only linked by UUID if they\n  already exist.\n"
}