Handoff workflows need finer granularity than personal ones — calibrate the competent stranger to the least experienced actual executor

Why This Is a Rule

Documentation written for yourself operates with your full tacit knowledge as backstop — abbreviations, shortcuts, and implicit steps that your current self fills in automatically. Documentation written for handoff must externalize all of that tacit knowledge because the recipient doesn't have it. Your "future self" is often closer to a stranger than you expect: six months from now, you won't remember why step 3 requires that specific flag, which folder the output goes in, or why the order matters.

The calibration target is the least experienced actual executor — not the most experienced person who might run this, but the least experienced. If a workflow will be executed by a team ranging from senior engineers to new hires, the documentation must work for the new hire. This isn't dumbing down; it's removing ambiguity. The senior engineer loses nothing from explicit documentation (they'll scan past what they already know), but the new hire is blocked by every implicit assumption.

This is the same principle behind defensive programming: code defensively for the least-skilled maintainer, not the most skilled. The marginal cost of extra clarity is near zero, while the marginal cost of missing context is an interruption, a mistake, or a blocked handoff.

When This Fires

• When documenting a workflow you'll hand off to someone else
• When creating documentation for your future self (anything you won't execute for 30+ days)
• When a handoff recipient keeps asking questions that "should" be answered by the docs
• 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 adjusting who the "competent stranger" is

Common Failure Mode

Writing handoff documentation at the same granularity as personal notes: "Run the deploy script." You know which script, where it lives, what flags it needs, what to check after. The recipient knows none of this. Every unstated element is a support request that interrupts you or a mistake that requires cleanup.

The Protocol

(1) Identify who will actually execute this workflow — the specific people or roles, not a theoretical audience. (2) Calibrate to the least experienced among them: what do they know? What don't they know? (3) Apply Competent stranger test for workflow steps — could someone complete this step with zero clarifying questions? If not, it is not yet atomic's competent stranger test using this specific calibration: could the least experienced executor complete each step with zero clarifying questions? (4) Include elements you'd normally skip for yourself: exact file paths, specific tool names, output formats, success/failure indicators, and "what to do if X goes wrong." (5) Test if possible: have the actual least-experienced executor follow the documentation cold. Every question they ask is a documentation gap to fill.