Scheduling recurring work
Give ask or task a time and it becomes a schedule: the pack does that work without being asked, either once or repeatedly. --cron takes a cron expression (30-minute minimum interval); --at takes a single future RFC 3339 time. --name is an optional human label.
edisyl task growth-metrics "Digest the week's activity" --cron "0 9 * * 1" --name weekly_digestedisyl ask growth-metrics "Which hypotheses moved this week?" --cron "0 9 * * 2" --name weekly_checkEach fire creates that verb’s own Action: a scheduled ask answers, a scheduled task works. task and ask are schedulable because a brief carries their whole request; a verb that also needs a file or a target (teach, import) has nothing to schedule from.
The create command prints a schedule id, and that id is the only thing every other schedule command takes, not the name, which you can reuse or leave off entirely.
edisyl schedule list [--pack <pack>] # ids, labels, when they run, last/next runedisyl schedule view <schedule-id> # when it runs, brief, recent runsedisyl schedule trigger <schedule-id> # run it now; returns an actionId to followedisyl schedule runs <schedule-id> # run historyedisyl schedule pause <schedule-id> # stop firing, keep itedisyl schedule resume <schedule-id>edisyl schedule delete <schedule-id> # disables it; --force removes it outrightComposing a self-maintaining pack
Section titled “Composing a self-maintaining pack”This is where the Ask/Teach/Task model compounds:
- A pack receives a recurring task to research weekly activity.
- The task reads the pack’s live sources and learned definitions.
- It produces a result.
- If requested, it teaches that result back into the same pack.
- Future asks can compare the current week against every retained prior run.
No self-updating skill is a separate product concept here: schedules and tasks supply the recurrence, teach supplies the durable update.
Was this page helpful?
Thanks for the feedback.
