| name | workflow-intake |
| description | Classify a request before acting — intent, expected artifact, ambiguity, risk, persona class. Use when starting any new request and deciding whether to clarify, route, answer directly, or run a workflow. |
Workflow Intake
The first move on any request is not to act — it is to classify. A wrong classification ten seconds in is cheaper than a wrong implementation ten minutes in.
When to use
- A new task or message arrives and you have not yet decided what to do with it.
- The request is ambiguous, broad, or compound and a single direct action would over-commit.
- You are choosing between answering, clarifying, routing, or running a workflow.
Procedure
- Name the intent. What does the user actually want — an answer, an artifact, a decision, a hand-off, or a clarification? State it in one short sentence.
- Identify the expected artifact. Words, plan, review, report, schedule entry, nothing? The artifact shape constrains every later move.
- Score ambiguity. Are key parameters missing — target, scope, deadline, format? If yes, surfacing them now beats guessing.
- Score risk. Reversible or destructive? Local or shared? Touches data, infra, money, or other people? Higher risk → stricter verification later.
- Pick the persona class. Generator, Verifier, Coordinator, Guide, Logistics. Map the intent to the cognitive role best suited to it.
Output
A 4–6 line intake note: intent · artifact · ambiguity · risk · persona class · next move (clarify / route / answer / workflow). Then act on the next move.
Anti-patterns to avoid
- Diving straight into execution when the intent is unclear.
- Treating ambiguity as risk-free and "deciding for the user" without naming the assumption.
- Asking five clarifying questions when one would do — ask the one that most reduces uncertainty.
