Keep shared work reviewable
Coordinate people and agents through small changes, explicit ownership, previews, and a clear integration path.
Picture tomorrow's assignments list: you are fixing the layout while your agent renames the shared badge in the same file. Git saves both edits. It will not stop them from clashing.
You prevent that by agreeing who owns what, and by keeping each change small enough to review.
Why this matters
Combined work fails at the seams — tokens, schemas, lockfiles — not inside isolated files. Without explicit ownership and a combined check, two passing branches make one broken product.
What to understand
Start from the repository's policy: what branch you are on, what is uncommitted, what must pass before merge. A small team may use short-lived branches into main. This project uses dev as a working branch. Neither is a universal rule. Slice by a result someone can judge — one outcome plus a way to check it — and rerun checks on the combined result, not just each branch.
Watch for
- Treating a "locked" note as enforced exclusion — it is a convention.
- Hand-merging resolved hashes or keeping an old lockfile to avoid a diff.
- Splitting one working form across disconnected changes so no review shows it working.
- Missing that a small token or primitive diff alters the entire product.
Strong default
State the task boundary and shared-file ownership before parallel edits. Give tokens, API schemas, and lockfiles one coordinating owner. Update versions through the package manager, regenerate the lockfile once versions are agreed, and review the actual candidate revision — diff, checks, preview, unrelated work intact.
When this doesn't apply
A second checkout does not resolve conflicts — it only lets you compare old and new side by side without stashing. Isolation never replaces agreeing on the shared exchange and bringing changes together.
In practice
Ask your agent: "What branch am I on, what is uncommitted, and what checks must pass before I merge?"
Say you want to compare the old and new assignments list. A worktree — a second checkout of the same repository — lets you do that. Keep separate dev-server ports and check which checkout a preview serves.
Ask your agent: "Update versions through the package manager, not by hand-editing the version lists."
| Change | Useful review evidence |
|---|---|
| Shared token update | Representative pages in supported themes and states. |
| A new user flow | Main path, relevant failure, data and permission behavior. |
| Dependency update | Version-list diff, compatibility notes, build and runtime checks. |
| Content revision | Meaning changed, links kept, rendered reading experience. |
Respect repository-specific restrictions and the user's existing authorization. Do not impose a blanket rule that agents may never update dependencies or refactor within an authorized task.
Verify
Inspect the diff, run the checks, and open a preview of the combined revision. The PR explains the problem, resulting behavior, tradeoffs, and verification — a checked box counts only if the check happened.
Related skills
Use $git to refine the integration policy. Continue with agent collaboration to keep tasks bounded.
Last updated on