| true |
permissions |
tools |
network |
safe-outputs |
|
| contents |
issues |
read |
read |
|
|
defaults |
|
Check whether a fresh contributor can still follow the documented setup path without avoidable confusion or hidden blockers.
Run when setup docs, bootstrap scripts, dependency versions, or onboarding paths change enough that the local setup experience may have drifted.
- Read the setup guide, contribution guide, bootstrap scripts, package manager files, and the first commands a new contributor is expected to run.
- Look for real onboarding drift: renamed commands, missing prerequisites, hidden environment variables, platform assumptions, outdated version requirements, or steps that now depend on removed files.
- Focus on the earliest point a fresh clone would fail or become confused. Early blockers matter more than late polish.
- Identify the smallest change that would unblock the next contributor: one missing prerequisite, one renamed command, one missing file reference, or one undocumented branch in the setup path.
- Use safe outputs to leave one concise validation note or remediation comment rather than a scattered list of minor style nits.
- If repository evidence cannot confirm a step, mark it as unverified instead of calling it correct or broken with false confidence.
- Prefer setup reliability over documentation style. The question is whether someone can get working, not whether the prose is elegant.
- A focused setup reliability result that identifies the first-time contributor blockers most likely to matter.
- Clear separation between confirmed drift, likely drift, and unverified assumptions.
- Add the exact bootstrap commands your project treats as the success path.
- If your team supports multiple platforms, state which platform should be validated by default.
- Keep the output short and action-oriented so maintainers can fix setup drift quickly.