SKILL.md
1,656 tokens · o200k_base · 7,778 bytes
Source excerpt starting at line 1.---name: agent-builderdescription: >- 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.recommended_tools: - build-agent - build-workflow - data-tables--- # Agent Builder ## Routing Use this skill after `intent-recognition` chooses an agent-anchored design, orwhen the conversation already targets an Agent and the user is continuing thatbuild. 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 copyof the request as soon as any required orchestrator-owned prerequisites areready. Before that call, use `ask-user` only to choose a supported channel or todefine a workflow or data-table prerequisite that the orchestrator must create.Only ask about the channel after `list-agent-capabilities` shows that therequested channel is unsupported. Do not collect model, service, tool, topic,schedule, credential, or other Agent implementation choices first. The embeddedAgent Builder asks those questions through the `build-agent` call. When the conversation opens from an existing Agent in the editor and the userasks to change its configuration or capabilities, that is an agent-anchoredrequest — target that Agent and call `build-agent`. Do not reroute to`workflow-builder`, and do not spawn a workflow to satisfy a capability changeon the Agent. ## Supported channels & unsupported requests `list-agent-capabilities` returns every chat channel n8n Agents support, eachwith `capabilities`, `useIntegrationWhen`, and `useNodeToolWhen`. It is theauthoritative source the orchestrator can read before building; a channelabsent 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 configureand do not fake it by adding the platform as an agent tool. Explain the channelis unsupported for agents, offer the supported alternatives, and ask which touse — or whether the user explicitly wants that unsupported platform as theconversation surface, in which case offer the `agent-entrypoint` workflowbridge described in Prerequisites (it connects the platform trigger to Messagean 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. ## Faithful handoff Treat `message` as a faithful handoff of the user's request, not an Agent buildspecification authored by you. Forward the user's wording as close to verbatimas possible. Include only: - Requirements, constraints, and implementation choices the user explicitly stated.- Explicit answers or decisions from earlier turns that are necessary for the current request.- Prerequisite workflows or data tables you created for this Agent. Never infer, invent, expand, recommend, or prescribe implementation details theuser 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 touse. 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 itinto a request for a Slack node tool. Preserve unspecified and ambiguousimplementation details so the builder can resolve them with its own guidanceand interactive tools. ## Prerequisites Before the first `build-agent` call, create prerequisites the builder cannotcreate when they must be attached to or used by the Agent: - Create a workflow tool only when one Agent tool call must run an ordered multi-node procedure, or when the user explicitly needs that workflow to be reusable, manually callable, or usable outside the Agent. Follow `workflow-builder`, then pass the built workflow in `workflowContext`.- When the Agent will store or query tabular data, follow `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 theremaining Agent-specific requirements, including model, credentials,integrations, and direct tools. `build-agent` can return structured `requiredArtifacts` when the embeddedbuilder discovers something Instance AI must create: - For a workflow with `relationship: "agent-tool"`, build it, pass it in `workflowContext`, and call `build-agent` again so the builder can attach it.- For a workflow with `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.- For a data table, create it and call `build-agent` again with its name and schema in `message`. For an unsupported chat channel, an `agent-entrypoint` workflow should connectthe platform trigger to Message an Agent, map the incoming message, use astable platform conversation/sender identifier as the custom session key, andsend the Agent's `text` response through the platform. Native Agent channels donot 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 iscalled by the Agent. Never ask the user to create prerequisites manually. ## Targeting across turns Address Agents in this conversation with `agentRef`, a short stable key similarto a workflow `filePath`. - For the first Agent, pass a fresh `agentRef` and `name`.- Reuse that `agentRef` on later calls. Calls with neither `agentRef` nor `agentId` continue editing the current Agent.- To build an additional Agent, pass `createNew: true` with a different `agentRef` and `name`.- To edit an Agent not built in this conversation, pass its `agentId` once, optionally with an `agentRef`, then prefer the returned `agentRef`. Naming or renaming the current Agent never silently creates another one. ## Saved sub-agent dependencies When the user asks for an Agent that uses other newly built Agents as savedsub-agents: 1. Build each child Agent under its own `agentRef` before attaching it to the parent.2. Call `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.3. Publication is not required for saved sub-agent delegation. Forward publication intent only when the user explicitly asks to publish or activate an Agent. ## Builder-owned interactions When the user asks to test, run, publish, activate, make usable, unpublish, orotherwise change the Agent, forward that intent in `message`. The builder ownsits internal testing tools; do not conclude testing is unavailable becausethose tools do not appear in your toolset. When the builder needs a user choice, credential, chat channel, or approval, itsurfaces an interactive card in this chat. Do not relay the question yourself;the `build-agent` call resumes with the user's answer.
Discovery context
Discovered by repository scan. No exact path reference found in the snapshot’s root AGENTS.md.