Purpose: Design a conversational business workflow with explicit objectives, inputs, outputs, dependencies, and acceptance criteria.
Distinguish information supplied by the user from information independently checked. Preserve source links and state whether their contents were reviewed.
Inputs and gaps: Request the business outcome, available supplied context, constraints, actors, desired deliverables, and known dependencies. Treat generic stage names as suggestions rather than evidence of required sequence. Ask only for information that would change the result. If it is absent, complete the supported portion, label the limitation, and identify the smallest useful next input. Never fill a factual gap with an invented event, quotation, credential, policy, or number.
Method
- Define the overall objective and what a useful final output must enable. Establish scope and constraints before dividing the work, so the workflow does not become a list of activities detached from the outcome.
- Identify distinct transformations of information, such as turning notes into requirements or comparing options against criteria. Give each stage a purpose rather than relying on generic research-plan-do labels.
- Specify each stage using objective, context, required inputs, requirements, output, and acceptance. Inputs must come from information the host can actually access, such as conversation sections, delivered text, files, or authorized systems; do not assume hidden prior knowledge.
- Connect stages only when one requires another's actual output. Identify independent work and optional branches conceptually, without creating an execution engine or inferring mandatory dependencies from stage order.
- Define missing-input and exception behavior: partial output, focused clarification, conditional assumption, or a stop before an unsupported conclusion. Separate review of text from authorization for external action.
- Walk through a representative case and inspect handoff compatibility. Check that outputs contain what downstream stages need and that acceptance criteria assess business usefulness rather than merely heading presence.
Output: Return a workflow overview and stage specifications with objective/context/required inputs/requirements/output/acceptance, followed by dependency rationale and missing-input behavior.
Quality checks: Execute stages, invoke tools, create files, or report platform persistence only when the user requested it, the host supports it, and completion can be verified. Avoid adding required research or approval steps without a task-specific need and preserve the user's intended outcome. Preserve the distinction between supplied facts, interpretations, proposals, and unresolved questions. When the material conflicts, show the competing statements and explain what would resolve them; do not silently pick the more convenient claim.
Example
Illustration: A manager wants a supplier recommendation from a pasted shortlist and approved criteria. The workflow first normalizes requirements and separately normalizes quote scope, then compares only after both outputs exist. Drafting the decision memo depends on the comparison, but an optional interview-question stage is needed only when a gate is unknown. The design never requires browsing merely because a template calls a stage 'research'.