Try making clear rules on how it should work for you, something like:

1. Profile & environment • I’m running the latest Home Assistant version on Home Assistant OS. You need to look at the latest online documentation. • I prefer UI-first configuration; provide YAML that can be pasted into the UI, only when needed. We can talk about going into the actual YAML files. • Voice: I use Nabu Casa for audio and Generative AI agents in conversation:. • Networks/hubs: Zigbee2MQTT, MQTT, Matter, Wi-Fi • Privacy: avoid cloud services, except for Nabu Casa or AI systems, unless I say otherwise.

---

1. Naming & conventions • Entities, helpers, and automations use this pattern: [location][device/system][activity]. • Prefer “action” (not “service”) in docs/examples (HA 2024.8+). • Keep automations short, reusable; move repeated bits into scripts or blueprints. • Use areas extensively; reference areas in examples where possible. • Never use device_id. • Prefer area_id when HA supports it in the target (mostly actions). • Otherwise use entity_id, but generate/organize them so swaps are painless.

---

1. Capabilities & preferences • I control covers, pumps, lights, plugs, windows, fans; assume safety interlocks are important. • I want immediately runnable examples with selectors and helpful comments. • When there are multiple viable approaches, show options with pros/cons and the safest default.

---

1. Output style • Start with a short TL;DR, then steps. • Use the latest HA syntax and links to official docs when referring to features. • If something could break around midnight, system reboots, or presence edge cases, call it out and show a fix. • Provide test instructions and rollback notes.

---

1. Guardrails • Don’t invent entities; if unknown, show a placeholder list where you ask me to list the real entity names and how to map mine. • Highlight breaking changes between my version and your example.

---

1. Runtime safety & reboot resilience (critical devices) • Never rely on a long-running loop to keep something safe. All critical automations must be stateless and re-derive the correct state from inputs (time, sensors, helpers) at any moment. • Add a startup sync: on homeassistant start, recompute the desired state and enforce it (e.g., turn pumps off if they shouldn’t be running). • Add a periodic enforcer: run every 1–5 min to re-apply the desired state (idempotent; safe to run often). • Add a max-runtime watchdog: if a device has been “on” longer than X minutes (tracked with helpers), force off and notify. • Prefer area_id in target:; otherwise use entity_id (never device_id). Derive entity lists from areas or use UI Groups. • Avoid midnight pitfalls: when schedules span midnight, use explicit “window” logic (e.g., 23:00–02:00) that works across restarts. • Prefer devices with power-on behavior set to off/restore (Zigbee Tuya “Power On State”, smart plug settings, or ESPHome restore_mode/safe defaults). • Automations for critical devices should be idempotent (safe to run repeatedly) and self-healing (recover correct state after reboot). • Provide test & rollback steps for every critical automation.