Mark shared workflow steps as fixed (deviation breaks it) or customizable (substitution OK) — make the adaptation boundary explicit

Why This Is a Rule

When someone receives a shared workflow, they face a constant question at every step: "Can I do this differently?" Some steps are fixed — the specific order, tool, or method is essential to the workflow's function, and deviating will break something downstream. Other steps are customizable — the author chose a particular tool or method, but any equivalent would work fine. Without explicit marking, the executor must guess which is which, producing two failure modes.

If they guess "fixed" when it's actually customizable, they waste effort conforming to unnecessary specificity (buying a tool they don't need, learning a method they already have an equivalent for). If they guess "customizable" when it's actually fixed, they substitute something that breaks the workflow in a way they don't discover until several steps later. Both failures are the author's fault for not communicating the adaptation boundary.

This is the workflow equivalent of API documentation marking required vs. optional parameters. A well-designed API clearly states which parameters must be provided exactly as specified and which can be varied or omitted. A well-designed shared workflow does the same for its steps.

When This Fires

• When creating a workflow intended for sharing with people who have different tools or preferences
• When someone adapts your shared workflow and breaks it by customizing a fixed step
• When someone follows your workflow rigidly and wastes effort on steps that didn't need to be followed exactly
• Complements Make workflows portable by naming tools with alternatives, not by eliminating specificity — separate essential logic from incidental implementation (tool + alternatives) with the broader marking system for all types of step flexibility

Common Failure Mode

Unmarked workflows that implicitly assume everything is fixed: every step must be followed exactly as written. This makes the workflow rigid, hard to adopt, and fragile — any difference in the executor's context (different tools, different team structure, different preferences) either blocks adoption or produces invisible breakage.

The Protocol

(1) For each step in a shared workflow, classify it as Fixed or Customizable. (2) Fixed steps: mark with a clear indicator (e.g., "[FIXED]" or a lock icon) and explain why deviation breaks the workflow: "This step must use CSV format because step 5's parser expects CSV." (3) Customizable steps: mark with an indicator (e.g., "[FLEX]") and specify the constraint: "Any spreadsheet tool that supports pivot tables will work here" or "This step can be done in any order relative to step 4." (4) When in doubt, mark as fixed — it's safer for the executor to conform unnecessarily than to deviate and break something. (5) As you receive feedback from executors who adapted the workflow, update the markers: steps initially marked fixed that turned out to be customizable can be relaxed, expanding the workflow's portability.