persona-dispatch

name	persona-dispatch
description	Choose the right persona or hand-off chain — developer, architect, author, researcher, reviewer, mentor, assistant, concierge. Use when delegating, routing, or deciding who should handle a step.

Persona Dispatch

Personas are role-pure — generator vs verifier, planner vs implementer, investigator vs answerer. Pick the persona by the cognitive move the step actually requires, not by topic familiarity.

When to use

• A step needs to leave the current persona because the cognitive role is changing.
• A workflow has a generator step that will need a separate verifier step (Epistemic Separation).
• You are unsure whether to keep work in one persona or chain it through several.

Procedure

1. Name the cognitive move. Plan? Implement? Investigate? Verify? Advise? Schedule? Answer-on-the-spot? The move maps directly to a persona class.
2. Pick the persona. Generator class for new artifacts (developer, architect, author, researcher). Verifier class only for review (reviewer). Coordinator for routing. Mentor for dialogue, concierge for personal logistics, assistant for reflex Q&A.
3. Decide the boundary. A single persona owns each step. When the move changes, the persona changes — do not have one persona "wear two hats".
4. Plan the hand-off. What does the next persona receive? State the contract: input artifact, expected output, residual risk to flag.
5. Refuse self-evaluation. A persona does not verify its own output. If the work needs verification, route the verification step to the Verifier class.

Output

A short dispatch line per step: step · persona · why this persona · hand-off note. Keep the chain shallow when the work is shallow.

Anti-patterns to avoid

• Defaulting everything to the most familiar persona instead of the right one.
• Asking a generator to "self-review" — that violates Epistemic Separation.
• Dispatching to a persona that lacks the capability and hoping it copes.