schedule
Schedule
Register a scheduled task — one-shot or recurring — that runs reliably whether the user is logged on, on battery, or idle. Cross-platform: Windows (Task Scheduler), Linux (systemd-run --user), macOS (launchd).
When to use
- User wants a command/script/AI prompt to run later (delay or absolute time, one-shot).
- User wants a recurring trigger — every N seconds/minutes/hours, daily at HH:MM, weekly on specific days, or a calendar spec ("Mondays at 09:00", "--* 18:00:00").
- User wants to chain a follow-up after a long-running build/release that exceeds a single agent turn.
- User asks to "schedule", "queue", "run in X minutes", "fire at HH:MM", "every day at HH:MM", "every N minutes".
Recurring tasks have no auto-stop; the user is responsible for cancelling when done (Unregister-ScheduledTask / systemctl --user stop / launchctl bootout). Surface this on registration. The skill registers; it does not own a lifetime policy.
Workflow
- Detect the platform and load the matching reference:
- Windows →
references/windows.md(Task Scheduler /Register-ScheduledTask) - Linux →
references/linux.md(systemd-run --user, fallbackat) - macOS →
references/macos.md(launchd LaunchAgent plist)
- Windows →
More from patrickruddiman/skills
spec
Write a detailed, objective specification of WHAT a system does and WHY. No code, no file paths, no library picks, no implementation prescriptions of any kind. The spec is read by an AI coding agent that will produce its own plan; the spec exists to bound the problem completely — every user-visible behavior, persona task, lifecycle transition, and failure mode.
11slice
Produce a scoped design doc for one technical vertical of a parent spec. Researches the existing codebase first, surfaces implementation choices as questions one at a time, and only drafts the doc after the user resolves them. No code, no tasks — design only.
10create-tasks
Break a slice into AI-executable task files. Each task has a checkbox Tasks section (file paths, line numbers, technical detail — no code) and a strictly code-verifiable Acceptance criteria section that always includes a test command. The consuming AI must tick checkboxes as it works; create-tasks uses that to decide whether to edit a task in place on re-run or append a new one.
10hunt
Aggressively debug, diagnose, or root-cause an issue. Drives a disciplined hunt — query telemetry, reproduce, bisect, instrument, hypothesize-test-confirm, and verify causation by reverting the fix. Refuses common anti-patterns (fix-without-repro, symptom suppression, multi-variable changes, theorize-without-running). Use when the user types /hunt or asks to debug, diagnose, root-cause, track down, or figure out a bug, crash, regression, flaky test, or unexplained behavior.
8worktree
Create or enter a git worktree for the current repo. New worktrees are named repo-<slug>, placed as a sibling of the repo root, and check out a branch (existing or new). Use when the user says "/worktree", "spin up a worktree", "branch off into a worktree", "hop into worktree X", or wants to work on a separate branch in parallel without disturbing the current checkout.
7simplify
Reduce complexity in a code surface — survey smells, collapse speculative abstractions, prefer inline-and-name over extract-and-hide, apply Beck-style tidyings one commit at a time with tests staying green throughout. Default deletion-first. Use when the user says "/simplify", "this is overengineered", "make this simpler", "too much abstraction", "extract too much / too little", "factory with one product", "tidy this code", or wants the canon (Ousterhout, Fowler, Beck, Metz) applied to existing human-written code.
5