用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/nearai/ironclaw --skill routine-advisor命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
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.
正在显示 SKILL.md
基于 SOC 职业分类
| 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."