/planned-task-runtime

name: planned-task-runtime
description: >-
  Handles system follow-up turns: planned-task-follow-up (synthesize, replan,
  build-workflow, checkpoint), background-task-completed, running-tasks context,
  and create-tasks silence rules. Load whenever any of these tags appear or
  after calling create-tasks.
recommended_tools:
  - create-tasks
  - complete-checkpoint
  - build-workflow
  - task-control
  - workflows
  - verify-built-workflow
  - executions

Planned Task Runtime

Load this skill when the current message contains `<planned-task-follow-up>`, `<background-task-completed>`, `<running-tasks>`, or immediately after calling `create-tasks`. Before calling `create-tasks`, load it via `load_tool` if it is not already visible (search "create tasks" if needed).

Silence after spawning tasks

**After calling `create-tasks`**: do not write any text. The task card or approval card shows the user what's being built or done; restating it is redundant. Do NOT summarize the plan, list credentials, describe what the agent will do, or add status details. Progress is already visible to the user in real time.

When `create-tasks` returns after approval, tasks are already running. Do not summarize or add status text — the user already approved the plan and the checklist shows progress. Wait for `<planned-task-follow-up>` to arrive; do not invent synthetic follow-up turns.

Never poll

**Never poll and never sleep.** Background tasks settle via `<planned-task-follow-up>` turns that arrive automatically when work finishes. After you spawn or acknowledge one, end your turn. Do not call `workflows(action="list")`, `executions(action="list")`, or any shell command to check progress — you will receive a follow-up turn the moment the task settles. If a task appears stuck, tell the user and stop; do not try to detect completion yourself. Do not re-dispatch a build whose task ID is already visible in `<running-tasks>`.

When `<running-tasks>` context is present, use it only to reference active task IDs for cancellation or corrections.

If the user sends a correction while a build is running, call `task-control(action="correct-task")` with the task ID and correction.

Synthesize follow-up

When `<planned-task-follow-up type="synthesize">` is present, all planned tasks completed successfully and any unsettled runtime verification obligations have already been handled. Before the final message, inspect workflow task outcomes: if a workflow still has `verificationReadiness.status === "needs_setup"`, call `workflows(action="setup")` for that workflowId; if it has `verificationReadiness.status === "not_verifiable"`, include the readiness guidance as a clear warning/manual-test note and do not call it verified. Treat verified workflow drafts as finished deliverables — they are ready to use. If the original user request explicitly asked to run or execute the workflow after building it, call `executions(action="run")` once for the built workflow; checkpoint verification does not satisfy a user-requested run. Otherwise write a concise completion message that names each delivered artifact (data tables, workflows) and summarizes what it does, using the user's time zone for any scheduled timings. Do not hedge with phrases like "ready to go live" or "let me know when you're ready" — the work is done. If any workflow is unpublished, state that plainly as a one-line next-step note ("Publish when you want it live — you can do that from the workflow editor."), not as a gating condition. Do not create another plan.

Replan follow-up

When `<planned-task-follow-up type="replan">` is present, a planned task failed and the graph is in `awaiting_replan`. You MUST take action in this same turn — handle a single simple task directly (matching tool: `build-workflow`, `data-tables`, etc.), load `create-tasks` via `load_tool` if needed and call `create-tasks` with `planningContext.source: "replan"` for multiple dependent tasks, or explain the blocker to the user if nothing sensible remains. Do NOT reply with an acknowledgement or status update alone — the scheduler will not fire another follow-up until you act, and the thread will silently stall.

Replan routing (do not re-plan from scratch):

• One simple task remains (single data-table op, credential setup, single-workflow

patch) → handle directly with the matching tool.

• Multiple dependent tasks still need scheduling → load `create-tasks` via

`load_tool` if needed, then call `create-tasks` with `planningContext.source: "replan"`.

• Nothing sensible remains → explain the blocker to the user.

Build-workflow follow-up

When `<planned-task-follow-up type="build-workflow">` is present, load the `workflow-builder` skill and build exactly the `buildTask` in the payload. If `buildTask.workflowId` is present, update that workflow; otherwise create a new one. If `buildTask.isSupportingWorkflow === true`, pass `isSupportingWorkflow: true` to `build-workflow`; that saved supporting workflow is the task's final deliverable. Save with `build-workflow` and stop after a successful save — do not verify, set up credentials, publish, call `complete-checkpoint`, create a new plan, or write a user-facing message. If `build-workflow` returns fixable validation errors, patch in the same turn and save again. If the build is blocked, explain the blocker briefly; the planned task finalizer will mark the task failed.

Checkpoint follow-up

When `<planned-task-follow-up type="checkpoint">` is present, the block contains exactly one checkpoint task (`checkpoint.id`, `checkpoint.title`, `checkpoint.instructions`, and `checkpoint.dependsOn` — the outcomes of prior tasks, including workflow build outcomes with their `outcome.workItemId` / `outcome.workflowId`). **Always require structured verification evidence — never trust builder prose.** Before completing the checkpoint, inspect each dependent persisted workflow with `workflows(action="get-as-code", workflowId)` or the boun