Skills / Automate a task
Automate a task
Write a script that completes a repetitive task they actually do. Covers input, output, dry runs, logs, scheduling, and a safe off switch. Use when they mention a repetitive task, ask "can I automate this", or want a script that runs by itself.
Use this skill. Nothing to install.
Don't have an agent? · Raw file: skills/automate-a-task.md
Watch the first two minutes
This is how a session goes, including the part everyone is afraid of. Click through it.
Scripted example of a real session.
What if it breaks something while I'm not looking?
The skill treats that fear as a design requirement. Destructive steps rehearse in dry-run mode against copies of real files before they earn the originals. Every run leaves visible output, so a silent failure has nowhere to hide. And the script does one job, readable top to bottom, so when the source page changes shape you can see exactly where it stopped. These are the kinds of chores people kill first:
What you end up with
A script that does the real chore, on a schedule, with proof. Here is the shift script's log after its first unattended week.
$ tail runs.log
2026-07-13 07:02 ok 4 shifts found, calendar updated
2026-07-14 07:01 ok no changes
2026-07-15 07:02 ok no changes
2026-07-16 07:03 FAIL page layout changed, wrote
nothing (exit 1)
2026-07-16 18:40 ok selector fixed, 4 shifts found
2026-07-17 07:02 ok no changes
2026-07-18 07:01 ok 1 shift added, calendar updated
Runs every morning at 07:00 via GitHub Actions (.github/workflows/shifts.yml). To stop it, comment out the `schedule:` block.
- The failure is the best line in the log. The page changed shape, and the script wrote nothing rather than half a calendar, said why, and exited nonzero. That behavior was built in step 3, before scheduling.
- "No changes" is still a line. Visible output on every run is what makes an unattended script trustworthy; a quiet log means it ran and found nothing, a missing line means it didn't run.
- The off switch is documented. One README line says what runs, when, and how to turn it off. Future you will need exactly that.
Anatomy of a cron line
The five fields that scare everyone read left to right:
- A Minute 0.
- B Hour 7, so 07:00.
- C Any day of the month, any month.
- D Weekday 1, which is Monday. Whole line: every Monday at 07:00, run the script. You'll write yours and be able to recite it back.
Questions people actually ask
Do I need a server for this?
No. Chores on your own machine run under cron or launchd. Chores that must run while your laptop is closed go in a GitHub Actions scheduled workflow on the free tier. Both cost nothing.
Is scraping a website allowed?
The skill has the script behave like a polite visitor: check robots.txt, fetch once per run, and prefer an official feed or API whenever one exists. If the site offers an export, that beats scraping every time.
Where do passwords and tokens go?
In an env var locally and in Actions secrets on GitHub. Never in the script, never committed. If the chore needs your login to a site, that's worth a pause to check the site's terms before automating.
Python or JavaScript?
Whichever you've touched. The skill favors plain files and standard tools over frameworks either way, so the script stays readable top to bottom.
What happens when the page changes shape?
The script fails with a clear message and a nonzero exit instead of producing half-finished work, and the dated log makes the failure visible. You fix the selector and re-run by hand, which the log above shows happening in real life.
Where to go from here
More chores worth killing:
Level the script up:
Ideas to use it on
- The chore rotation bot — Whose week is it for dishes, trash, or driving is a recurring argument in your house because the rotation lives in everyone's memory.
- A bot your Discord server actually uses — Some job in your Discord server is still done by a human: giving newcomers the right role, reminding everyone about game night, keeping a leaderboard for the running joke.
- A janitor for your downloads folder — Your downloads folder (or camera roll export, or desktop) is a landfill you excavate by hand every few weeks.
- One email instead of three apps — Every morning you open the same three things: the weather, your team's score, the bus alerts, a subreddit, a webcomic.
- A price watcher for the thing you want — There is a thing you are saving for, and you check its price by hand every few days.
- A GitHub Action that does a real job in your repo — Pick something you do by hand in one of your existing repos every time you touch it: checking that the links in the README still work, regenerating a stats table from a data file, compressing images before commit, validating that a JSON file still parses.
- Your school's schedule as a calendar feed — Your school publishes its schedule as a PDF, a webpage, and three different emails, and you retype the parts you care about into your phone.
Curious? Read the full skill — the exact instructions your agent gets
--- name: automate-a-task category: code description: Write a script that completes a repetitive task they actually do. Covers input, output, dry runs, logs, scheduling, and a safe off switch. Use when they mention a repetitive task, ask "can I automate this", or want a script that runs by itself. --- # automate-a-task Automate a chore someone actually does: a script that does the boring thing, then a scheduler that runs it without them. The payoff is the shift in stance from doing tasks to writing things that do tasks. It only lands if the chore is real. ## Ground rules - Start from a real chore. Ask what they do every week that feels mechanical: checking a page for changes, sorting a downloads folder, collecting posts from feeds, reformatting a file for school or work. If the task is not theirs, there is no reliable way to verify whether it remains useful, so keep asking until one is. - One script, one job, readable top to bottom. Python or Node, whichever they have touched; plain files and standard tools over frameworks. If it scrapes, respect the site: check robots.txt, fetch once per run, and prefer an official feed or API when one exists. - Destructive steps get a rehearsal. Anything that renames, moves, or deletes runs in dry-run mode first, printing what it would do, and only touches copies of real files until the output has been read twice. - Free scheduling only: cron or launchd on their machine, or a GitHub Actions scheduled workflow for anything that should run while their laptop is closed. Name the honest limits: Actions cron is best-effort timing, free minutes are capped, and schedules on inactive repos get suspended. - Any key or token the script needs goes in an env var locally and in Actions secrets on GitHub. Never in the script, never committed. ## The path 1. Do the chore manually once, together, narrating each step. The narration is the spec; write it as comments before any code. 2. Script the core: input to output, run by hand, output checked against a manual pass of the same chore. Dry-run flag first if anything is destructive. 3. Harden lightly: the missing file, the page that changed shape, the empty feed. Fail with a clear message and a nonzero exit instead of half-finished work. 4. Schedule it. Local chore: a cron or launchd entry they write and can recite back. Cloud chore: a workflow YAML with `schedule:`, pushed, then triggered once by hand with `workflow_dispatch` to prove it runs before waiting for the clock. 5. Make results visible: the script writes a dated log line, commits an output file, or produces something they will notice. Silent automation is broken automation waiting to be discovered. 6. Let it run on its own at least once, then read the log together. ## Done - A script in a repo that does the real chore end to end - Scheduled and proven: at least one unattended run with visible output or log - Destructive steps had a dry run; secrets live in env vars or Actions secrets only - A README line saying what runs, when, and how to turn it off - They can name the next chore they would automate Then: use-an-api if the chore wants richer data, or ship-on-github if the script deserves a repo of its own.