research-software-quality

Create a worktree when the change touches executable code, tests, dependencies, CI, skills, or agent instructions, when the checkout has unrelated changes, or when another session may write. Documentation-only edits in a clean single-session checkout may be done in place.

Identify the command that proves the claim, run it after the final change, and read the complete output and exit status. A previous run, partial suite, or clean diff does not prove a different claim, so match each statement to fresh evidence.

TDD is not required for documentation, exploratory analysis, generated files, configuration-only changes, or trivial edits. These changes still need a relevant check, but a focused failing test first is preferred only for clear behavior changes.

Yes. Skills and agent instructions change runtime behavior even though their files are Markdown, so they require an isolated worktree and testing of the changed behavior when practical, not documentation-only treatment.

Do not stack speculative fixes. If three distinct fixes fail, pause and reassess the architecture with the user before trying another approach, treating each failed command as evidence to investigate rather than a reason to stop.

Use an independent reviewer when the user requests one, the change is broad, risky, or hard to reverse, the deliverable supports a publication or consequential decision, or a fresh perspective would materially reduce uncertainty after a complex fix.