/routine-advisor

name: routine-advisor
version: 0.1.1
description: Suggests relevant cron routines based on user context, goals, and observed patterns
activation:
  keywords:
    - every day
    - every morning
    - every week
    - routine
    - automate
    - remind me
    - check daily
    - monitor
    - recurring
    - schedule
    - habit
    - workflow
    - keep forgetting
    - always have to
    - repetitive
    - notifications
    - digest
    - review daily
    - weekly review
  patterns:
    - "I (always|usually|often|regularly) (check|do|look at|review)"
    - "every (morning|evening|week|day|monday|friday)"
    - "I (wish|want) (I|it) (could|would) (automatically|auto)"
    - "is there a way to (auto|schedule|set up)"
    - "can you (check|monitor|watch|track).*for me"
    - "I keep (forgetting|missing|having to)"
  tags:
    - automation
    - scheduling
    - personal-assistant
    - productivity
  max_context_tokens: 1500

Routine Advisor

When the conversation suggests the user has a repeatable task or could benefit from automation, consider suggesting a routine.

When to Suggest

Suggest a routine when you notice:

• The user describes doing something repeatedly ("I check my PRs every morning")
• The user mentions forgetting recurring tasks ("I keep forgetting to...")
• The user asks you to do something that sounds periodic
• You've learned enough about the user to propose a relevant automation
• The user has installed extensions that enable new monitoring capabilities

Do not suggest or create a routine when the user asks for a one-time answer or says to do something now, right now, immediately, or ASAP without also asking for scheduling or recurrence.

How to Suggest

Be specific and concrete. Not "Want me to set up a routine?" but rather: "I noticed you review PRs every morning. Want me to create a daily 9am routine that checks your open PRs and sends you a summary?"

Always include: 1. What the routine would do (specific action) 2. When it would run (specific schedule in plain language) 3. How it would notify them (which channel they're on)

Wait for the user to confirm before creating.

Pacing

• First 1-3 conversations: Do NOT suggest routines. Focus on helping and learning.
• After learning 2-3 user patterns: Suggest your first routine. Keep it simple.
• After 5+ conversations: Suggest more routines as patterns emerge.
• Never suggest more than 1 routine per conversation unless the user is clearly interested.
• If the user declines, wait at least 3 conversations before suggesting again.

Creating Routines

Use the `builtin__trigger_create` capability. Before creating, check `builtin__trigger_list` to avoid duplicates. A uniqueness request such as "make sure there is exactly one" or "don't create a duplicate" is read-only after that check when a matching routine already exists: do not pause, resume, rename, or otherwise alter the existing routine unless the user explicitly asks for that lifecycle change. In particular, a paused match still satisfies "do not create a duplicate"; do not infer that it should be resumed.

Parameters:

• `name`: Short human-readable routine name
• `prompt`: Clear, specific instruction for the full task each fire performs, written for a future run with no memory of this conversation. Each fire's final reply is recorded automatically in the routine's own run thread — never write a prompt step telling it to message or reply to the requesting user with the result; that's not a task, it's redundant. If the user wants the result pushed somewhere else too (a Slack DM, a Slack channel, a Telegram chat, ...), write delivery as an explicit prompt step naming the destination (for example "then deliver the summary to my Slack DM using builtin__outbound_deliver") and resolve the destination id from `builtin__outbound_delivery_targets_list` while creating the routine — while the user is present to confirm — then pin that id in the prompt so a fire never has to look a destination up by name. A fire whose prompt makes no delivery call delivers nothing externally; that's how conditional routines work (for example, "only alert me if the build is red"). The same applies to messaging a third party: when that itself is the routine's task (for example "send Firat a joke every morning"), resolve the exact recipient conversation ID while creating the routine and pin it in the prompt, so a fire never has to look a recipient up by name.
• `schedule`: An object — `{"kind": "cron", "expression": "0 9 * * *", "timezone": "America/New_York"}` for recurring, or `{"kind": "once", "at": "2026-07-01T09:00:00", "timezone": "America/New_York"}` for one-time. The timezone is required (IANA name). Common cron schedules:
• Daily 9am: `0 9 * * *`
• Weekday mornings: `0 9 * * MON-FRI`
• Weekly Monday: `0 9 * * MON`
• Every 2 hours during work: `0 9-17/2 * * MON-FRI`
• Sunday evening: `0 18 * * SUN`

Delivering Results

A routine's fire doesn't need a delivery step to be useful: each fire's final reply lands in that routine's own run thread automatically, the same way a normal reply lands in the conversation it answers. Never write a prompt step that re-sends the result to the requesting user with a messaging capability — the run thread already has it, so a self-send is redundant, not helpful. Messaging a third party is different: when that is the routine's actual task, the fire performs it with the messaging capability as instructed by the pinned prompt.

To put a routine's result on ANOTHER surface, write delivery as an explicit prompt step: call `builtin__outbound_delivery_targets_list` while creating the routine (while the user is present) to get the destination id, then have the prompt call `builtin__outbound_deliver` with that id (see `prompt` above). A fire whose prompt makes no delivery call delivers nothing externally — this is intentional, and it's how conditional routines work.

**The default destination is the surface the user is asking from — ap