Review-first run
Freelancers can move from client problem, scope, deliverables, timeline, support, assumptions, and pricing context to a proposal outline without treating the first answer as finished. The workflow adds a messy-note example, answer checks, and a follow-up prompt for proposal outline quality, client scope and deliverable boundary.
Turn client problem, scope, deliverables, timeline, support, assumptions, and pricing context into a proposal outline for a client, prospect, or project stakeholder.
- Bring first
- Need proposal with goals, scope, deliverables, timeline, client inputs, assumptions, out-of-scope items, and next step. proposal section outline with scope and assumptions would be weak without the source details, so the evidence has to stay attached. A reviewable answer should keep the original constraint in the open. Freelancers should use the note as the base for a proposal outline. Before freelancers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
- Reject if
- Do not use the answer if it hides unsupported claims about verified account context, buyer language, and deal stage or treats uncertainty as fact.
Ready-to-run path
Freelancers can move from buyer role, suspected problem, deal stage, product fit, and learning to discovery questions without treating the first answer as finished. The workflow adds a messy-note example, answer checks, and a follow-up prompt for discovery questions quality, client goals and scope risk.
Turn buyer role, suspected problem, deal stage, product fit, and learning goal into discovery questions for a client, prospect, or project stakeholder.
- Bring first
- Need questions about audience, offer, current page, support, competitors, timeline, budget, approvals, and red flags. question ladder by buyer signal would be weak without the source details, so the evidence has to stay attached. A reviewable answer should keep the original constraint in the open. Freelancers should use the note as the base for discovery questions. Before freelancers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
- Reject if
- Do not use the answer if it hides unsupported claims about true experience, measurable support, and target role fit or treats uncertainty as fact.
Ready-to-run path
Use this scope of work workflow when the raw material is client goal, deliverables, exclusions, timeline, acceptance criteria, and change rules. It turns that material into a scope of work split into reader-ready copy, open questions and keeps the pasted notes, concrete examples, hard limits, and reviewer in front of the person checking the answer.
Turn client goal, deliverables, exclusions, timeline, acceptance criteria, and change rules into a scope of work for a client, prospect, or project stakeholder.
- Bring first
- Need SOW sections, deliverables, client inputs, timeline, revision policy, exclusions, acceptance criteria, and change request language. scope table with exclusions and acceptance terms needs the source note, output shape, and review owner in the same pass. The prompt run should carry the rough note forward. a scope of work should use the note as its source. Before freelancers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
- Reject if
- Hold the answer if it blurs what is known, what is assumed, and what still needs evidence.
Review-first run
Start with this material: client goals, access needs, kickoff agenda, owners, and communication cadence. Use the client onboarding plan workflow to create a client onboarding plan, keep onboarding checklist with owner and access fields visible, add reject rules, and show a client, prospect, or project stakeholder what to check next.
Turn client goals, access needs, kickoff agenda, owners, and communication cadence into a client onboarding plan for a client, prospect, or project stakeholder.
- Bring first
- Need onboarding checklist, account access, brand assets, audience info, approvals, timeline, and first-week agenda. Phrase shopping fails for client onboarding plan work because the note should become onboarding checklist with owner and access fields. The user's note should stay readable after the answer is organized. This client onboarding plan work run should turn that note into a client onboarding plan. For client onboarding plan work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a sequenced plan with stages, owners, timing, and choice checkpoints.
- Reject if
- Reject the answer if it invents facts, numbers, policy claims, citations, credentials, or examples that were not in the notes.
Ready-to-run path
The project update workflow turns rough notes into a project update around completed work, blocker, choice needed, timeline risk, and owner. It includes a sample run, rerun instruction, and reusable fields for the next pass.
Turn completed work, blockers, choices needed, next steps, and deadline risk into a project update for a client, prospect, or project stakeholder.
- Bring first
- Need update with completed work, current blocker, choice needed, next milestone, timeline impact, and friendly tone. Phrase shopping fails for project update work because the note should become status update with blocker and choice rows. A safer answer should separate source notes from guesses. This project update work run should turn that note into a project update. For project update work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a project update with copy-ready parts, needs-checking parts, and reuse fields.
- Reject if
- Reject the answer if it invents facts, numbers, policy claims, citations, credentials, or examples that were not in the notes.
Ready-to-run path
Bring customer context, problem, approach, evidence, outcome, and permission limits into the case study outline workflow and keep before state, intervention, evidence, outcome, and permission boundary visible from the first run. freelancers can check case study outline quality, before state and intervention before sharing the result.
Turn customer context, problem, approach, evidence, outcome, and permission limits into a case study outline for a client, prospect, or project stakeholder.
- Bring first
- Need case study outline with problem, approach, deliverables, client quote, visual support, limits, and CTA. No fake metrics. Freelancers need more than broad ChatGPT advice here; the answer has to work against the actual note and reviewer. The model output should keep the rough request attached to each choice. a client, prospect, or project stakeholder should still see the note while a case study outline is being built. Write Case Studies works better when the context is in named fields, because each variable can be checked before copying.
- Reject if
- Stop before sharing if it cannot show support, numbers, or authority that the user did not provide.
Review-first run
Use the testimonial request flow to keep relationship context, result prompt, approval path, and easy reply from disappearing in polished wording. The result is a testimonial request, plus checks for the actual notes, usable examples, boundary checks, and reviewer.
Turn client relationship, result achieved, timing, ask, and approval path into a testimonial request for a client, prospect, or project stakeholder.
- Bring first
- Need email ask, 4 guiding questions, short LinkedIn version, permission note, and gentle follow-up after one week. Phrase shopping fails for testimonial request work because the note should become request note with approval and quote boundary. The workbench should turn this note into checkable fields. This testimonial request work run should turn that note into a testimonial request. For testimonial request work, paste the source as bullets, constraints, and audience notes so the model has enough shape for a testimonial request with copy-ready parts, needs-checking parts, and reuse fields.
- Reject if
- Reject the answer if it invents facts, numbers, policy claims, citations, credentials, or examples that were not in the notes.
Ready-to-run path
The pricing prompt set keeps a pricing explanation, cost drivers, value logic, tradeoffs, and scope protection, and the final check tied to the same source note. It is built to reduce polished but unsupported answers.
Turn service scope, value support, cost drivers, alternatives, and boundaries into a pricing explanation for a client, prospect, or project stakeholder.
- Bring first
- Need explanation for price, what is included, why it matters, payment schedule, alternatives, and boundary for extra work. pricing explanation with cost-driver rows needs the source note, output shape, and review owner in the same pass. The answer should protect the real constraint before polish. a pricing explanation should use the note as its source. Before freelancers run this, separate facts, preferences, and limits so the finished answer does not hide assumptions.
- Reject if
- Hold the answer if it blurs what is known, what is assumed, and what still needs evidence.