Workflow variants are complete strategies for specific…

When This Fires

• When designing "lite" or "quick" versions of existing workflows
• When using a shortened workflow and feeling guilty about "cutting corners"
• When output quality is inconsistent because the same standards are applied to different workflow variants
• When contexts vary (time-pressure, energy level, stakes) and a single workflow can't serve all of them

Common Failure Mode

The "cutting corners" narrative: using a shorter variant while mentally comparing it to the full version, producing guilt and half-hearted execution. The result is worse than either a committed full version or a committed quick version — you get the time cost of trying to do the full version with the quality of a resentful shortcut.

The Protocol

(1) For any workflow that needs to adapt to different contexts, design named variants: "Full" (optimal conditions, high stakes), "Standard" (normal conditions, moderate stakes), "Rapid" (time-constrained, lower stakes). (2) Each variant gets its own complete description: steps, output standards, and quality criteria calibrated to its context. (3) The "Rapid" variant is not "Full minus steps 3, 5, and 7" — it's a redesigned workflow that achieves its own purpose within its own constraints. (4) When selecting a variant, choose based on context, then commit fully. No guilt, no half-measures, no "I should be doing the full version." (5) Each variant's output should be excellent by its own standards. A quick email update written well is better than a comprehensive report written resentfully.