Effective prompting reduces iteration cycles and gets you closer to your intent on the first pass. This guide covers how to structure your initial prompts, use Plan mode to refine your approach, give actionable feedback, and test thoroughly before publishing.
Get better results from the start
The more context you provide in your initial prompt, the fewer iterations you need. A vague prompt produces a generic workflow that requires multiple rounds of correction. A specific prompt gets closer to what you want on the first pass.
A prompt like this produces a near-complete workflow on the first pass:
“Build a workflow that receives a phishing email via webhook. Extract the sender address, subject line, and any URLs from the body. Enrich each URL with VirusTotal using the vt_integration integration. If any URL scores above 70, create a Torq case with severity High and notify #soc-alerts in Slack.”
This works because it covers the trigger type, the integrations by name, the enrichment logic, a threshold, and the output action. The Builder does not need to ask follow-up questions for any of those.
Prompts that only name the goal without specifying the trigger, integrations, or logic (such as “Build me a phishing workflow”) force the Builder to guess. It will ask follow-up questions, but each round of clarification is one more back-and-forth before you get there.
When writing your initial prompt, try to include:
The trigger type (webhook, scheduled, on-demand, internal event).
Which integrations to use, by name.
The expected input format or data source.
What the workflow should do with the results (create a case, send a notification, generate a report).
Any thresholds, conditions, or branching logic.
The Builder will ask about anything you leave out. Front-loading the detail just gets you to a working draft faster.
Use Plan mode to shape the approach
Before the Builder generates anything, use Plan mode to align on what the workflow should do. This is especially valuable when you are not yet sure about the full scope, or when the use case involves multiple workflows.
In Plan mode, ask the Builder to help you think through the problem:
“What kind of workflows would I need to monitor case assignments and notify my team lead when a case is unassigned for more than five minutes?”
“I want to build a vulnerability triage process using CrowdStrike and CISA KEV data. What steps would that involve?”
“What integrations in my workspace could I use for a daily threat intel digest?”
The Builder responds with a proposed structure. Review it, push back on anything that does not align with your intent, and iterate until the plan looks right. Then switch to Build mode.
Plan mode is also useful for exploring what is possible. Asking “what kind of processes can I build with my current integrations?” yields a contextual answer tailored to your workspace, not a generic list.
Build complex workflows in stages
The front-loading advice above works well for a single, well-scoped workflow. For larger use cases (multiple integrations, branching logic, or long processing chains), build in stages instead: start with the core workflow, verify it works, then add complexity one layer at a time:
Start with the core logic: “Build a workflow with a webhook trigger that extracts URLs from the payload body and enriches each one with VirusTotal.”
Verify, then add conditions: “Now add a condition: if the VirusTotal score is above 70, create a case. Otherwise, log the result and continue.”
Add error handling: “Add error handling for the VirusTotal step. If the API call fails, skip that URL, log the error, and continue with the next one.”
Add notifications: “Send a Slack summary to #soc-alerts after all URLs are processed. Include the total count, how many were flagged, and a link to any cases created.”
Each step produces a testable result, so if something breaks, you know which change caused it. This approach also works when the Builder needs to create multiple workflows for one use case: start with the primary workflow, verify it, then build supporting workflows that connect to it.
Give precise feedback when iterating
When requesting changes, describe what you see, what you want instead, and where the issue is. This gives the Builder enough to make a targeted correction without re-evaluating the entire workflow.
Examples:
“The Slack notification is going to #general. Change it to #soc-alerts, and include the case ID and severity in the message body.”
“The CrowdStrike step is using the wrong integration. Switch it to crowdstrike_integration.”
“The conditional logic only checks for High severity. Add a branch for Medium that sends a Slack message instead of creating a case.”
“The error handling is missing. If the VirusTotal enrichment fails, the workflow should skip that URL and continue processing the rest.”
Feedback like “this is wrong” or “fix the logic” does not give the Builder enough to act on. Name the specific step, the actual behavior, and what you expected instead.
Push for thorough testing
After saving a workflow, test it to verify behavior before publishing. Ask the Builder to verify specific scenarios:
“Test what happens if the webhook payload is missing the sender field.”
“Run the workflow with a URL that returns a VirusTotal score of 0. Verify that no case is created.”
“What happens if the CrowdStrike API returns a rate limit error? Does the error handling catch it?”
“Test with a payload that contains 50 URLs. Does the loop handle all of them?”
Each prompt targets a specific behavior. The Builder executes the workflow and reports the results, providing concrete information to help you decide whether the workflow is ready.
Know when to start a new chat
Your chats are saved, so you can leave and return without losing context. Even so, for complex use cases with many iterations, starting a fresh chat can help the Builder stay accurate.
Example: You started a chat to build a phishing triage workflow. After several iterations, you pivoted to a secondary enrichment path using a different vendor. The Builder keeps referencing decisions from the original design (routing logic you have since removed, a step name that no longer exists) and its suggestions no longer align with the current workflow. Starting a new chat with a prompt that describes the workflow as it stands now gives the Builder a clean, accurate starting point.
A good handoff summary includes:
The workflow ID or name (so the Builder can import it).
What the workflow currently does.
What you want to change or add next.
For example:
“Import workflow <name>. It currently receives a webhook, enriches URLs with VirusTotal, and creates cases for anything that scores above 70. I want to add CISA KEV correlation before the case-creation step.”
This gives the Builder enough context to pick up where you left off without having to re-explain the entire use case.