Skip to content
Code Dev Home

Working agreements / Code Dev Home

Decide where this task belongs.

A clear workspace boundary gives the assistant a useful frame for decisions. Name the repository, the area of the task, and the behavior you intend to change. State restrictions that matter in this project rather than relying on an assumed default.

Mark ownership before making edits

Identify generated files, vendored code, migrations, and shared interfaces that require special handling. Explain which module owns the feature and which nearby areas are out of scope. Keep the boundary tied to the task; an implementation can legitimately touch more than one file while still representing one coherent change.

Define the point where the plan must change

Ask the assistant to surface a missing dependency, incompatible interface, or unexpectedly broad refactor before extending the work. Preserve unrelated local edits. Avoid including secrets or private records in task context when sanitized examples are sufficient. Revisit the scope when new evidence changes what is required, and record the resulting decision.

A project boundary note

Adapt to your project
Repository: The intended working directory.
Task: One observable behavior to change.
Ownership: Modules and instructions that apply.
Special files: Generated or externally maintained areas.
Preserve: Unrelated edits and public behavior.
Replan when: The change requires a wider contract.
Should every task have the same restrictions?

No. Use the project instructions and actual risk of the change. A small content edit and a shared storage migration need different boundaries and verification.