Truestack task scheduling

Skill adtn0810/truestack/skills/truestack-task-scheduling

Honesty-first coding skill set for Claude Code — 21 skills behind an orchestrate router with an enforced governance gate, a code↔memory tally, and auto-research. Built for self-hosted work.

Install

npx -y skills add adtn0810/truestack --skill truestack-task-scheduling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Set up work that runs automatically later or on a recurring cadence — a daily check, a weekly report, a periodic sync, a deferred run — instead of doing it once now. Use whenever the user says "every day", "each morning", "weekly", "nightly", "cron", "schedule this", "remind me", "run this at", or wants a task to recur or fire in the future. (A standing behavior rule — hooks or settings config — is not a schedule.) Produces a self-contained job spec (trigger, the exact prompt the run executes, delivery, and failure policy) and wires it to the host's scheduler.

SKILL.md

4.2 KB, as published. Nobody here has run it

truestack-task-scheduling

A scheduled run happens with no memory of this conversation — only the job spec you write and whatever lives in committed project memory. So the whole skill is about making the future run self-sufficient, grounded at run time, and safe to repeat. Get the spec right and it runs unattended for months; get it vague and it silently does the wrong thing every morning.

1. Is it actually a schedule?

A cadence ("every morning", "each Monday", "hourly") → schedule it.
A time phrase describing the subject, not the timing ("summarize yesterday's standup") → that's a one-off; just do it now.
Ambiguous? Do it once now, then offer to make it recurring — don't assume.

2. Write the job spec

Capture four things, precisely:

Trigger — a recurring cadence (cron, e.g. 0 6 * * * for 06:00 daily) or a one-time fire-at timestamp. Pin the timezone.
The run prompt — the exact, self-contained instruction the run will execute. It must name its own data sources and re-fetch them at run time; it cannot rely on anything from this chat.
Delivery — what "done" produces and where it goes (a file, a message, a report, a memory update), so a silent run isn't a useless run.
Failure policy — what to do on error or empty result: skip quietly, retry, or alert — and explicitly don't spam the user with "nothing to report" every day unless they asked.

3. Ground at run time (never bake in stale facts)

The single biggest scheduled-task bug: freezing today's data into the prompt. The run must read live sources and current memory when it fires — "yesterday" is computed at run time, prices and statuses are re-fetched, the repo is re-read. Author the prompt so it pulls fresh, not so it repeats a snapshot.

4. Make repeated runs safe

Idempotent / bounded: a run must be safe to fire again; guard against overlap if one run can outlast its interval; cap the work so a busy day can't blow up.
Side-effects stay gated: a scheduled job still obeys the boundaries — it may prepare a message, payment, or destructive change, but anything Ask-first needs human approval, not an automatic 6am execution. Schedule the draft, not the irreversible send, unless the user explicitly authorized the action itself.

5. Wire it to the host

Discover, don't assume: check what scheduler actually exists here, in this order — (1) the harness's own scheduling tools if the session exposes them (some Claude Code environments ship Cron tools — look for them before shelling out), (2) system cron / Windows Task Scheduler running headless claude -p "<run prompt>", (3) a CI cron (GitHub Actions schedule:). Concrete copy-paste recipes for each → references/wiring.md. This skill defines the spec; create the schedule with the host's scheduler and confirm the first run's timing back to the user. If no scheduler is available, say so and hand back the spec to run manually — never pretend a schedule exists.

Output

# Scheduled job: [name]
## Trigger: <cron / fire-at + timezone>
## Run prompt: <self-contained instruction, re-fetches live data>
## Delivery: <what it produces, where>
## Failure policy: <retry / skip / alert; no-spam rule>
## Boundaries: <any Ask-first action kept as draft-only>

Explain it simply

Confirm in one plain line what will run, when, and what the user will receive ("Every weekday 7am: a fresh open-PR digest saved to reports/ — nothing sent anywhere"). State the first run time. Recurring research uses truestack-deep-research; recurring checks use truestack-quality-control / the test run.