Write the result in one sentence.
Replace an open-ended request such as “research this market” with a bounded deliverable: “Prepare a two-page comparison of three named options using this approved source set, and flag any missing evidence.”
The point is not to make the prompt longer. It is to make the expected output reviewable.
Use a short workflow brief.
- Objective: What result should exist when the work is complete?
- Inputs: Which sources and files are approved for use?
- Boundaries: What must not be accessed, changed, or sent?
- Acceptance criteria: What observable checks define a good result?
- Owner: Who can approve, revise, or stop the work?
- Exceptions: What should happen when information is missing or a check fails?
Break the work at decision points.
Plan around moments when new information changes what should happen next. Gathering approved inputs, creating a draft, checking it, and reviewing it are useful boundaries because each can produce a different next decision.
A task list is not automatically a workflow. The transitions, failure paths, and authority rules matter just as much as the happy path.
Define what “done” does not mean.
Done should not merely mean that the system stopped generating text. It should mean the agreed criteria were checked and the responsible person made the required decision.
Keep unresolved questions visible. A useful result may be a clear explanation of what is missing and why the workflow cannot responsibly proceed yet.