Skip to main content

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.

来源信息

仓库
protosphinx/sphinxstack
最近来源活动
2026年7月29日 13:55
检测到的 SKILL.md 语言
英语
星标
3
Forks
0

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
2 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
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.
在 GitHub 查看