| name | stack-intake |
| description | Guided interview that turns a rough idea into a PRP-style use-case description ready for /n8n-autopilot:build-stack-v2. Classic question-by-question format aimed at people NOT yet experienced with n8n — it asks about overall inputs, outputs, a concrete worked example, expected behavior, external systems, volume, and failure handling, then synthesizes the answers (using n8n decomposition knowledge) into a structured PRP file. Use when the user has an automation idea but no clear spec, says 'help me plan an n8n workflow/stack', 'I want to automate X but don't know how', or before running build-stack-v2 without a written use case. |
| argument-hint | "<one-line idea>" (optional — the interview fills in the rest) |
| user-invocable | true |
| allowed-tools | Read, Write, Glob, Bash(npx:*), AskUserQuestion |
Stack Intake — guided PRP interview
Most people can describe what they want ("when a lead comes in, research it and tell me if it's
worth chasing") but not how to wire it in n8n. This skill bridges that: a friendly, classic
interview that draws out inputs, outputs, and concrete examples, then writes a PRP-style use-case
description that /n8n-autopilot:build-stack-v2 can decompose into a
real workflow stack. You do the n8n thinking; the user only describes their world.
Principles
- One topic at a time. Ask, listen, follow up. Do NOT dump all questions at once — this is an
interview, not a form. Adapt: skip what's already obvious, dig where it's vague.
- Speak their language, not n8n's. Never ask "what trigger type?" Ask "how does this start — does
someone fill a form, does it run on a schedule, does an email arrive?" Map their answer to n8n
concepts yourself.
- Always anchor on a concrete example. Abstract specs decompose badly. Make them walk one real case
end-to-end ("Okay — a lead named Acme GmbH arrives. What happens first? Then?").
- You hold the n8n knowledge. Use what you know about decomposition (single-responsibility leaves,
fan-out/fan-in for lists, error boundaries, large-data batching, human-in-the-loop) to ask the RIGHT
follow-ups — but never make the user learn it. If unsure of an n8n capability, you may consult the
n8nac-cheatsheet / n8n-orchestration-patterns skills, not the user.
The interview (cover every section; adapt the wording)
Use AskUserQuestion for the closed choices (trigger family, volume, error policy, HITL) so the user
just clicks; use plain conversation for the worked example and free descriptions.
- The goal in one sentence. "In one line, what should this automation achieve?" (Seed from
$ARGUMENTS if given.)
- How it starts (input / trigger). A schedule? A webhook/form someone submits? An incoming email?
A chat message? A manual run? — and what data comes with it. Ask for a concrete example of the
input (a sample form, an example email, a row of data).
- What "done" looks like (output). When it finishes, what exists that didn't before, and where
does it land — a Slack message, a Notion page, a row in a database, a sent email, a file? Ask for an
example of the finished result.
- One worked example, end-to-end. Walk a single real case from trigger to output, step by step, in
their words. This is the most important answer — capture it verbatim.
- External systems & accounts. Which apps/services does it touch (Slack, Notion, Gmail, a CRM, an
LLM, a database, a scraping API …)? Each one likely needs a credential — note them, don't set them up.
- Volume & batching. One thing at a time, or a list/batch? Roughly how many per run? (This decides
fan-out/fan-in and large-data handling — infer it, don't quiz them on it.)
- When something goes wrong. If a step fails (an API down, a record missing), should it stop and
alert, skip that item and continue, or retry? (Maps to error boundaries.)
- Human checkpoints. Any step where a person must review/approve before it proceeds?
- Reuse & scope. Is any part of this already done elsewhere, or useful on its own? Anything
explicitly out of scope for now?
If the user is stuck on a question, offer 2–3 concrete examples to react to rather than leaving it open.
Synthesize → write the PRP
When the sections are covered, synthesize (do not just transcribe) into this structure and write it to
docs/stack-prps/<stack-slug>.prp.md (create the dir; <stack-slug> = kebab-case of the goal). Convert
the user's prose into n8n-flavoured signals where you confidently can, but never invent requirements
they didn't state — mark genuine gaps as OPEN:.
# <Stack name> — Use-Case PRP
> Intake interview <date>. Feeds /n8n-autopilot:build-stack-v2.
## Goal
<one-paragraph outcome>
## Trigger & input
- **Starts via:** <schedule / webhook / form / email / chat / manual>
- **Incoming data:** <fields>
- **Example input:**
```
Desired output
- Result:
- Lands in: <Slack / Notion / DB / email / file>
- Example output:
Worked example (end-to-end)
<the user's one real case, trigger → output, in clear steps>
External systems & credentials
Volume & batching
<one item vs list; rough count; implication for fan-out / batching>
Error handling
<stop-and-alert / skip-and-continue / retry, per the user's answer>
Human-in-the-loop
<any approval/review steps, or "none">
Reuse & scope
- Reusable / standalone parts: <…>
- Out of scope: <…>
Decomposition hints (for the architect — derived, not user-stated)
<your read: likely leaves, where a fan-out/fan-in applies, error/large-data boundaries, the entry orchestrator>
## Hand off
After writing the file, show the user a short summary and offer the next step verbatim:
> PRP written to `docs/stack-prps/<slug>.prp.md`. Run it with:
> `/n8n-autopilot:build-stack-v2 "<paste the Goal + key sections, or 'see docs/stack-prps/<slug>.prp.md'>"`
Do **not** auto-run build-stack-v2 — building deploys workflows to the instance; that needs an explicit
go from the user. If they confirm, pass the PRP content as the `description` arg to build-stack-v2.
## Limits
- This skill only **plans** — it never touches the n8n instance and writes nothing but the PRP file.
- The quality of the stack depends on the worked example. If the user can't give one concrete case,
say so in the PRP (`OPEN: no concrete example`) rather than guessing the behavior.
