Define workflow inputs as precondition checklists — every piece of information, material, and state needed before step 1 can execute

Why This Is a Rule

Most workflow failures happen before the first step executes — not because the steps are wrong, but because the preconditions weren't met. Missing information ("I need the client's budget before I can draft the proposal"), unavailable materials ("the template hasn't been updated"), and incorrect states ("the staging environment isn't running") all produce the same outcome: you start the workflow, hit a blocker, context-switch to gather the missing input, and lose the momentum and focus you'd built up.

Explicit precondition checklists prevent this by making the start-gate binary: either all preconditions are met (begin) or they're not (gather missing inputs first). This is the software engineering concept of pre-conditions — assertions that must be true before a function executes — applied to human workflows. Just as a function that checks its pre-conditions fails fast and clearly, a workflow with an explicit input checklist fails before you've invested time and attention in the process.

The key word is "complete": partial checklists create false confidence. If the checklist has 5 of 7 actual preconditions, you'll discover the missing 2 mid-workflow — exactly the disruption the checklist was supposed to prevent. Completeness requires enumerating not just the obvious inputs (the data, the document) but also the implicit ones (access permissions, tool availability, collaborator readiness, environmental state).

When This Fires

• When designing any workflow that will be executed more than once
• When a workflow repeatedly stalls at the beginning because something wasn't ready
• When handing off a workflow and wanting to ensure the recipient can start without interruption
• Complements Competent stranger test for workflow steps — could someone complete this step with zero clarifying questions? If not, it is not yet atomic (competent stranger test) by making the preconditions explicit rather than assumed

Common Failure Mode

"Obviously you need X before starting" — but what's obvious to the workflow author is not obvious to the executor, especially future-self after months of context loss. Every "obviously" is an undocumented precondition that will eventually cause a failed start.

The Protocol

(1) For each workflow, create a Start Checklist before the first step. (2) List every precondition in three categories: Information (data, documents, decisions that must be in hand), Materials (tools, templates, access credentials, software), and State (system status, environmental conditions, collaborator availability). (3) Make each item binary-checkable: "Client budget received: Y/N" not "Budget stuff is ready." (4) Before executing the workflow, run through the checklist. If any item is unchecked, resolve it before starting step 1. (5) After each workflow execution, ask: "Did I discover a missing precondition mid-workflow?" If yes, add it to the checklist immediately.