LeadHaste
IntermediateNo variables to fill — paste & go

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.

The prompt
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. 1

    Copy the prompt into Claude, ChatGPT, or any LLM.

  2. 2

    Answer the interview, and pay attention when the output flags undecided points — those are the gaps your builder would have guessed through.

  3. 3

    Send the spec to your builder and ask them to reply with questions before starting; a good spec makes those questions specific.

  4. 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

Roles
Founder / CEORevOpsSales Leader
Company size
Solo founderStartup (1–10)SMB (11–50)
Audience
B2B
Industries
Any industry
Works with
Any LLM
Difficulty
Intermediate

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 →
Prompt FAQ

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