These are starting structures, not incantations. Replace the bracketed details with facts about your repository. Include the relevant requirement and files, then give the assistant enough freedom to identify missing information. Do not ask it to pretend uncertainty has disappeared.
Explore before editing
Repository exploration prompt
Trace how [entry point] reaches [behavior].
Read the relevant code without changing files.
List the important files and explain their roles.
Separate confirmed facts from open questions.
Stop with a proposed next investigation.Use this when you need a map of unfamiliar code. Check the file references yourself before treating the explanation as the basis for an edit.
Make one bounded change
Implementation prompt
Implement [observable requirement].
Follow the nearby pattern in [file].
Preserve [interface or behavior].
Keep the change limited to the requirement.
Run [relevant check] and report its actual result.
Identify any part you could not verify.Supply a real acceptance check. A constraint like “keep it clean” is less useful than naming the interface or behavior that must remain stable.
Review the reasoning
Review prompt
Review this diff against [requirement].
Prioritize concrete behavioral failures.
For each finding, give a triggering input or state
and reference the affected code.
Distinguish demonstrated issues from questions.
Do not change files.A second reading can expose an assumption; it does not guarantee an independent review. Decide which findings are supported before asking for corrections.
