01 / START HERE
A useful way to approach it.
'Create a launch kit' can mean a logo, a website, social graphics, or all three. A scope draft removes that ambiguity by naming the actual deliverables, what each includes, and how it will be accepted. Tasks describe activity; deliverables describe the outputs a client expects to receive.
Use o1 to improve the wording of a scope you supply, keeping commercial commitments for your normal agreement process. The assistant can identify gaps, but it cannot decide what your client approved. The fictional launch-kit example below illustrates observable checks rather than a binding agreement or completed project.
02 / THE PROCESS
Go from question to next step.
- 01
Name the deliverables precisely
Replace broad labels with concrete outputs. Specify a document, set of files, page, or other result and the intended user. Distinguish a design draft from implemented behavior. 'Design a form' and 'deliver a form that reaches the agreed destination' require different work and should not share an ambiguous acceptance rule.
- 02
Define included and excluded work
List the components, versions, formats, and review rounds included in each output. Name related work that is outside the draft scope. Exclusions should clarify the boundary without becoming a list of hypothetical problems. Mark unresolved requests separately so they cannot be mistaken for either agreed inclusions or confirmed exclusions.
- 03
Write observable acceptance criteria
State what the reviewer should inspect and what a passing result looks like. Replace 'looks professional' with checks such as approved copy present, specified files supplied, links functioning, or a defined interaction completing successfully. Ask whether two reviewers could apply the criterion consistently without guessing what you intended.
- 04
Identify supplied inputs and constraints
Record who provides copy, assets, access, and approval, plus any required dates or formats. State what happens to the draft plan when an input is missing: pause the dependent task, clarify the requirement, or agree a revised schedule. Do not present that draft process as already accepted by the client.
- 05
Review scope changes explicitly
Define a simple way to document a requested change and its effect on deliverables, effort, and timing. Keep the original scope visible when reviewing a revision. A chat-generated wording change does not automatically amend an agreement. Confirm the final scope and change process with the people authorized to approve the project.
03 / YOUR STARTING POINT
A prompt you can make your own.
Replace the bracketed fields. Add only information you have permission to share. This is a reusable text prompt; it does not run a task from this page.
Review this project scope: {{draft_scope}} for {{audience_and_outcome}}. Produce a deliverables table with included work, exclusions, supplied inputs, file or format requirements, and observable acceptance criteria. Flag ambiguous terms and unresolved decisions. Distinguish a draft design from a working implementation. Suggest a plain-language process for reviewing requested changes, without inventing approved fees, timelines, or contract terms. Finish with the questions both parties should answer before agreeing this scope.04 / SEE THE SHAPE OF IT
Illustrative launch-kit scope
Fictional project and authored criteria; these terms are examples and have not been agreed with a client.
| Deliverable | Included boundary | Acceptance check |
|---|---|---|
| Launch brief | Audience, message, and offer summary | Client confirms the factual statements |
| Three social graphics | One format and approved copy | Three named files match the agreed size |
| Landing-page draft | One page; sample form behavior | Sections and sample behavior can be reviewed |
| Delivery notes | File list and unresolved setup items | Real submission destination is not claimed connected |
Concrete boundaries let the reviewer identify what was delivered and what still needs separate agreement or implementation.
05 / KEEP YOUR JUDGMENT
What to watch before you use it.
Using subjective completion language
Words such as 'polished' cannot carry the entire acceptance process. Add observable content, format, and behavior checks.
Leaving assumptions outside the scope
Inputs and exclusions affect delivery. Keep them beside the relevant output instead of buried in an earlier conversation.
Treating revisions as unlimited
Describe the review process you propose and confirm it explicitly. Do not let an undefined promise create expectations neither party reviewed.
06 / THE FINAL PASS
A little review goes a long way.
Your checks stay on this page. They do not approve or run a task.
07 / GOOD QUESTIONS
Before you begin.
What is the difference between a task and a deliverable?
A task is an activity such as interviewing a stakeholder. A deliverable is an output such as an approved audience brief. Connect tasks to outputs, but define acceptance around the output the reviewer will receive.
Can an AI scope draft replace an agreement?
Use it as drafting assistance. The actual agreement depends on the terms your parties review and approve through their normal process. Do not describe authored sample terms, prices, or approval language as already accepted.
What if I cannot define a criterion yet?
Name the missing decision and who should resolve it. You can propose a criterion for discussion, but keep it provisional. An honest unresolved item is easier to manage than a confident definition nobody has agreed to.