Case Study 3: A Personal Automation Utility

The idea

A purely selfish one: a script that every morning grabs the day's calendar events and the weather, formats a one-line summary, and sends it to a personal Telegram chat. The point was to stop opening three apps before coffee.

The spec

A scheduled job that runs at 7am my timezone. It reads today's
events from my calendar, fetches the forecast for my city, and
sends one Telegram message like: "3 events today, first at 9:30.
High 24C, rain after 4pm." If any source fails, still send what
you have and note what's missing.

That last sentence — degrade gracefully instead of crashing — is the kind of behavior you have to ask for explicitly. The AI won't assume it. Left unsaid, the default a model reaches for is "throw on error," which for a 7am cron job means a silent morning and no clue why.

The stack

A single scheduled serverless function (a Cron-triggered Worker) so there's no machine to keep running. The whole thing is one file plus a schedule. For a personal utility this matters more than it sounds: anything with a server to babysit is a thing you will eventually forget to pay for, and the project dies of neglect rather than failure.

The key prompts

Write a Cloudflare Worker triggered by cron at 7am Asia/Seoul.
It calls a weather API and a calendar API (I'll provide both
tokens as secrets), builds a one-line summary, and POSTs it to
the Telegram Bot API. Wrap each external call in try/catch so one
failure doesn't kill the message. Read every token from env.

When we wanted to iterate on wording without waiting for 7am:

Add a manual trigger: if the Worker is hit with a GET request and
a ?test=1 query param, run the same logic immediately and return
the message text in the response instead of sending it. Keep this
behind a secret token so only I can trigger it.

That test trigger saved us from a brutal feedback loop — we could see the output on demand instead of once per day. It's a general move worth stealing: anytime your code runs on a schedule, build yourself a way to run it now, on demand, before you commit to waiting on the clock.

The obstacle

The Telegram message arrived, but the times were wrong: events showed in UTC, not Korean time. The weather was fine. We isolated it:

Calendar times are 9 hours off — showing UTC, not Asia/Seoul.
The weather time ("rain after 4pm") is correct. Here's how I
format both: [pasted]. Fix only the calendar formatting and tell
me why the weather path was already right.

The AI explained the weather API (Application Programming Interface — the doorway one service exposes for another program to fetch its data) already returned localized strings while the calendar API returned UTC timestamps we were printing raw. It added a single timezone conversion at the calendar formatting step. Scoping the fix to "only the calendar path" stopped it from rewriting the working weather code — a common way AI fixes break things that were fine. The second half of that prompt — "tell me why the weather path was already right" — did double duty: it gave us the actual root cause instead of a guess, and it forced the AI to articulate the difference so its fix didn't accidentally "harmonize" the two paths into one broken one.

The launch

"Launch" here just meant deploying the Worker, setting the cron schedule, and adding the API tokens as encrypted secrets. We hit the ?test=1 endpoint a few times to confirm the message read well, then left it. It's run every morning since — and the graceful-degradation line proved its worth a month later, when the weather API had an outage and the message still arrived, just without the forecast.