Build Your First Edgaze Workflow: Blog Post to Tweet Thread

Every good blog post gets read by a few hundred people. The same post, cut into a tweet thread, gets read by a few thousand. The problem is that cutting it up is annoying. You paste the post into a chat window, write a prompt, get something too formal, rewrite the prompt, get something too casual, and twenty minutes later you have six tweets you're not happy with. That's a workflow. It has fixed steps, it runs the same way every time, and it should be a button, not a ritual. In this tutorial you'll build that button. By the end you'll have a working workflow with a public product page: one link, fixed inputs, your prompts hidden, and a run that anyone can start without rewriting your instructions. **Time: about 15 minutes.** No code. --- ## What you're building Four nodes, in a straight line: ```docsgraph blog-to-thread ``` The first AI step pulls the actual ideas out of the post. The second turns those ideas into tweets. That split matters, and it's the single most useful thing in this tutorial. If you ask one model call to "read this and write a thread," it does both jobs badly: it skims for structure and writes about the post instead of writing the post's ideas. Splitting extraction from writing gets you a noticeably better thread for the same money. --- ## Before you start You need an Edgaze account with access to **Workflow Studio** (`/builder`). For test runs in the builder, use **Edgaze-hosted runs** (included builder quota) or switch the LLM nodes to **API Vault** / **My own key** (BYOK) so the provider bills your key directly. Marketplace buyers fund runs from their wallet or a free demo when one is available. You do not need wallet balance just to draft and test this workflow. That's it. --- ## Step 1 — Create the workflow Open **Workflow Studio**. In the launcher, hit **New** (subtitle: Start a new workflow). Name it something you'd actually search for later. `Blog to Thread` beats a generic draft name. You'll land on an empty canvas. Drag nodes in from the left panel; click any node to open its config in the inspector on the right.  --- ## Step 2 — Add the input node Drag in a **Workflow Input** node. This is what the person running your workflow actually fills in. Configure it in the inspector **User input** card: | Field | Value | | ---------------------- | ------------------------------ | | Question | Blog post | | Description (optional) | Paste your full blog post here | | Input type | Long Paragraph | The **Question** is what runners see on the run form. Keep it short and clear. 

--- ## Step 3 — Extract the ideas Drag in an **LLM Chat** node and connect the input node's output port to its input port. Just drag from one circle to the other. The edge snaps into place. Set the model to **GPT-5.6 Luna**. It's the fast, low-cost tier and more than good enough for extraction. ```prompt @@label: Style / System (optional) You are an editor who reads long-form writing and identifies which ideas are strong enough to stand alone. You are ruthless about cutting filler, throat-clearing, and restatement. ``` ```prompt @@label: Prompt Read the blog post in the inputs. Pull out the 5 to 7 strongest standalone ideas: the claims a reader would screenshot or argue with. For each one, write: - The idea, in one sentence, in plain language - The specific detail, number, or example from the post that backs it up Ignore introductions, conclusions, and anything that only exists to transition between sections. If the post makes the same point twice, keep the better version and drop the other. Output as a numbered list. No preamble. ``` Because the input node is connected, Edgaze feeds the pasted post into this step automatically as inbound input. You don't need to re-paste it into the prompt. Keep the instructions here and the source material on the wire.  Two things worth noticing about that prompt. It asks for evidence alongside each idea, which is what stops the second step from writing vague tweets. And it keeps the job narrow (extract only) so the model isn't also trying to sound like a Twitter account. --- ## Step 4 — Write the thread Add a second **LLM Chat** node and connect it to the first. Use a stronger model here: **GPT-5.6 Terra**. Extraction is mechanical; voice is not. This is the one place in the workflow where paying more actually shows up in the output. ```prompt @@label: Style / System (optional) You write tweet threads that people finish. You write in plain declarative sentences. You never use hashtags, never use emoji as bullet points, and never end a thread by asking people to like and retweet. ``` ```prompt @@label: Prompt Turn the ideas in the inputs into a tweet thread. Rules: - 6 to 9 tweets total - Each tweet under 270 characters - Tweet 1 states the single most surprising idea as a flat claim. No "a thread", no "let's talk about", no question openers. - Each following tweet makes exactly one point and includes the specific detail that supports it - The last tweet lands on an implication, not a summary - Number each tweet like "1/" at the start ``` The extracted ideas arrive through the connection from the previous node. Same rule as before: data on the wire, judgment in the prompt.  The rules in that prompt are all negative constraints, and that's deliberate. Models have strong defaults for tweet threads: hook question, emoji bullets, engagement bait ending. Telling the model what to do doesn't override those defaults. Telling it what _not_ to do does. --- ## Step 5 — Add the output node Drag in a **Workflow Output** node and connect the second chat node to it. Set **Output Name** to something like `Tweet thread`. There is no format dropdown. The run surface picks the best view from the result (text, markdown, and so on). The output node is what the person running your workflow sees when it finishes. Everything upstream of it is hidden, which is the point. Your prompts stay yours.  --- ## Step 6 — Test it Hit **Run** in the top bar. Paste in a real blog post: yours, or anything long enough to have actual ideas in it. Watch the nodes as it runs. Each one shows a status: idle, running, then success or error. Click any node after the run to see exactly what went in and what came out. This is the fastest way to debug. If the thread is bad, the problem is almost always visible in the extraction step's output, not the writing step's.  **If the output is weak, tune in this order:** 1. **Extraction is vague** → your source post is thin, or the extraction prompt needs a tighter definition of "strong idea" 2. **Thread is generic** → add more negative constraints to the writing prompt 3. **Tweets are too long** → models are unreliable at counting characters; drop the limit to 240 and it'll land near 270 Iterate until it's good. Builder test runs use your hosted quota or your own key, so you can iterate without publishing first. --- ## Step 7 — Publish it Hit **Publish**. Fill in: - **Title:** what it does, not what it is. "Blog Post to Tweet Thread" beats "Thread Generator." - **Description:** the specific problem it solves, in two sentences - **Output demo images:** upload screenshots or stills of a real result. Buyers trust a visible demo more than a description alone. - **Your margin per run:** start at `$0.50` if you charge. The buyer-facing price is your margin plus estimated compute. You earn from the margin share, not from compute. You can also publish it **Free** while you're getting your first runs in. Free workflows still build your creator page.  --- ## Step 8 — Share the link Your workflow now has a public product page. Anyone with the link can open it, see the inputs, and understand what it does without reading your prompts. Depending on how you priced it, runners may get a free demo, or they may need to sign in and fund the run (wallet / bundle) before a full paid execution. Either way, they are not rewriting your prompt from scratch. Send it to one person who writes and complains about promoting their writing. Watch what they do with it.  --- ## Level up: take a URL instead of pasted text Pasting a whole blog post is friction. Here's the version that takes a link. Change the **Workflow Input** node: Question `Article URL`, Input type `URL`, Description something like `https://yourblog.com/post`. Insert a **Web Scrape** node between the input and the first chat node when you want the article body cleaned into markdown. Use **HTTP Request** only if you specifically need the raw response. Then update the extraction node's prompt to work on fetched content: ```prompt @@label: Prompt The content below is a fetched page. Ignore navigation, headers, footers, sidebars, cookie banners, comments, and related-post links. Extract only the article body, then pull out the 5 to 7 strongest standalone ideas as described above. ``` Expect fragility: sites block scrapers, paywalls return login pages, and JavaScript-rendered blogs can come back thin. Web Scrape fails closed on blocked destinations rather than silently feeding junk into the model. Ship the paste version first, get runs on it, then add the URL path once you know people actually want it. --- ## Common first-workflow mistakes

The workflow in this tutorial passes that bar only barely, because of the extract-then-write split and the negative constraints. Yours should clear it by more. --- ## What to build next The pattern here (take an input, enrich it, transform it, return it) covers most of what's worth building: - Product URL → competitor teardown - Transcript → follow-up email with action items - Job description → tailored cover letter - Company domain → outreach brief Same four nodes. Different prompts. Want this exact workflow without building it by hand? Use the template — same nodes, models, and prompts as this tutorial.

Prefer to rebuild it yourself? Open [Workflow Studio](/builder) and follow the steps above. Built something with this? Send it over. The good ones get featured.