Menu
Suggests relevant cron routines based on user context, goals, and observed patterns
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/nearai/ironclaw --skill routine-advisorThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
| 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} |
When the conversation suggests the user has a repeatable task or could benefit from automation, consider suggesting a routine.
Suggest a routine when you notice:
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.
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:
Wait for the user to confirm before creating.
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 nameprompt: 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:
0 9 * * *0 9 * * MON-FRI0 9 * * MON0 9-17/2 * * MON-FRI0 18 * * SUNA 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 — apply it, never ask. A bare "send me X every morning" asked in a Slack or Telegram conversation means that conversation's channel: resolve the current channel's target id from builtin__outbound_delivery_targets_list and pin it in the delivery step, exactly as if the user had named it. Asked from the web app, a bare "send me" needs no delivery step — the result already lands in the routine's run thread the user will see there; create the routine without one and say where results will appear. Do not respond to a bare "send me" with a which-channel question in either case. Naming destinations overrides this default ("in Telegram" from Slack → Telegram; "to Slack and Telegram" → one delivery call per channel).
Delivery and notifications are different concerns. Delivery puts the routine's actual result on a destination the prompt names, one call per destination. Notifications are host-owned pings that a background run needs attention — an approval gate, a reconnect prompt, a failure — and they ride the user's configured notification channels (builtin__notification_channels_set), independent of any routine's own delivery steps; if the user wants to be pinged when a routine stalls waiting for approval, that's a notification-channel setting, not a prompt step. Routines carry no stored default destination: if a fire's prompt makes no delivery call and no notification is due, the result stays in the run thread only.
Developer:
Professional:
Health/Personal:
General:
context/profile.json, suggest a Monday routine that reads the profile via memory_read, searches recent conversations for new patterns with memory_search, and updates the profile via memory_write if any fields should change with confidence > 0.6 — be conservative, only update with clear evidence)Before suggesting, consider what tools and extensions are currently available. Only suggest routines the agent can actually execute. If a routine would need a tool that isn't installed, mention that too: "If you connect your calendar, I could also send you a morning briefing with today's meetings."
Use when adding or changing a Reborn integration — a new extension, a channel surface, model-callable tools, or a shared auth provider — or when deciding whether something is "a channel", "an extension", or "a tool". Maps the unified extension model (NEA-25) to the exact manifest sections, crates, seams, and tests.
Use when creating or editing agent guidance in this repo — anything under .claude/ (skills, commands, rules), AGENTS.md or CLAUDE.md files, or the runtime skills/ directory — or when guidance is found citing files, branches, or checks that no longer exist.
Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Based on SOC occupation classification
