SKILL.md
2,065 tokens · o200k_base · 9,197 bytes
Source excerpt starting at line 1.---name: planned-task-runtimedescription: >- 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 isnot 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 theuser what's being built or done; restating it is redundant. Do NOT summarize theplan, 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 notsummarize or add status text — the user already approved the plan and thechecklist shows progress. Wait for `<planned-task-follow-up>` to arrive; do notinvent 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 commandto 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 completionyourself. 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 taskIDs 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 taskscompleted successfully and any unsettled runtime verification obligations havealready 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 readinessguidance as a clear warning/manual-test note and do not call it verified. Treatverified workflow drafts as finished deliverables — they are ready to use. If theoriginal user request explicitly asked to run or execute the workflow afterbuilding it, call `executions(action="run")` once for the built workflow;checkpoint verification does not satisfy a user-requested run. Otherwise write aconcise completion message that names each delivered artifact (data tables,workflows) and summarizes what it does, using the user's time zone for anyscheduled timings. Do not hedge with phrases like "ready to go live" or "let meknow 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 notcreate another plan. ## Replan follow-up When `<planned-task-follow-up type="replan">` is present, a planned task failedand 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 theblocker to the user if nothing sensible remains. Do NOT reply with anacknowledgement or status update alone — the scheduler will not fire anotherfollow-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 newone. If `buildTask.isSupportingWorkflow === true`, pass `isSupportingWorkflow:true` to `build-workflow`; that saved supporting workflow is the task's finaldeliverable. Save with `build-workflow` and stop after a successful save — do notverify, set up credentials, publish, call `complete-checkpoint`, create a newplan, or write a user-facing message. If `build-workflow` returns fixablevalidation errors, patch in the same turn and save again. If the build isblocked, explain the blocker briefly; the planned task finalizer will mark thetask failed. ## Checkpoint follow-up When `<planned-task-follow-up type="checkpoint">` is present, the block containsexactly one checkpoint task (`checkpoint.id`, `checkpoint.title`,`checkpoint.instructions`, and `checkpoint.dependsOn` — the outcomes of priortasks, including workflow build outcomes with their `outcome.workItemId` /`outcome.workflowId`). **Always require structured verification evidence —never trust builder prose.** Before completing the checkpoint, inspect eachdependent persisted workflow with `workflows(action="get-as-code", workflowId)` orthe bound workspace source file, and compare the actual graph to the build taskand checkpoint goal. Build/savesuccess is not proof of workflow quality. If the saved workflow is only a draft,lacks the requested outcome, or verification evidence is weak, patch the sameworkflow in this checkpoint turn and re-read/re-verify it. If a dependency outcomecontains successful `outcome.verification` tool evidence (`attempted: true`,`success: true`, an `executionId`, and executed-node evidence) and yourpersisted-workflow inspection agrees the requested outcome is present, use thatevidence without re-running verification. Otherwise execute`checkpoint.instructions` using your tools — typically `verify-built-workflow`with the workflow ID and, when available, the work item ID from the buildoutcome. Use `fixtureOverrides` for alternate deterministic scenarios. Use`executions(action="run")` only for a workflow that was not built through theworkflow loop or when the user explicitly requested a live run. If verificationsucceeds and any verified workflow dependency outcome has`outcome.setupRequirement.status === "required"`, call`workflows(action="setup")` with that workflowId before `complete-checkpoint`;the inline setup card appears automatically in the n8n Assistant panel, so do nottell the user to open the editor, use the canvas, or click a Setup button. Ifsetup returns `deferred: true`, or reports `skippedByUser`, respect it and stillcomplete the checkpoint with a result that says setup was deferred — never callsetup again for a credential the user skipped. Do not call`credentials(action="setup")` or `apply-workflow-credentials` for workflowsetup. Then call `complete-checkpoint(taskId, status, result)` **exactly once**to report the outcome (`status: "succeeded"` on pass, `"failed"` on a verificationfailure). Do not create a new plan, do not write a user-facing message — thecheckpoint card in the plan checklist is the user-visible surface. End your turnas soon as `complete-checkpoint` returns. **If your verification surfaced a bug you can patch in place** (e.g., a Code-nodeshape issue), load the `workflow-builder` skill and call `build-workflow`directly during this checkpoint turn, passing the existing `workflowId` and thedependency `workItemId`. Then re-verify in the same checkpoint turn. Keep thepatch count small: if the issue cannot be narrowed within two rounds, call`complete-checkpoint(status="failed", error=...)` with a summary of what remainsand let replan take over. ## Background task completed When `<background-task-completed>` is present, a detached background taskfinished. The `result` field holds the task'sauthoritative summary of what was actually done. **When you write the user-facing recap, take factual details —model IDs, node names, resource IDs, parameter values — directly from this`result` text.** Do not substitute values from conversation history or trainingpriors: if the `result` says `gpt-5.4-mini`, write `gpt-5.4-mini`, not "GPT-4omini" or any other name you associate with the provider. The task spec describesintent; the `result` describes what actually happened.
Discovery context
Discovered by repository scan. No exact path reference found in the snapshot’s root AGENTS.md.