The scenario
The README names one package manager or test runner while tracked project files suggest another.
Required context: a selected repository matching this scenario, relevant task evidence, and access to its instructions and checks. Use redacted or synthetic data where appropriate.
Adapt the complete prompt
Edits stay in this browser tab. Saving bookmarks the original example; export your edited version to keep it elsewhere.
Why this is a strong example
It resolves conflicting evidence instead of treating familiar setup commands as facts.
A concrete outcome
Determine the correct local startup and test procedure when README instructions disagree with the manifest or lockfile.
The result can be assessed against an observable task rather than prompt length or confidence.
Boundaries and a method
Compare scripts, lockfiles, CI and current imports. Propose the smallest documentation correction; do not replace the tooling to match an old README.
This leaves implementation judgment while constraining the changes that would exceed the task.
Evidence that can disagree
Explain the source of each discrepancy. Run only relevant safe checks if dependencies are already available; otherwise label the procedure unverified.
These checks describe what would make acceptance justified; asking for them does not mean they ran.
A safe way to encounter uncertainty
If the repository contradicts these assumptions, required access is unavailable, or a consequential product decision is missing, explain the conflict and pause the dependent work. Preserve unrelated changes.
Consequential uncertainty stays visible rather than being converted into an invented requirement.