Feature requests come in at the worst times. A client drops a message at 11pm. A collaborator sends a voice note. You screenshot something and tell yourself you'll deal with it later. Later never comes.
I lost count of how many good ideas got buried in Slack threads or forgotten in a notes app graveyard. So I built a workflow in n8n that takes the chaos and turns it into something Claude Code can actually run with.
Here's how it works.
The Problem With Ad-Hoc Feature Requests
When you're a solo operator or a small team, the intake process for new features is usually nonexistent. Someone says "it would be cool if..." and you either build it immediately (and wreck your current focus) or you forget it entirely.
Even when you remember, the original message is vague. "Make the dashboard faster" tells you nothing. You have to go back, ask questions, wait for answers, then figure out what "faster" actually means to that person.
The gap between raw request and buildable spec is where time dies.
What the Workflow Actually Does
The n8n workflow sits between Slack and my project system. When a message hits a specific channel (I use #feature-inbox), the automation picks it up and runs it through a series of steps before anything reaches a developer, including me.
High level, it does four things:
- Captures the raw message and any thread replies
- Sends it to Claude via API to generate a structured spec draft
- Creates a card in Linear (or Notion, depending on the project) with that draft
- Posts a confirmation back to Slack so the requester knows it was logged
That's it. No magic. Just friction removal at the exact point where requests usually die.
Setting Up the Slack Trigger
In n8n, you start with a Slack trigger node set to watch for new messages in a specific channel. I use the "Message Posted" event type and filter for #feature-inbox.
A few things worth configuring here:
- Set a bot user filter so the workflow doesn't trigger on its own confirmation messages (infinite loops are not fun)
- Grab the thread timestamp so you can pull replies if the original message spawned a discussion
- Store the sender's Slack user ID so you can mention them in the confirmation
If you want thread replies included, add a second Slack node after the trigger that calls conversations.replies using the thread timestamp. Feed all of it into the next step as one combined block of text.
The Claude Prompt That Turns Noise Into Spec
This is where most people underinvest. They send the raw message to Claude and ask it to "make a spec." The output is generic and not useful.
The prompt matters a lot. You need to give Claude context about your stack, your conventions, and what a good spec looks like in your world. I send the message content plus a system prompt that includes my project context, what fields I want in the output, and formatting rules so it drops straight into Linear without cleanup.
The output I ask for looks like this every time:
- Title: One line, verb-first, action-oriented
- User story: As a [user], I want [thing], so that [outcome]
- Acceptance criteria: Bulleted, specific, testable
- Open questions: What Claude couldn't infer and needs a human to answer
- Suggested approach: Optional, but Claude usually nails this if your stack context is in the prompt
That open questions field is underrated. It surfaces ambiguity before you start building, not halfway through.
Pushing to Linear
Once you have structured output from Claude, you parse it (I use a simple JSON mode response so n8n can map fields directly) and push it into Linear via the Linear API node in n8n.
Set the issue to a triage state by default. Nobody builds it yet. It just exists in a clean, reviewable format. You do a quick pass on the open questions field, add any missing context, and move it to backlog or your current cycle when it's ready.
The whole process from Slack message to Linear card takes under 30 seconds and requires zero manual work from you.
The Confirmation Loop
Last node in the workflow is a Slack message back to the original thread. Something simple:
Got it. Created a spec draft in Linear. I'll review and follow up if I have questions.
This closes the loop for whoever sent the request. They know it landed somewhere real, not a black hole. It also sets the expectation that review happens separately from capture. You're not promising to build it, just promising to look at it.
Variations Worth Knowing
This same pattern works for more than feature requests. I've adapted it for:
- Bug reports: Different channel, different Claude prompt that asks for reproduction steps and severity
- Client feedback: Comes in via email, parsed and routed the same way
- Personal ideas: I have a shortcut that texts a number, which triggers a Make.com webhook and feeds into the same n8n pipeline
Once the pattern is in place, you just clone the workflow and swap the prompt and destination.
The prompt and field mapping behind the gate is where the real time savings live, including the classification step that routes bugs versus features automatically. All of that, plus the workflow export files, are inside Inner Circle.
