fix(ai-builder): Prevent orchestrator and planner from assuming resource identifiers (no-changelog) (n8n-io#28342)

Author: aalises

packages/@n8n/instance-ai/src/agent/system-prompt.ts

@@ -188,7 +188,7 @@ Never use \`delegate\` to build, patch, fix, or update workflows — delegate do
 
 To fix or modify an existing workflow, use a \`build-workflow\` task (via \`plan\` if multi-step, or \`build-workflow-with-agent\` directly if single) with the existing workflow ID and a spec describing what to change.
 
-The detached builder handles node discovery, schema lookups, resource discovery, code generation, validation, and saving. Describe **what** to build (or fix), not **how**: user goal, integrations, credential names, data flow, data table schemas. Don't specify node types or parameter configurations.
+The detached builder handles node discovery, schema lookups, resource discovery, code generation, validation, and saving. Describe **what** to build (or fix), not **how**: user goal, integrations, credential names, data flow, data table schemas. Don't specify node types or parameter configurations. Mention integrations by service name (Slack, Google Calendar) but don't specify which channels, calendars, spreadsheets, folders, or other resources to use — the builder resolves real resource IDs at build time.
 
 Always pass \`conversationContext\` when spawning background agents (\`build-workflow-with-agent\`, \`delegate\`, \`research-with-agent\`, \`manage-data-tables-with-agent\`) — summarize what was discussed, decisions made, and information gathered. Exception: \`plan\` reads the conversation history directly — only pass \`guidance\` if the context is ambiguous.
 

packages/@n8n/instance-ai/src/tools/orchestration/plan-agent-prompt.ts

@@ -13,6 +13,7 @@ You receive the recent conversation between the user and the orchestrator. Read
 1. **Prefer assumptions over questions.** The user is waiting for a plan, and they can reject it if your assumptions are wrong — so default to making reasonable choices rather than asking.
    - **Never ask about things you can discover** — call \`list-credentials\`, \`list-data-tables\`, \`get-best-practices\` instead.
    - **Never ask about implementation details** — trigger types, node choices, schedule times, column names. Pick sensible defaults.
+   - **Never default resource identifiers** the user didn't mention (Slack channels, calendars, spreadsheets, folders, etc.) — leave them for the builder to resolve at build time.
    - **Do ask when the answer would significantly change the plan** — e.g. the user's goal is ambiguous ("build me a CRM" — for sales? support? recruiting?), or a business rule must come from the user ("what should happen when payment fails?").
    - **List your assumptions** on your first \`add-plan-item\` call. The user reviews the plan before execution and can reject/correct.
 
@@ -28,10 +29,11 @@ You receive the recent conversation between the user and the orchestrator. Read
    - Set \`summary\` and \`assumptions\` on your first call
    - Each call makes the item visible to the user immediately
    - \`purpose\`: Write a rich, user-focused description of what this item delivers and why. Include key requirements and behaviors from the user's request. 3-5 sentences. Do NOT include node names, parameters, or implementation details — the builder handles that.
-   - \`triggerDescription\`: a few words (e.g. "Webhook POST", "Schedule daily")
+   - \`triggerDescription\`: a few words describing trigger type (e.g. "Webhook POST", "Schedule daily"), no resource identifiers
+   - \`integrations\`: service names only (e.g. "Slack", "Google Calendar"), no resource identifiers or qualifiers
    - \`dependsOn\`: **CRITICAL** — set dependencies correctly. Data tables before workflows that use them. Workflows that produce data before workflows that consume it. Independent workflows should NOT depend on each other.
    - \`columns\`: name and type only — no descriptions
-   - \`assumptions\`: only non-obvious ones
+   - \`assumptions\`: design decisions only, no resource identifiers (channels, calendars, etc.)
    - Use \`research\` kind for tasks requiring web research before other tasks can proceed (e.g. "find the API endpoint format for service X"). Research tasks run a dedicated web research agent.
    - After all items are added, call \`submit-plan\` to request user approval.