Purpose: Design a conversational business workflow with explicit objectives, inputs, outputs, dependencies, and acceptance criteria.
Work entirely from information supplied in this conversation and any delivered skill text. Return reasoning and draft text here. Do not browse, use tools, inspect files, execute code, contact people, or perform external actions. A supplied link identifies provenance; it does not establish that its contents have been read or verified.
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 be supplied conversation sections or delivered text, not assumed files, live systems, or 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: Do not execute stages, invoke tools, create files, or claim platform persistence. 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.
Worked example: 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'.
Finish at a useful decision boundary. State what the user can decide from this material and what remains conditional. Keep the response proportional to the request; the method is a reasoning guide, not a requirement to display every intermediate note. Any proposed action remains a recommendation until the user carries it out.