Write an Automation Recipe
Turn 'I wish the house would...' into an inspectable, versioned automation: triggers and actions that name real devices from the house's own inventory, a dry run through the device tools before anything is armed, and a manual override always written in. Locks the owner's intent and the safety rules FIRST (nothing that heats or locks runs unattended without a failsafe, an override path is mandatory, dry-run before arm), then drafts the recipe, then proves it against the devices — so the house only ever does what was actually asked, and never anything it cannot be talked out of. Use for home automations, 'make the lights do X', schedules and scenes, sensor-triggered routines, and wiring up a new smart-home behavior.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the wishhuisautomaatentry
the owner's intent, the real device inventory, and the safety rules locked
Show working prompt
Understand the wish and the house before writing a single trigger. Step 1: restate the owner's intent in one plain sentence — when should what happen, and when should it NOT — and confirm it with them if anything is ambiguous. Step 2: pull the device inventory through the project's home capabilities and list the devices this automation actually needs: the sensors that will trigger it, the devices it will act on, each with its exact inventory id and current state. If a device the wish assumes does not exist in the inventory, say so now — never plan around an invented device. Step 3: lock the safety rules — nothing that heats, locks, or opens runs unattended without a stated failsafe; every automation carries a manual override the owner can flip without ceremony; and no recipe is armed before a dry run has exercised it against the devices. Step 4: write an acceptance-criteria checklist ('every device in the recipe exists in the inventory, by exact id', 'trigger, conditions, and actions are all present and specific', 'a manual override is written into the recipe', 'the dry run exercised every action with the tool responses recorded', 'the install notes say how to arm it and how to stop it'). Call write_task_note with the intent sentence + the devices involved + the checklist and write notes/scope.md. - Draft the recipedeveloper
the automation as one inspectable JSON file under automations/
Show working prompt
Write the automation down as a file someone can read, diff, and version. Step 1: derive a short lowercase-kebab slug from the automation's name and write the recipe to automations/<slug>.json — one JSON object with a name, a plain-language summary, the trigger (what starts it), the conditions (what must also be true), the actions (what happens, in order), and the override (how a human stops or bypasses it, always present). Step 2: reference every device by its exact inventory id from notes/scope.md — the id the house actually answers to, not a nickname. Step 3: keep every field concrete: a trigger names its sensor and the state change, a condition names what it checks, an action names the device and the state it sets. Step 4: re-read the file once as JSON — valid, complete, no placeholder values left. Call write_task_note with the recipe path and a one-line description of trigger, conditions, actions, and override.
- Dry-run the recipedeveloper
every trigger and action exercised against the devices, evidence on file
Show working prompt
Prove the recipe against the real device inventory before anyone arms it. Step 1: for every device the recipe references, read its current state through the project's home capabilities and confirm the device answers — a device that does not exist or does not respond sends you back to the draft, not onward. Step 2: exercise each action through the device tools' dry-run path, so the intended state change is checked without actually switching anything in the house. Step 3: record the evidence in notes/dry-run.md — for each device: its id, the state you read, the dry-run response you got, verbatim — plus a short verdict per action (would fire as intended, or what was off). Step 4: if any action came back wrong, fix the recipe first and dry-run again; the notes must describe the run that matches the final recipe. Call write_task_note with the device count exercised and the verdict.
- Write the install notescopywriter
what it does, how to arm it, how to stop it, what the dry run proved
Show working prompt
Write the install notes the owner will actually read. Step 1: open with one warm paragraph saying what the automation does and when — the intent sentence from notes/scope.md, in the owner's language. Step 2: list the devices it touches, each with its friendly name and inventory id, and where the recipe file lives. Step 3: say how to arm it and — just as prominently — how to stop or override it: the manual override path from the recipe, spelled out so it works at 2am. Step 4: summarize what the dry run proved, citing the evidence in notes/dry-run.md — which devices answered, which actions were exercised, and that nothing was actually switched. Step 5: close with what to watch the first week and the one or two ways this automation could misbehave (the safety rules from scope, made concrete). Write report.md and call write_task_note with a one-line DONE summary.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open automations/, notes/dry-run.md, report.md, and notes/scope.md and verify every criterion from the checklist: the recipe file parses as JSON and carries a trigger, conditions, actions, and a manual override; every device id in the recipe appears in the inventory evidence gathered during scope and dry-run — no invented devices; the dry-run notes show every action exercised with real tool responses recorded, not paraphrased; and the install notes say how to arm the automation, how to stop it, and what the dry run proved. Write PASS/FAIL per criterion; on any failure, name the field or device that is wrong and loop back to draft. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "draft" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- set up an automation
- make the house do
- automate the lights
- write an automation recipe
- when I get home, turn on
Source
View this craftbook on GitHub · MIT license