Morning House Report
The house says good morning properly: every zone's state read through the device tools, anything unusual surfaced first with one suggested action apiece, and the boring rest compressed to a line or two — glanceable before the first coffee. Locks the report criteria FIRST (every zone covered, anomalies before normals, a suggested action per oddity, short enough to read standing up), then polls the house, then writes the report — so the one morning the garage door stayed open all night is the morning it gets noticed. Use for morning house checks, daily home status, 'anything wrong with the house', overnight anomaly sweeps, and a glanceable device roundup.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the reporthuisautomaatentry
coverage, anomalies-first ordering, and brevity locked as criteria
Show working prompt
Decide what a good morning report is before reading a single sensor. Step 1: pull the device inventory through the project's home capabilities and note the zones the house actually has — the report must account for every one of them, so nothing quietly falls off the page. Step 2: define what counts as unusual against what is typical for the hour — a door or window open overnight, a battery running low, a sensor that has gone quiet, anything switched on that should not be. Step 3: lock the shape — anything unusual comes FIRST, each oddity with the device, what is off, and one concrete suggested action; the nominal rest is compressed to a line or two, never a device-by-device inventory dump; the whole report reads standing up, before coffee. Step 4: write an acceptance-criteria checklist ('every zone accounted for', 'anomalies surfaced before anything normal', 'each anomaly carries one suggested action', 'every device mentioned exists in the states evidence — nothing invented', 'short and warm'). Call write_task_note with the zone count + checklist and write notes/scope.md. - Poll the housedeveloper
every device's state read and recorded, oddities flagged in the evidence
Show working prompt
Read the whole house, honestly. Step 1: through the project's home capabilities, read the inventory and the current state of every device — every zone, not just the interesting ones. Step 2: record the evidence in notes/states.md — for each device: its name and id, its zone, the state you read, and the battery level or last-seen time where the house reports one — verbatim from the tool responses, never from memory. Step 3: as you go, flag which readings look unusual against the criteria locked in notes/scope.md, and mark each flagged reading with a short why ('open since 23:41', 'battery 9 percent'). Step 4: end the notes with a one-line tally — devices read, anomalies flagged. Call write_task_note with that tally. - Write the morning reportcopywriter
anomalies first with suggested actions, the calm rest in two lines
Show working prompt
Write the report the owner reads standing up. Step 1: open with a 'Needs attention' section — every anomaly from notes/states.md, each as one short line: the device, what is off, and one concrete suggested action ('close it', 'charge it today', 'worth a look'). The most urgent first. If nothing is unusual, say so in one honest, pleasant line instead. Step 2: follow with the all-clear — the rest of the house compressed to a line or two by zone, never a device-by-device dump. Step 3: keep every device name and reading traceable to notes/states.md — the report never mentions a device the evidence does not carry. Step 4: keep it warm and short — headings, plain words, no filler; if it does not read in under a minute, trim it. Write report.md and call write_task_note with the anomaly count and the top item. - Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open report.md, notes/states.md, and notes/scope.md and verify every criterion from the checklist: every zone in the states evidence is accounted for in the report; every anomaly flagged in the evidence appears in the 'Needs attention' section, before anything normal, each with one concrete suggested action; every device the report mentions exists in notes/states.md with the state the report claims — nothing invented, nothing embellished; and the nominal remainder is compressed rather than dumped. Read it once at speed: if it does not scan before coffee, that is a FAIL on brevity. Write PASS/FAIL per criterion; on any failure, name the gap and loop back to report. 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: "report" })` 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.
- morning house report
- how is the house
- anything wrong with the house
- what happened overnight
- house status check
Source
View this craftbook on GitHub · MIT license