routine-from-chat

Create a routine from chat

When the guardian describes something they want to happen automatically, turn that intent into a routine — without making them learn event names, RRULEs, timezones, filters, or JSON. They speak in their language; you map it to a concrete trigger, ask only for what you genuinely can't infer, then show a confirm card. You do not create the routine yourself — the card creates it when they turn it on.

A routine fires one of three ways. Decide which the request is:

• Event — "when X happens": an email arrives, a payment lands, a form is submitted. Reactive, no fixed time.
• Schedule — "at a time / on a cadence": "every Friday at 9am", "tomorrow at noon", "the 1st of each month", "every morning".
• Manual — "save this so I can run it whenever": a playbook with no automatic trigger. the guardian runs it by hand from the Routines page's "Run now" button.

If it's ambiguous ("remind me about the standup"), ask one short question to disambiguate before going further. In particular, if it's unclear whether they want it on a schedule or to run it by hand, ask.

The flow

1. Classify the request as event, schedule, or manual (above).
2. Resolve the trigger.
   • Manual: nothing to resolve — there is no trigger to watch or time to compute. Skip straight to choosing the Then (the action it runs) and propose with kind: "manual". No eventName, tzid, rrule, or date.
   • Event from a third-party app (Gmail, GitHub, Slack, Stripe, …): go through the connector chain — connector_event_search → connector_event_schema → confirm with the guardian → connector_event_subscribe. It finds the trigger, gets a yes before arming it upstream, and hands you the exact eventName to bind. See "Event routines from a connector".
   • Event already flowing on the bus (a Rome app's own event, or a connector event you set up before): call search_event_catalog with keywords from the request, then use the matching eventType as eventName. Never invent an event name.
   • Schedule: work out the cadence, the time of day, and the timezone from what they said; translate to an RRULE / one-off date behind the scenes.
3. Fill the gaps with ask_question. Underspecified requests are the norm ("important", "my landlord", "in the morning"). Ask one short, recognition-style question per gap: a single-type question with concrete options when you can name them (candidate senders; "8am / 9am / noon"), or a text question when the answer is open-ended. Never demand a raw value the user would have to look up, and never ask them for an RRULE or an IANA timezone — ask "what time?" and "roughly where are you?" and convert it yourself.
4. Propose with propose_routine. Pass kind: "event", kind: "schedule", or kind: "manual" plus the human summary and the machine spec. A confirm card renders; the guardian turns it on. For manual, set watchLabel to something like "Run on demand" and omit all trigger fields.
5. Close. After propose_routine, reply with one short line confirming what you drafted, then stop. Do not call any create action — the card does that.