Draw the boundary before expanding it.
A narrow task can still cross a wide system boundary. A renamed field may affect storage, public responses, and clients. Give the assistant a working scope, then ask it to identify dependencies that make the scope incomplete before it starts modifying them.
Protect existing work
Inspect the working tree first. Identify edits already present, generated files, and local configuration. Name the modules that are relevant to the task and the interfaces that consumers rely on. Do not treat a clean-looking diff as proof that user changes were preserved.
Make expansion a decision
If the implementation needs a schema migration, dependency upgrade, or public API change, describe why and what it affects. A neighboring refactor may be sensible but still deserve its own task. Review difficulty usually grows faster than the number of changed lines.
Checkpoint
- Existing work accounted for
- Public contracts listed
- Scope expansion triggers defined
Read-only transmission
Work on [module] to achieve [outcome]. Preserve existing edits and [public behavior]. Identify generated files before changing anything. Report any need for a migration, new dependency, or unrelated module change before expanding the implementation.
Use the final diff to check the boundary again. Every changed file should have a clear role in the requested outcome.
Next: Provider routing