Choosing between a skill and a scheduled task means clarifying whether the thing you want to automate needs its operational steps packaged, its trigger timing set, or both. A skill is fundamentally an instruction manual, answering how Claude should do the thing, and needs to be invoked to run. A scheduled task is fundamentally an alarm clock paired with an instruction, answering when the thing should happen automatically, firing on its own once the time arrives. This is a different question from which feature is better — most people's first sticking point is treating the two as mutually exclusive options to compare, when in fact they address entirely different levels of need, and in many cases the answer is both, not either-or.
This confusion arises because the two features sit close together in the interface, and both are described using the language of automation, making it easy to treat them as two options within the same category. But conflating them leads to two common misuses. One forces an irregularly occurring task onto a fixed schedule, producing either empty runs or delays no matter how the timing gets adjusted, because the problem was never the schedule — the task itself simply doesn't happen on a fixed rhythm. The other crams an operation complex enough to need demonstration into a single line of scheduled-task instruction, producing slightly unstable results each run, because that one line is carrying more detail than it can hold. Both misuses trace back to the same root cause: never first asking whether this is fundamentally a how question or a when question.
In practice this judgment runs in three steps. First, ask whether the thing's timing is fixed — weekly, daily, monthly on a set cadence falls under scheduled tasks; triggered by some uncertain event (receiving a certain type of email, a document getting uploaded) falls under manually invoking a skill. Second, ask whether the operation itself is complex enough to be worth demonstrating — if it can be stated clearly in one sentence ('compile yesterday's alert list'), write it directly into the scheduled instruction; if it involves several steps, formatting rules, or details easily lost in description, it's worth recording as a skill first. Third, if both conditions hold — regular occurrence plus complex operation — stack the two: record the skill first and confirm it's stable through testing, then set a scheduled task whose trigger content reads 'call this skill, processing data in this range,' letting the schedule handle only the calling and the skill handle the doing, each maintained separately.
For you, sorting out these two questions first saves a lot of time spent debugging 'I keep adjusting this and it's still not right.' When most people pick wrong, their first instinct is to suspect the schedule wasn't set precisely enough, or the skill wasn't recorded thoroughly enough — rarely stepping back to consider that this task simply shouldn't be using this mechanism in the first place. The habit worth building is spending ten seconds asking yourself these two questions whenever a task comes up for automation, rather than jumping straight into the settings interface and picking whichever option looks more appealing at a glance. Worth noting: when the two are stacked together, the benefit of splitting them is independent maintenance — rules change, edit the skill; timing changes, edit the schedule. Hard-code both into the same place for convenience, and adjusting either one later means untangling the whole thing again.
You want Claude to sort out your expense records every week, so you open settings and see 'Record a Skill' and 'Scheduled Task' sitting side by side, and for a moment you can't tell which to pick — both sound like they'll 'let Claude do this automatically going forward,' and it's not obvious what happens if you pick the wrong one. This hesitation is normal, because the two features genuinely do overlap on the surface, but they're actually answering two different-level questions: one answers how Claude should do the thing, the other answers when the thing should happen on its own. Once that distinction is clear, the choice stops being a guess.
A skill is, at its core, an instruction manual — you demonstrate something once, Claude breaks that demonstration down into a repeatable set of steps, and saves it to the skill library. A skill doesn't start itself; it has to be invoked, either by you asking for it directly in a conversation, or by a scheduled task calling it. A scheduled task is, at its core, an alarm clock paired with an instruction — you set a time and a thing to do, and when that time arrives, Claude runs it automatically without you needing to be there to trigger it. The two aren't an either-or choice, they're complementary: a skill handles exactly how something should be done, and a scheduled task handles when it should happen automatically — many genuinely mature automation workflows are actually a scheduled task calling an already-recorded skill at a fixed time.
If something doesn't happen on a regular cadence and its trigger timing isn't fixed — say, a contract review workflow that only needs to run when a new client contract actually comes in — you just need to record a skill and call it manually whenever it's needed, no scheduling required. Forcing a fixed time onto something irregular just produces either an empty run because there's nothing to process when the time hits, or a delay because the item arrived before the scheduled time — neither is worth it. The skill's value here is storing the knowledge of how to do it so you don't have to re-demonstrate every time, entirely separate from when it happens.
If something is simple and its method barely ever changes — say, compiling yesterday's system alert list every morning — just write the instruction directly into the scheduled task's trigger content, no need to record a dedicated skill for it. A skill's value lies in packaging an operation complex enough to be worth demonstrating once and calling repeatedly afterward; if the task can be stated clearly in a single sentence, recording a separate skill just adds an unnecessary layer of indirection and one more thing to remember to keep in sync during maintenance.
The situation best suited to combining the two is a task that satisfies both conditions at once — it happens on a regular cadence, and its steps are complex enough to be worth demonstrating first. Expense filing is exactly this: it needs to happen weekly on a fixed schedule (calling for a schedule), but the logic of sorting expenses involves several steps and formatting rules (calling for a skill to encapsulate it). The approach is to record the expense-filing skill first, confirm it's stable through testing, then set a weekly scheduled task whose trigger content reads 'call the expense-filing skill, processing receipts from the past seven days.' The benefit of splitting it this way: if the expense rules change later — Finance adds a new review field, say — you only need to edit the skill definition, not the schedule; if the schedule needs adjusting — moved from Monday to Friday — you only need to change the schedule, not re-record the skill. The two get maintained independently, without pulling on each other.
The cost of picking wrong usually isn't 'completely unusable' — it's 'works, but feels off in a way you can't quite name.' Force an irregular task into a schedule, and you'll find yourself constantly adjusting the trigger time, never quite getting it right no matter how much you tweak it. Write a complex operation that should have been packaged as a skill directly into a one-line scheduled instruction, and you'll find each run comes out a little unstable, because that one line is carrying more detail than it can actually hold. Spend two minutes asking yourself whether this thing should happen on a regular cadence and whether the operation itself is genuinely complex — the answer to those two questions usually tells you which one to pick, or whether it's worth using both together.