Menu
Design effective automated workflows using scheduled tasks, prompt chaining, and delivery channels.
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/siddsachar/row-bot --skill task-automationThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Based on SOC occupation classification
Showing SKILL.md
| name | task_automation |
| display_name | Task Automation |
| icon | ⚙️ |
| description | Design effective automated workflows using scheduled tasks, prompt chaining, and delivery channels. |
| enabled_by_default | true |
| version | 3.0 |
| tags | ["automation","productivity"] |
| activation | {"phrases":["recurring task","scheduled task","every monday","automate this","reminder workflow"],"keywords":["recurring","schedule","scheduled","task","workflow","monday","reminder"],"negative_phrases":["meeting notes","human tone"],"examples":["Help me set up a recurring task every Monday"]} |
| author | Row-Bot |
When the user wants to set up automations, create recurring workflows, schedule something, or set a reminder, apply these principles:
A task is an ordered list of prompts executed sequentially in a dedicated thread. Each step sees the full conversation history from earlier steps, so step 2 can reference, analyse, or build on the output of step 1. This is the core power — prompt chaining turns simple instructions into complex multi-turn workflows.
There are three task types:
delay_minutes for quick "remind me in 30 minutes" requests. These auto-delete after firing.Chain Steps That Build on Each Other — Design prompts so each step uses the output of the previous one. Example:
Step 2 works because it can see step 1's search results in the conversation. Step 3 works because it can see the summary.
Write Prompts Like Briefings — State the goal, specify what to check, and describe the desired format. Vague prompts produce vague results. Each prompt should make it clear what the agent should do in that step.
Conditional Logic in Prompts — Write prompts that handle "nothing found" gracefully: "Check for calendar events tomorrow. If there are none, just say 'Clear schedule tomorrow.' If there are events, list them with times and highlight any conflicts."
Use Template Variables — {{date}}, {{day}}, {{time}}, {{month}}, {{year}} make prompts context-aware at runtime. "Summarise news for {{date}}" produces different results each day.
daily:HH:MM — briefings, digests, check-insweekly:DAY:HH:MM — reviews, summaries, reportsinterval:H / interval_minutes:M — monitoring, polling, frequent checkscron:EXPR — complex schedules (e.g. cron:0 9 * * mon-fri for weekdays only)notify_only) for simple nudges.model parameter to run a specific task on a different model (e.g. a heavier model for complex research, a lighter one for quick checks).persistent_thread=false). Set persistent_thread=true when the task needs to see results from prior runs — e.g. monitoring/polling tasks that compare against previous values, project trackers that build on earlier summaries, or any task where cross-run context matters. The system auto-generates and manages the thread ID.Pipeline mode replaces simple prompt lists with typed steps for complex workflows. Use steps instead of prompts when you need conditional branching, approval gates, subtasks, or notifications.
{{prev_output}} and {{step.<id>.output}} for data passing between steps. Optional: on_error (stop/skip), max_retries, retry_delay_seconds.condition (expression), if_true (step ID to jump to), if_false (step ID or "end"). Operators: contains:X, not_contains:X, equals:X, matches:REGEX, gt:N, lt:N, empty, not_empty, true, false, json:path:operator:value, llm:question, and:[...], or:[...].message, timeout_minutes (0 = wait forever, default 30). The user approves or denies from the Activity tab.task_id, pass_output (bool, pass previous output as input).message, channel (desktop/telegram/email).llm:question — Best for natural language output. An LLM evaluates the question against the previous step's output and returns yes/no. Use when the output is free-form text (e.g. llm:Were any relevant results found?). Most reliable for ambiguous output.contains:X / not_contains:X — Keyword match. Good for structured output or sentinel values.empty / not_empty — Only when the step literally returns nothing on failure.equals:X — Exact string match. Only reliable when the prompt is engineered to output a specific sentinel value (e.g. "If no results, output exactly: NO_RESULTS").json:path:operator:value — For structured JSON output with dot-path access.and:[...] / or:[...] — Combine multiple operators.Each step's output is captured. Use template variables to reference it in later steps:
{{prev_output}} — the output of the immediately preceding step.{{step.prompt_1.output}} — the output of the step with ID prompt_1.Step IDs are auto-generated as {type}_{counter} — e.g. prompt_1, condition_1, prompt_2, notify_1. Do NOT provide an id field; it is assigned automatically based on step type and position.
nextAll step types accept an optional next field to override the default linear advancement:
"next": "step_id" — jump to a specific step after this one completes."next": "end" — terminate the pipeline after this step.This is essential for branching workflows: when a condition branches to an if_true path, the last step of that branch should use "next": "end" to prevent fall-through into the if_false path.
Every task has a safety_mode that controls access to destructive tools (shell commands, file writes, emails, calendar changes):
block (default) — destructive tools are removed entirely. Safest for automated runs.approve — destructive tools are available, but the pipeline pauses for human approval before executing them. The user approves from the Activity tab.allow_all — no restrictions. Use only for trusted, well-tested pipelines.# Search → Condition → Branch → Approve → Notify
# Step IDs are auto-assigned: prompt_1, condition_1, notify_1, prompt_2, approval_1, notify_2
steps = [
{"type": "prompt", "prompt": "Search for breaking news about {{topic}}"},
{"type": "condition", "condition": "llm:Were any relevant results found?",
"if_true": "prompt_2", "if_false": "notify_1"},
{"type": "notify", "message": "No results for {{topic}}.", "channel": "desktop",
"next": "end"},
{"type": "prompt", "prompt": "Summarize: {{step.prompt_1.output}}"},
{"type": "approval", "message": "Send this summary to the team?"},
{"type": "notify", "message": "{{step.prompt_2.output}}", "channel": "telegram"},
]
Key patterns in this example:
llm: condition operator for intelligent evaluation of free-text search outputnotify_1 has "next": "end" to stop the pipeline after the "no results" branch — without this, execution would fall through into prompt_2if_true jumps to prompt_2, skipping the "no results" notifytask_list to avoid duplicates or overlapping schedules.task_run_now after creation so the user can verify the output before waiting for the first scheduled run.task_update rather than deleting and recreating.When the user wants to monitor a condition and be notified when it changes ("check X and tell me when Y", "alert me if Z drops below W"), use the interval + self-disable pattern:
Use an interval schedule — interval_minutes:M for frequent checks (stock availability, price drops) or interval:H for slower checks (daily digest changes).
Write a conditional prompt — The prompt should:
task_update(task_id='{{task_id}}', enabled=false)Always set persistent_thread=true — This lets the agent see prior checks across runs. Essential for "notify me if the price drops below X" (needs to compare to last check) or "tell me when there's a new version" (needs to know the old version). The system auto-generates the thread ID — just pass the boolean flag.
Template: polling prompt pattern —
Search for [condition]. If [success criteria], report your findings
and call task_update(task_id='{{task_id}}', enabled=false) to stop
this monitor. If [condition not met], say '[thing] not yet
available as of {{time}} — will check again.'
Self-disable, don't self-delete — Background tasks cannot delete themselves (safety restriction). Use task_update(enabled=false) instead. The user can re-enable, delete, or leave the disabled task.