Competent stranger test for workflow steps — could someone complete this step with zero clarifying questions? If not, it is not yet atomic
For each workflow step, apply the competent stranger test: if you handed this step to a competent stranger with no additional context, could they complete it without asking a single clarifying question? Any step that fails this test is not yet atomic.
Why This Is a Rule
Workflow steps that seem clear to the author are often opaque to anyone else because the author's tacit knowledge fills gaps that the documentation leaves open. "Process the report" feels like a complete step when you know exactly what "process" means, which tool to use, what the output format should be, and where to put the result. To someone without your context, it's a step-shaped hole requiring multiple clarifying questions before execution can begin.
The competent stranger test operationalizes the gap between explicit documentation and tacit knowledge. A "competent stranger" has domain skills (they can use the tools, they understand the field) but lacks your specific context (they don't know your naming conventions, your folder structure, your preferred output format, your quality criteria). If such a person needs to ask clarifying questions, the step contains implicit knowledge that hasn't been externalized.
This test is essentially a documentation unit test: each step is tested in isolation against a clear pass/fail criterion. The zero-questions threshold is deliberately strict because each question represents an execution-blocking ambiguity. In software engineering, this parallels the principle that a function's interface should be self-documenting — the caller shouldn't need to read the implementation to use it correctly.
When This Fires
- When writing or reviewing workflow documentation and checking for completeness
- When someone follows your documented workflow and gets stuck or does it wrong
- When handing off a process and wanting to ensure zero-context execution
- When converting personal tacit workflows into team-sharable documented procedures
Common Failure Mode
The curse of knowledge: you read your own documentation and it seems perfectly clear because your brain automatically fills in the unstated assumptions. "Upload the file" — where? In what format? Using which tool? Named how? Each unstated assumption is a question the competent stranger would need to ask. The fix is to literally imagine handing the step to someone who has never seen your system before.
The Protocol
(1) For each workflow step, perform the competent stranger simulation: read the step as if you had no context beyond the document itself. (2) Count the questions that arise: "Where?" "Using what?" "In what format?" "Named how?" "What counts as done?" (3) If question count > 0 → the step is not atomic. Rewrite to explicitly answer every question within the step text. (4) Common missing elements: specific tool/location ("in Google Sheets, column B"), output format ("as a PDF named YYYY-MM-report"), completion criteria ("until all rows show green status"), and handoff instruction ("then notify [person] via [channel]"). (5) After rewriting, re-run the test. Repeat until the step survives with zero questions. The goal is documentation so explicit that execution requires zero interpretation.