Developer friction

Follow the advertised path to the first useful result with the knowledge and environment of the intended newcomer.

Establish the starting point

Read the entry page and promised outcome before exploring implementation details. Identify the intended audience, starting environment, and definition of first success. Respect stated prerequisites; a skill the guide explicitly requires is not automatically an onboarding defect.

Use the guide's order and record what a newcomer knows at each step. Inspect repository internals to diagnose a blocker, but count information found only there as a gap if the guide depends on it. Avoid silently using cached credentials, preinstalled packages, hidden environment variables, or prior project knowledge to make the path pass.

Walk the path

Use a disposable environment when available. Execute safe, in-scope setup and software checks when practical; inspect before running commands that install globally, consume credits, delete data, flash devices, or actuate hardware. Existing authorization still applies. When a step cannot be executed, record the reason and continue with a clearly labeled source walkthrough.

Capture the entry step, expectation, actual observation, and evidence for each point of friction. Distinguish observed failure, source-confirmed gap, and untested concern. An unavailable device or account is a verification limit, not proof that the guide fails.

Look for gaps that change the developer's ability to proceed: