stack-intake

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.

1. The goal in one sentence. "In one line, what should this automation achieve?" (Seed from $ARGUMENTS if given.)
2. 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).
3. 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.
4. 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.
5. 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.
6. 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.)
7. 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.)
8. Human checkpoints. Any step where a person must review/approve before it proceeds?
9. 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

• — — credential:

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.