planning

Source excerpt starting at line 1.

1---2name: planning3dependencies:4  tools:5    - create-tasks6description: >-7  ONLY for coordinated multi-artifact work: multiple workflows with dependencies,8  shared data-table schema/migration across tasks, or the user explicitly asked9  to review a plan first. Load create-tasks via load_tool before calling it10  (search "create tasks" if not visible). Do NOT use for new one-off workflows,11  single-workflow edits, verification-only requests, or standalone data-table12  ops — use workflow-builder or data-table-manager instead.13recommended_tools:14  - create-tasks15  - workflows16  - nodes17  - credentials18  - data-tables19  - parse-file20  - research21  - ask-user22---23 24# Planning25 26Use this skill to design a dependency-aware task graph in the orchestrator and27submit it with `create-tasks`. Do not spawn another agent and do not use28incremental plan item tools.29 30Before calling `create-tasks`, load it via `load_tool` (search "create tasks" if31it is not visible).32 33## When NOT to use this skill34 35Stop and use `workflow-builder` + `build-workflow` instead when the request is:36 37- A new or one-off single workflow, even if it sounds large or unfamiliar38- An edit to one existing workflow (nodes, expressions, credentials, schedule, Code)39- Verification, setup, or credential collection for a workflow you just built40- A workflow-local data table whose schema ships with that same workflow41- Standalone data-table list/schema/query/create/mutation work42 43Do not call `create-tasks` just to get approval, verification, or a checklist for44a single workflow. Workflow verification is automatic from structured build45outcomes after `build-workflow`.46 47## When to use this skill48 49Planning is only for work that needs coordination: multiple workflows,50dependencies between workflows, shared data-table schema or migration work across51tasks, multiple durable artifacts, broad best-practice research across many52sources, genuinely ambiguous business-process architecture that cannot be53resolved with one `build-workflow` call, or an explicit user request to review a54plan first.55 56If shared data tables are involved, load `data-table-manager` before this skill57and carry the relevant table guidance into workflow task specs. Clear58single-workflow builds and existing-workflow edits use `workflow-builder` with59`build-workflow` directly. Standalone data-table work uses `data-table-manager`60with direct `data-tables` and `parse-file` calls.61 62## Knowledge Base63 64**Consult the knowledge base before planning.** It lives at the workspace root.65Read the relevant `.md` guides and templates for each technique the request66involves (`${N8N_WORKSPACE_DIR}/knowledge-base/index.json`,67`${N8N_WORKSPACE_DIR}/knowledge-base/best-practices/index.json`, and linked68files). Use `workspace_execute_command` with `rg` or `find` under69`${N8N_WORKSPACE_DIR}/knowledge-base/templates/` to locate matching SDK70examples — never load `templates/index.json` wholesale.71Skip only for trivial mechanical edits you have already reviewed in this thread.72 73## Method74 751. Decide whether the request is plan-worthy by coordination need, not by76   whether a workflow is new.772. Discover what materially affects the plan with normal tools:78   `nodes(action="suggested")`, `credentials(action="list")`,79   `data-tables(action="list")`, `parse-file`, `workflows`, and `research`80   when relevant.81 823. Prefer reasonable assumptions over questions. Ask the user only when the83   answer would materially change the plan and cannot be discovered.844. Build a dependency-aware graph. Producers must come before consumers.85   Independent tasks should not depend on each other.865. Put single workflow-local table requirements inside that workflow task spec.87   Do not create separate data-table tasks unless the table work is a durable88   artifact shared across tasks.896. Add checkpoint tasks only for exceptional semantic checks that normal90   workflow verification cannot cover.917. Load `create-tasks` via `load_tool` if needed, then call `create-tasks` with92   `planningContext.source: "planning-skill"`,93   a concise `summary`, optional `assumptions`, `postBuildRunRequested: true`94   only when the user explicitly asked to run, execute, or test a workflow95   after building it, and the final task graph.968. After calling `create-tasks`, do not write visible text. The approval card is97   the user-visible surface.98 99## Task Graph Rules100 101- Use task kinds exactly as supported: `build-workflow` and `checkpoint`.102- Each task `id` must be stable and referenced by dependency edges.103- Each `title` should be short and user-facing.104- Each `spec` must be the complete executor briefing for that task. The task105  executor may not see your broader planning notes.106- For `build-workflow` tasks, make `spec` a structured executor briefing, not107  freeform prose. Include these labels in this order: `Outcome`,108  `Trigger mode`, `External systems`, `Required effects`, `Required branches`,109  `Required data`, `Explicit constraints`, `Empty/invalid behavior`, and110  `Done when`.111- In `Required effects`, list every observable action the user asked for, such112  as send email, send Telegram, write Google Sheets, create Notion pages, upsert113  Data Table rows, or post one Slack summary.114- In `Required branches`, state partial-failure behavior when multiple effects115  start from the same trigger, and state whether no-results or invalid-input116  paths need an explicit notification, fallback, log, or no-op.117- In `Required data`, name fields needed by later conditions, filters, ranking,118  response messages, or downstream effects, and note when those fields must119  remain available after side-effect nodes that replace item JSON.120- In `Explicit constraints`, preserve concrete user-provided resource names,121  channels, tables, labels, URLs, and required node families or mechanisms. If122  the user explicitly says to use a node family or mechanism such as HTTP123  Request, webhook, form, MCP, or a service-native node, treat that as a hard124  requirement unless it is impossible or contradicts another stated requirement.125  Do not move those values to assumptions, replace them with placeholders, or126  silently swap them for a more convenient alternative.127- In `Empty/invalid behavior`, distinguish data that invalidates the whole item128  from data that only affects one requested effect. For multi-effect intake129  workflows, do not turn a field into a workflow-wide rejection requirement130  merely because one message or side effect uses it.131- In `Done when`, write observable acceptance checks, including final actions132  and branch behavior. Do not write node-by-node wiring or fake user data.133- If a `build-workflow` task's final deliverable is a supporting sub-workflow,134  set `isSupportingWorkflow: true` on that task. Do not set it for helper135  sub-workflows that are only intermediate artifacts inside a larger main136  workflow task.137- For `checkpoint` tasks, write structured semantic verification instructions:138  `Verify trigger mode`, `Verify external systems`, `Verify required effects`,139  `Verify required branches`, `Verify required data`,140  `Verify explicit constraints`, `Verify empty/invalid behavior`, and141  `Pass condition`. Checkpoints are exceptional; use this structure only when a142  checkpoint is actually warranted.143 144## Assumptions And Questions145 146- Never ask about things tools can discover, such as available credentials,147  existing data tables, workflow names, node availability, or attached-file148  structure.149- Never ask for implementation details such as node choices, column names, or150  trigger mechanics when a sensible default exists.151- Never ask for the user's timezone when the current date/time section includes152  it. Use that timezone for schedule times, cron assumptions, and digest windows.153- Never default resource identifiers the user did not mention, such as Slack154  channels, calendars, spreadsheets, folders, databases, or recipient lists.155  Leave them for the builder to resolve or collect through setup.156- Trust already-collected briefing context. If the conversation or task briefing157  includes already-collected answers or already-discovered resources, treat them158  as authoritative and do not ask again for purpose, trigger, integrations,159  schedule, model, resource, or credential choices already listed there.160- A question is asked at most once. Once the user has answered, deferred161  ("later"), or skipped it, never re-present it. On a skip or deferral, record a162  sensible assumption in `planningContext.assumptions` where a default exists163  (for example a default morning time for a digest), otherwise leave the detail164  for the builder or setup — do not block on it and do not ask again.165- If exactly one matching credential exists, assume it and mention the166  credential name in `planningContext.assumptions`.167- If no matching credential exists, plan normally. The builder will mock or168  leave it unresolved and route setup after verification.169- If multiple matching credentials exist and the user did not name one, ask once170  with `ask-user` because the choice cannot be discovered.171- Use credential-backed resource investigation only when it changes the plan,172  for example validating a named Slack channel that affects the architecture. Do173  not turn resource lookup into a credential-choice question unless the174  multiple-credentials rule applies.175 176## Checkpoints177 178Workflow verification is automatic from structured build outcomes. Do not add179routine "verify this workflow" checkpoint tasks for every workflow.180 181Checkpoint tasks are exceptional semantic checks. Use them for cross-workflow182contracts, confirming a report combines upstream data correctly, validating a183business invariant across deliverables, or checking a condition that cannot be184covered by normal runtime verification.185 186Do not add checkpoints for routine verification-only work.187 188## Revisions189 190If the user rejects the plan with requested changes, revise surgically, load191`create-tasks` via `load_tool` if needed, and call `create-tasks` again in the192same orchestrator run with193`planningContext.source: "planning-skill"`.194 195If the user denies the plan outright, stop. Do not call `create-tasks` again in196the same message group.197