Make workflows portable by naming tools with alternatives, not by eliminating specificity — separate essential logic from incidental implementation

Why This Is a Rule

The naive approach to making workflows shareable is removing tool-specific references: "Use a spreadsheet tool" instead of "Use Google Sheets." But this eliminates actionability. Someone following the workflow now has to figure out which spreadsheet tool to use, how to set it up, and whether their choice will support the required operations. The vague instruction created a decision point that wasn't there before.

The better approach is naming the specific tool plus alternatives: "Use Google Sheets (or Excel, or Airtable — any tool that supports pivot tables and shared editing)." This gives the executor a concrete default (Google Sheets), a clear understanding of why that tool was chosen (pivot tables + shared editing), and the criteria for selecting an alternative. The essential logic (the workflow needs pivot tables and shared editing) is separated from the incidental implementation (the author happened to use Google Sheets).

This parallels the software engineering distinction between interfaces and implementations. The workflow's essential logic is the interface — what capabilities each step requires. The specific tools are implementations — one way to satisfy those capabilities. By specifying both the implementation and the interface, you make the workflow immediately actionable (use this tool) and adaptable (or any tool that does these things).

When This Fires

• When documenting workflows that others will use with different tool stacks
• When your own tools change and you need to adapt existing workflows
• When vague workflow instructions produce confusion about which tools to use
• Complements Handoff workflows need finer granularity than personal ones — calibrate the competent stranger to the least experienced actual executor (handoff granularity) with the specific technique for handling tool references

Common Failure Mode

Over-abstraction: "Process the data using an appropriate tool." What tool? What counts as appropriate? The person following this instruction has no starting point and no criteria for selection. The workflow author removed specificity in pursuit of generality and achieved neither — the instruction is too vague to execute and too generic to guide tool selection.

The Protocol

(1) For each tool-specific step in your workflow, write three elements: Tool (the specific tool you use), Capability (what the tool does in this step — the essential function), and Alternatives (other tools that provide the same capability). (2) Format: "Use [Tool] ([Capability]). Alternatives: [Alt1], [Alt2] — any tool that [Capability description]." (3) The capability description is the interface — it tells the reader what to look for in an alternative. (4) Test: could someone substitute their preferred tool and still complete the step? If yes, the capability description is adequate. If no, you've missed a tool-specific requirement that needs to be made explicit. (5) Update alternatives when you discover new tools or when existing ones change capabilities.