/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>`.

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.

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.

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 AI Assistant panel is the user-visible surface. If it returns `deferred: true`, respect the user's choice and do not retry with any other setup tool. 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 — search with `credentials(action="search-types")`. 2. **Simplified Custom Auth** (`httpTemplatedCustomAuth`) for any service without a dedicated type whose auth is expressible as header/query/body values — which covers API keys and bearer tokens (`Authorization: Bearer <token>` becomes `{"headers":{"Authorization":"Bearer {{api_key}}"}}`, not `httpBearerAuth`). Always provide a recipe (below) so the user only pastes their secret. 3. **Plain generic types** (`httpBasicAuth`, `httpDigestAuth`, `oAuth2Api`, …) only for what a template cannot express: basic auth's base64-encoded pair, digest's challenge-response, OAuth flows — or when the user explicitly asks for a specific plain type: an explicit user choice wins (setup accepts it with `allowPlainGenericAuth: true`).

Credential recipes for Simplified Custom Auth

When the workflow authenticates a service through Simplified Custom Auth, include `credentialHints` in the same `workflows(action="setup")` call so the setup card pre-fills the credential and the user only pastes their secret — instead of facing an empty JSON template they'd have to decode from the provider's docs. Before composing the hints, load the `credential-recipe-research` skill and execute its lookup procedure — the template, `docsUrl` and `testUrl` must come from the provider documentation it has you fetch, never from memory:

• `template` — the auth request parts (headers/qs/body) exactly as documented,

with `{{placeholder}}` markers where the user's values go.

• `placeholders` — one entry per marker: `name`, user-facing `title`, an

optional `info` clarifying the value itself — its format or which of the provider's tokens it is (e.g. "Starts with tvly-"). Never where to obtain it, and never a URL or domain: the user asks the AI Assistant for that from the credential form. `type` is `password` unless clearly non-secret (at least one placeholder must stay `password`). Add `optional: true` only when the provider documents the value as optional (e.g. an org/region qualifier) — template entries referencing an empty optional placeholder are omitted from the request.

• `docsUrl` — the provider page where a logged-in user CREATES/COPIES the

secret (e.g. `https://replicate.com/account/api-tokens`) — never the API reference. Not shown in the form: the AI Assistant help thread uses it to send the user to the exact page. Found via the `credential-recipe-research` procedure; omit when it finds nothing conclusive.

• `testUrl` — a documented side-effect-free GET that rejects a bad key with

401/403, used to verify the credential on save and later retests; never one of the workflow's own endpoints, never anything billable. Found via the `credential-recipe-research` procedure; omit when nothing qualifies — a credential without a testUrl saves fine and honestly shows "could not be verified", which beats a false green.

• `acceptedStatusCodes` — almost always omit; the user can adjust it later on

the credential if a service's auth answers 401/403 to valid GETs.

• `suggestedName` — display name for the created credential.

Example — fal.ai's docs say requests use `Authorization: Key <FAL_KEY>` and `GET https://api.fal.ai/v1/models/usage` is a documented side-effect-free endpoint that rejects a bad key (the model-serving host `fal.run` is not a key-check endpoint):

{
  "action": "setup",
  "workflowId": "...",
  "credentialHints": [
    {
      "suggestedName": "fal.ai API Key",
      "template":