JARVIS-MCP: Skill for Claude Code

jarvis Scheduled Continuation

One user request starts one durable chain: acquire the goal, arm one cloud successor, keep doing useful work, hand off when necessary, and stop only after the goal is verifiably terminal.

Non-negotiable outcome

• Never require the user to type “continue”, “ทำต่อ”, or ask for status to restart an unfinished goal.
• Never send a completion report while get_goal reports active.
• A request to stop scheduling cancels only the successor. It does not cancel, block, pause, or complete the durable goal. Continue in the current run and still call finish_goal when the work is actually done.
• cancel_goal and cancel_scheduled_continuation are independent controls: the former records the goal as cancelled, aborts in-flight fenced MCP requests, and stops every tracked process, Codex task, and shell task; the latter cancels only the waiting successor. Call both when the user wants both effects.
• Use one native one-time cloud ChatGPT Scheduled Task in the current chat. Never use recurrence, Windows Task Scheduler, schtasks.exe, cron, shell timers, browser automation, or undocumented scheduling APIs.
• Native task creation, update, and deletion are host-owned. jarvis stores the reservation, receipts, claim, and cancellation truth.

Start or resume

run_goal defaults to scheduledContinuation: auto. When its result contains continuationDirective.mode: auto, the client MUST apply this skill automatically even when the user did not name $jarvis-scheduled-continuation. The directive is the durable-goal opt-in signal: never require another user prompt to resume an unfinished goal. Use scheduledContinuation: off only when the user explicitly disables future scheduling; that disables the successor, not the current goal work.

1. Call run_goal with a stable workspace and goal key using the normal 600-second (10-minute) lease. Never override this workflow to an hour-long lease. Keep the returned lease token and generation private. The lease is a short crash-recovery window, not the expected work duration; real checkpoint/fenced-mutation activity renews it while work is actually alive.
2. Read the durable checkpoint and do the next useful work. Record real milestones with checkpoint_goal; do not checkpoint merely because time elapsed.
3. After the first checkpoint, call prepare_scheduled_continuation and create exactly one native one-time task from its scheduleRequest. Record created with the real native task ID and runsOn: cloud immediately before relying on it. Never yield after native creation while durable state is still only prepared.
4. Choose successorDelayMinutes adaptively within 2–25 minutes. The API default is deliberately 2 minutes as a fail-safe: any longer watchdog must be explicit.