/planning

name: planning
description: >-
  ONLY for coordinated multi-artifact work: multiple workflows with dependencies,
  shared data-table schema/migration across tasks, or the user explicitly asked
  to review a plan first. Load create-tasks via load_tool before calling it
  (search "create tasks" if not visible). Do NOT use for new one-off workflows,
  single-workflow edits, verification-only requests, or standalone data-table
  ops — use workflow-builder or data-table-manager instead.
recommended_tools:
  - create-tasks
  - workflows
  - nodes
  - credentials
  - data-tables
  - parse-file
  - research
  - ask-user

Planning

Use this skill to design a dependency-aware task graph in the orchestrator and submit it with `create-tasks`. Do not spawn another agent and do not use incremental plan item tools.

Before calling `create-tasks`, load it via `load_tool` (search "create tasks" if it is not visible).

When NOT to use this skill

Stop and use `workflow-builder` + `build-workflow` instead when the request is:

• A new or one-off single workflow, even if it sounds large or unfamiliar
• An edit to one existing workflow (nodes, expressions, credentials, schedule, Code)
• Verification, setup, or credential collection for a workflow you just built
• A workflow-local data table whose schema ships with that same workflow
• Standalone data-table list/schema/query/create/mutation work

Do not call `create-tasks` just to get approval, verification, or a checklist for a single workflow. Workflow verification is automatic from structured build outcomes after `build-workflow`.

When to use this skill

Planning is only for work that needs coordination: multiple workflows, dependencies between workflows, shared data-table schema or migration work across tasks, multiple durable artifacts, broad best-practice research across many sources, genuinely ambiguous business-process architecture that cannot be resolved with one `build-workflow` call, or an explicit user request to review a plan first.

If shared data tables are involved, load `data-table-manager` before this skill and carry the relevant table guidance into workflow task specs. Clear single-workflow builds and existing-workflow edits use `workflow-builder` with `build-workflow` directly. Standalone data-table work uses `data-table-manager` with direct `data-tables` and `parse-file` calls.

Knowledge Base

**Consult the knowledge base before planning.** It lives at the workspace root. Read the relevant `.md` guides and templates for each technique the request involves (`${N8N_WORKSPACE_DIR}/knowledge-base/index.json`, `${N8N_WORKSPACE_DIR}/knowledge-base/best-practices/index.json`, and linked files). Use `workspace_execute_command` with `rg` or `find` under `${N8N_WORKSPACE_DIR}/knowledge-base/templates/` to locate matching SDK examples — never load `templates/index.json` wholesale. Skip only for trivial mechanical edits you have already reviewed in this thread.

Method

1. Decide whether the request is plan-worthy by coordination need, not by whether a workflow is new. 2. Discover what materially affects the plan with normal tools: `nodes(action="suggested")`, `credentials(action="list")`, `data-tables(action="list")`, `parse-file`, `workflows`, and `research` when relevant.

3. Prefer reasonable assumptions over questions. Ask the user only when the answer would materially change the plan and cannot be discovered. 4. Build a dependency-aware graph. Producers must come before consumers. Independent tasks should not depend on each other. 5. Put single workflow-local table requirements inside that workflow task spec. Do not create separate data-table tasks unless the table work is a durable artifact shared across tasks. 6. Add checkpoint tasks only for exceptional semantic checks that normal workflow verification cannot cover. 7. Load `create-tasks` via `load_tool` if needed, then call `create-tasks` with `planningContext.source: "planning-skill"`, a concise `summary`, optional `assumptions`, `postBuildRunRequested: true` only when the user explicitly asked to run, execute, or test a workflow after building it, and the final task graph. 8. After calling `create-tasks`, do not write visible text. The approval card is the user-visible surface.

Task Graph Rules

• Use task kinds exactly as supported: `build-workflow` and `checkpoint`.
• Each task `id` must be stable and referenced by dependency edges.
• Each `title` should be short and user-facing.
• Each `spec` must be the complete executor briefing for that task. The task

executor may not see your broader planning notes.

• For `build-workflow` tasks, make `spec` a structured executor briefing, not

freeform prose. Include these labels in this order: `Outcome`, `Trigger mode`, `External systems`, `Required effects`, `Required branches`, `Required data`, `Explicit constraints`, `Empty/invalid behavior`, and `Done when`.

• In `Required effects`, list every observable action the user asked for, such

as send email, send Telegram, write Google Sheets, create Notion pages, upsert Data Table rows, or post one Slack summary.

• In `Required branches`, state partial-failure behavior when multiple effects

start from the same trigger, and state whether no-results or invalid-input paths need an explicit notification, fallback, log, or no-op.

• In `Required data`, name fields needed by later conditions, filters, ranking,

response messages, or downstream effects, and note when those fields must remain available after side-effect nodes that replace item JSON.

• In `Explicit constraints`, preserve concrete user-provided resource names,

channels, tables, labels, URLs, and required node families or mechanisms. If the user explicitly says to use a node family or mechanism such as HTTP Request, webhook, form, MCP, or a service-native node, treat that as a hard requirement unless it is impossible or contradicts another stated re