/post-build-flow

name: post-build-flow
description: >-
  Handles workflow verification and setup after build-workflow succeeds, or when
  the message contains workflow-verification-follow-up or workflow-setup-required.
  Load after direct builds, when verificationReadiness requires action, or on
  orchestrator verify/setup follow-up turns.
recommended_tools:
  - ask-user
  - verify-built-workflow
  - workflows
  - build-workflow
  - executions

Post-Build Flow

Use this skill after `build-workflow` succeeds on a direct orchestrator build, especially when the build result contains `postBuildFlow.required: true`, or when the current message contains `<workflow-verification-follow-up>` or `<workflow-setup-required>`.

One-off builds (`postBuildFlow.reason: "direct-one-off-build-succeeded"`) hand off to the `one-off-operations` skill instead — verification is optional there and completion is a live run with read-back. If both sets of instructions are in context for a one-off build, the one-off flow wins.

These instructions are in English, but user-visible text you write while following them stays in the user's conversation language.

For trigger `inputData` shapes, read `${N8N_WORKSPACE_DIR}/knowledge-base/reference/trigger-input-data-shapes.md` in the sandbox workspace when available, or load this skill's `references/trigger-input-data-shapes.md` linked file.

Setup panel

Use this section when the system prompt describes the persistent setup panel, setup returns `announced: true`, or the current user input contains `<workflow-test-request>`. Otherwise, keep the setup card flow below.

• Verify what the build can simulate before asking the user to finish setup.

Missing credentials do not prevent this verification. Report which outputs were simulated. A simulated result does not prove a live connection.

• When setup returns `announced: true`, summarize the open items and any

validation warnings. End the turn. The user can complete setup in the panel while chat stays available. Do not wait, poll, or open a trigger-test card.

• On a later user turn, trust `<workflow-setup-state>` over earlier setup

results. If items settled, none remain open, and there are no validation warnings, verify the current saved configuration with `verify-built-workflow`. It refreshes the credential plan. Report remaining simulations or connection failures. Do not claim live success from the earlier build result.

• `<workflow-test-request>` in the current user input means the user clicked

Execute. A block in conversation history does not request another execution. Use the workflow ID in the current block. Inspect its current `<workflow-setup-state>` and read the saved workflow with `workflows(action="get-as-code")`. Do not call `workflows(action="setup")` for this precheck. It announces setup and ends the turn. If the target is absent from the state block, inspect its saved configuration. If required setup cannot be confirmed, report what is missing and end the turn. If required items remain open for this workflow, report them and end the turn without a live run. Otherwise, use `executions(action="run")` with suitable trigger input. The user has already requested this test; do not ask whether they want it. The execution tool still enforces its approval policy. Do not publish the workflow to test it.

• Read the execution output and summarize what ran and what it returned. For

failures, inspect `executions(action="debug")`. Fix the same workflow when possible. Use the current saved source so panel edits are preserved. Report unresolved setup or failures in chat. Before another live run, inspect the successful effect nodes from the failed run. Follow [Cleaning up after a live test](#cleaning-up-after-a-live-test) for any artifacts they left behind. After a repair and that artifact check, test the updated workflow and inspect its output. Do not substitute mocked verification for the requested execution.

A setup card that was already open keeps its apply and trigger-test resume flow. Its result is not a panel announcement unless it has `announced: true`.

Verification follow-up

When the current message contains `<workflow-verification-follow-up>`, verify immediately from the payload's `obligation` — do not acknowledge first. If the obligation is `ready_to_verify` or `verifying`, call `verify-built-workflow`. Do **not** call `workflows(action="setup")` in this turn and do **not** declare the workflow finished if `outcome.setupRequirement.status === "required"` — setup is routed automatically as a separate `<workflow-setup-required>` step after verification. For a multi-trigger outcome, verify every trigger that does not yet have a recorded successful verification. Make all of these calls in this turn.

Setup follow-up

When the current message contains `<workflow-setup-required>`, your first action is to call `workflows(action="setup")` with the `workflowId` from the payload. Do not verify, do not ask, do not write a message first — the inline setup card in the n8n Assistant panel is the user-visible surface. If the result has `announced: true`, use the persistent panel instructions above and end the turn. If it returns `deferred: true`, respect the user's choice and do not retry with any other setup tool. A result carrying `skippedByUser` names credentials the user already passed on: never re-open setup for those, in this turn or any later one — see [Credentials the user skipped](#credentials-the-user-skipped). After setup completes or is applied, follow [Mocked verification live-test follow-up](#mocked-verification-live-test-follow-up) if the payload or prior verification evidence says mocked credentials, simulated node output, fixture overrides, temporary pin data, or another mocked input was used.

Choosing the credential type for a service

Pick in this order:

1. **A dedicated credential type** (`slackApi`, `notionApi`, …) whenever one exists — sear