Write a build spec a VA or ops hire can execute without you
Interviews you about a workflow, then writes a delegation-grade build spec: precise field-level flow steps, complete if-then decision rules, edge-case behavior, contractual acceptance tests, secure credential handling, and handover requirements. It eliminates the guess-filling that makes delegated builds technically work while doing the wrong thing.
You are a technical operations writer who has produced build specifications for hundreds of delegated automation projects, and you know why most delegated builds fail: the spec was three Slack messages and a Loom, the builder filled every gap with guesses, and the result technically works while doing the wrong thing. Your specs assume an intelligent builder with zero context and zero telepathy. Interview me about the workflow I want built, then write a complete build specification containing: 1. PURPOSE — two sentences on what this automation does and the business result it serves. 2. TOOLS AND ACCESS — every tool touched, the access level needed, and how credentials are shared securely (named vault or scoped invite — never passwords in chat). 3. THE FLOW — numbered steps in plain language, each with: tool, exact action, data fields (named as they appear in the tools), and what it passes to the next. 4. DECISION RULES — every branch as if-then statements with all cases covered, including the else. No step may require the builder to guess intent. 5. EDGE CASES — the inputs that will eventually happen (empty fields, duplicates, weird characters, API timeouts) and the specified behavior for each. 6. ACCEPTANCE TESTS — 5-8 concrete pass/fail checks I run before approving (for example: 'submitting the test form creates one CRM record with source populated; submitting twice creates no duplicate'). 7. HANDOVER — what the builder documents on completion: a walkthrough recording, where credentials live, and the two likeliest failure points with fixes. 8. MAINTENANCE NOTES — what to check weekly and who to contact when it breaks. Rules: no step may say 'appropriately' or 'as needed' — those words mean I haven't decided yet, and the spec forces the decision now. Acceptance tests are contractual: passing all of them means the build is done and paid. Interview me ONE AT A TIME, waiting for my answer each time: 1. Describe the workflow you want built, end to end. 2. What tools are involved, and does the builder already have access to any? 3. Where should human review or approval happen, if anywhere? 4. What's the weirdest input or edge case you've seen this process encounter? 5. Who is the builder — a VA, a freelancer, an ops hire — and how technical are they? Then write the full spec, flagging any decision I still haven't actually made.
How to use it
- 1
Copy the prompt into Claude, ChatGPT, or any LLM.
- 2
Answer the interview, and pay attention when the output flags undecided points — those are the gaps your builder would have guessed through.
- 3
Send the spec to your builder and ask them to reply with questions before starting; a good spec makes those questions specific.
- 4
Run the acceptance tests yourself before approving — they're the contract, so treat them like one.
Best practices
Never let 'appropriately' or 'as needed' survive into the final spec; every instance is a decision you're deferring onto someone with less context.
Share credentials through a password manager or scoped access invitations, exactly as the spec's access section states.
Keep the spec as the living document after launch — when the workflow changes, the spec changes first.
Reuse the acceptance-test pattern for every future delegation; it converts 'is it done?' arguments into checklists.
Example: what this looks like in practice
A founder wants her VA to build a workflow that catches positive Instantly replies, enriches the contact through Clay, creates a Pipedrive deal, and pings her on Slack. Previous attempt: a Loom and 'you'll figure it out', which produced deals with no source data and duplicates on every re-reply. The interview surfaces her real edge case (prospects replying from a different address than the one emailed) and that approval should gate deal creation above $10K signals. The spec comes out at four pages: nine flow steps with exact Pipedrive field names, an if-then table covering the alternate-address case, credentials via 1Password shared vault, and seven acceptance tests including a double-reply duplicate check. The VA builds it in two days with three questions instead of thirty, and every test passes on the first review call.
Best fit
This prompt is one gear in a bigger machine. We orchestrate 20+ tools into outbound systems our clients own — and guarantee the results.
Apply for a Pilot Spot → →Frequently asked questions
Write the decisions down before delegating the work: a spec with numbered steps, exact field names, if-then rules for every branch, edge-case behavior, and acceptance tests that define done. Most delegation failures aren't skill failures — they're specs that forced the builder to guess your intent, and the guesses compounded.
More automation & workflow design prompts
Build a system prompt for an AI cold email reply agent
Interviews you about your offer, booking flow, and voice, then generates a complete production system prompt for an AI reply agent — classification taxonomy, response rules, escalation conditions, and a strict JSON output contract an n8n or Zapier workflow can parse. You get the artifact teams pay thousands to have written, tuned to how you actually talk.
Turn a manual sales process into an automation blueprint
Converts a fuzzy 'we do this by hand every week' description into a structured blueprint with a detectable trigger, labeled steps, edge cases, human checkpoints, and failure alerts. It forces the design decisions people usually discover mid-build, so what you hand to n8n, Zapier, or an ops hire is assembly work, not archaeology.
Architect a Clay table before you burn the credits
Designs the Clay table before you build it: sources, column order, run conditions, waterfalls, outputs, and a credit estimate. Column ordering and gating are where most teams silently overspend, so the prompt enforces filter-first architecture and makes every paid column defend its run condition — typically cutting credit burn 40-70% versus enrich-everything builds.