Setting the skill. One moment.
43 skills · 279 min
Skills
Skill 17 of 43
Load immediately after an Agent intent. Then call build-agent with the user’s request after any required orchestrator-owned prerequisites are ready.
5 minutes · 1,163 words · 8 sections
Install
npx skills add n8n-io/n8n --skill agent-buildernpx skills add n8n-io/n8n/plugin marketplace add n8n-io/n8nThe first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.
Use this skill after intent-recognition chooses an agent-anchored design, or
when the conversation already targets an Agent and the user is continuing that
build. Do not rerun intent recognition for routine Agent edits or extensions.
Use build-agent only for Agent artifacts.
For a new Agent request, make the first build-agent call with a faithful copy
of the request as soon as any required orchestrator-owned prerequisites are
ready. Before that call, use ask-user only to choose a supported channel or to
define a workflow or data-table prerequisite that the orchestrator must create.
Only ask about the channel after list-agent-capabilities shows that the
requested channel is unsupported. Do not collect model, service, tool, topic,
schedule, credential, or other Agent implementation choices first. The embedded
Agent Builder asks those questions through the build-agent call.
When the conversation opens from an existing Agent in the editor and the user
asks to change its configuration or capabilities, that is an agent-anchored
request — target that Agent and call build-agent. Do not reroute to
workflow-builder, and do not spawn a workflow to satisfy a capability change
on the Agent.
list-agent-capabilities returns every chat channel n8n Agents support, each
with capabilities, useIntegrationWhen, and useNodeToolWhen. It is the
authoritative source the orchestrator can read before building; a channel
absent from its result is unsupported for agents.
When the user asks for a channel that is not supported (e.g. WhatsApp,
Microsoft Teams), do not forward it to the builder as a channel to configure
and do not fake it by adding the platform as an agent tool. Explain the channel
is unsupported for agents, offer the supported alternatives, and ask which to
use — or whether the user explicitly wants that unsupported platform as the
conversation surface, in which case offer the agent-entrypoint workflow
bridge described in Prerequisites (it connects the platform trigger to Message
an Agent; it is not a channel config). Only forward a channel to build-agent
once it is a supported type or the user has chosen an alternative.
Treat message as a faithful handoff of the user’s request, not an Agent build
specification authored by you. Forward the user’s wording as close to verbatim
as possible. Include only:
The host appends an block with the current user text and pending ask-user answers that have not yet reached Agent Builder. Treat those as the user’s decisions for this build call, not as implementation you invented. Still copy user-stated model, channel, and credential choices into message; do not omit them because the host also injected them.
Never infer, invent, expand, recommend, or prescribe implementation details the user did not request, and never present your assumptions as user requirements. In particular, do not choose or tell the builder which model, instructions, tools, tool types, integrations, channels, MCP servers, workflows, skills, tasks, memory, credentials, triggers, schedules, approvals, or test strategy to use.
Do not translate an outcome or named service into a specific implementation. For example, forward “a Slack agent that says hello to me” without turning it into a request for a Slack node tool. Preserve unspecified and ambiguous implementation details so the builder can resolve them with its own guidance and interactive tools.
Before the first build-agent call, create prerequisites the builder cannot
create when they must be attached to or used by the Agent:
workflow-builder, then pass the built workflow in workflowContext.data-table-manager
and create the required tables via data-tables. The builder cannot create
tables.List prerequisite names and schemas in message. Let the builder gather the
remaining Agent-specific requirements, including model, credentials,
integrations, and direct tools.
build-agent can return structured requiredArtifacts when the embedded
builder discovers something Instance AI must create:
relationship: "agent-tool", build it, pass it in
workflowContext, and call build-agent again so the builder can attach it.relationship: "agent-entrypoint", build it after the
Agent exists, using the returned agentId. This workflow invokes the Agent;
never pass it in workflowContext, never attach it to the Agent as a tool,
and do not call build-agent again solely to attach it.build-agent again with its name and
schema in message.For an unsupported chat channel, an agent-entrypoint workflow should connect
the platform trigger to Message an Agent, map the incoming message, use a
stable platform conversation/sender identifier as the custom session key, and
send the Agent’s text response through the platform. Native Agent channels do
not need this wrapper.
If an older builder only lists missing workflows or tables in builderReply,
handle them the same way based on whether the workflow calls the Agent or is
called by the Agent. Never ask the user to create prerequisites manually.
Address Agents in this conversation with agentRef, a short stable key similar
to a workflow filePath.
agentRef and name.agentRef on later calls. Calls with neither agentRef nor
agentId continue editing the current Agent.createNew: true with a different
agentRef and name.agentId once,
optionally with an agentRef, then prefer the returned agentRef.Naming or renaming the current Agent never silently creates another one.
When the user asks for an Agent that uses other newly built Agents as saved sub-agents:
agentRef before attaching it to the
parent.build-agent for the parent and identify the child by its display name.
The parent builder must discover the saved child and map its name to the
valid stored ID. Do not pass a raw agentId as a user requirement.When the user asks to test, run, publish, activate, make usable, unpublish, or
otherwise change the Agent, forward that intent in message. The builder owns
its internal testing tools; do not conclude testing is unavailable because
those tools do not appear in your toolset.
When the builder needs a user choice, credential, chat channel, or approval, it
surfaces an interactive card in this chat. Do not relay the question yourself;
the build-agent call resumes with the user’s answer.
When you send the user to the agent editor, use the labels they see:
Never say Runs tab, Executions tab, Activity History, or Runs Activity History for an agent.
Load immediately after an Agent intent. Then call build-agent with the user's request after any required orchestrator-owned prerequisites are ready. Agent Builder owns Agent setup and implementation questions. Governs prerequisite creation, faithful handoff, targeting, testing, and publishing. Use directly for routine Agent follow-ups; rerun intent-recognition only when the requested artifact is no longer clear.
The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.
master, last pushed 24 September 2026.SKILL.md, not by matching a directory convention. 5 distinct layouts observed: .agents/skills/*/SKILL.md, .claude/plugins/n8n/skills/*/SKILL.md, .opencode/skills/*/SKILL.md, packages/@n8n/cli/skills/*/SKILL.md, packages/@n8n/instance-ai/skills/*/SKILL.md.h1 and no skipped levels:.claude/plugins/n8n/.claude-plugin/marketplace.json by n8n, declaring 1 plugin. It is read for editorial metadata only — never as the skill index, which is always the repository tree./n8n-io/n8n.md, and each skill at its own .md URL.