post-build-flow

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.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./packages/@n8n/instance-ai/skills/post-build-flow/SKILL.md

Quality

Content

85%Weight 40%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is highly actionable and well-sequenced with strong validation checkpoints and a real, well-signaled reference file for the bulky trigger-shape detail. Its main weakness is repetition of the same guardrails across sections, which modestly undercuts token efficiency.

Suggestions

Consolidate the repeated guardrails (no auto-publish, no auto-runs to re-test, no unverified success claims) into a single 'Non-negotiables' section and reference it rather than restating in each section.

Consider moving the error-workflow and mocked-live-test follow-up ordering rules into the reference file so the main body stays a lean decision flow.

Tighten the duplicated 'do not acknowledge/write first' guidance in the verification and setup follow-up sections into one shared rule.

Dimension	Reasoning	Score
Conciseness	The body is dense and largely earned (specific tool calls, status branches, and guardrails rather than general concepts), but it repeats the same cautions (do not publish, do not auto-run, do not claim success) across multiple sections and could be tightened to cut redundant restatements.	2 / 3
Actionability	It gives concrete, executable guidance throughout: exact tool calls with arguments (verify-built-workflow with workflowId/workItemId/inputData, workflows(action="setup"), data-tables(action="insert-rows")), field paths to read (verificationReadiness.status, setupRequirement.status, nodesNotReached), and explicit recovery actions per branch.	3 / 3
Workflow Clarity	The 'After build-workflow succeeds' section is a clearly numbered sequence with explicit validation checkpoints (inspect persisted graph, judge coverage not just status, partial-evidence handling, nodesNotReached recovery loops) and feedback loops for error recovery, satisfying the rubric's bar for sequenced steps with validation.	3 / 3
Progressive Disclosure	The body is well-organized into clearly signaled sections and offloads the bulky per-trigger inputData shapes to a real one-level-deep reference file (references/trigger-input-data-shapes.md, confirmed present) with two clearly named load paths, avoiding a monolithic wall of inline detail.	3 / 3
	Total	11 / 12 Passed

Description

50%Weight 40%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description clearly scopes the skill to post-build verification/setup and surfaces concrete trigger payloads, but it leans on machine trigger tokens and tool/field names rather than natural user phrasing and lacks a crisp 'Use when...' clause. It is competent but slightly more routing-specification than user-facing trigger guidance.

Suggestions

Add an explicit 'Use when...' clause phrased in natural user terms (e.g. 'Use after build-workflow succeeds, when the user asks to verify or set up the workflow, or on verification/setup follow-up turns').

Lead with the concrete actions performed (verify built workflows, route setup, handle mocked-test and error-workflow follow-ups) before the trigger-payload conditions.

Sharpen the boundary against the referenced workflow-builder skill so it is clear this skill handles the post-build verification/setup flow rather than building.

Dimension	Reasoning	Score
Specificity	Names the domain (post-build workflow verification/setup) and several concrete trigger fields, but centers on tool/field names rather than enumerating the concrete actions performed; it is more trigger-routing language than a list of specific capabilities.	2 / 3
Completeness	The 'what' is stated (workflow verification and setup after build-workflow) and there is explicit 'Load after...'/'when' guidance, but it is phrased as load conditions rather than a clean 'Use when...' clause tied to natural user phrasing, which caps completeness.	2 / 3
Trigger Term Quality	It surfaces actual trigger tokens users/systems emit ('workflow-verification-follow-up', 'workflow-setup-required') and references verification readiness, but the natural-language terms a user would say (e.g. 'verify', 'set up', 'test workflow') are only implied, with the emphasis on machine payloads.	2 / 3
Distinctiveness Conflict Risk	It is scoped to a distinct post-build niche with specific payload triggers, but the domain overlaps heavily with the workflow-builder and verification skills it references, so it could still be confused for the wrong skill without sharper boundary language.	2 / 3
	Total	8 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: n8n-io/n8n
Path: packages/@n8n/instance-ai/skills/post-build-flow/SKILL.md
Commit: bcbea0a

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.