agent resolved a yarn.lock conflict by picking "ours" for everything and silently downgraded three packages

TL;DR: Redo the merge properly: take the merged package.json and regenerate yarn.lock from it, then verify no versions went backwards. Resolving a lockfile conflict with "ours" keeps your file byte-identical but silently drops the other side's upgrades. Never resolve a lockfile with ours/theirs; always re-resolve.

agent resolved a yarn.lock conflict by picking "ours" for everything and silently downgraded three packages

1. Diff the current yarn.lock against the pre-merge state and list every version that went down.

Expected: the silent downgrades are named explicitly, with before and after versions.

1. Redo the conflict: check out the merged package.json, then run a fresh install to regenerate the lockfile.

Expected: the lockfile reflects both sides' intended versions, not just one side's.

1. Verify the regenerated lockfile: every package at or above its intended version, no unexplained downgrades.

Expected: a clean diff showing only real, intended changes.

1. Add a CI check comparing lockfile versions before and after merge, failing on unexplained downgrades.

Expected: the next bad resolution gets caught automatically instead of shipping silently.

Use this when

• A yarn.lock conflict was resolved by picking "ours" (or "theirs") for everything
• Lockfile versions moved backwards after a merge
• Upgrades from one side of a merge went missing with no trace
• "Silently downgraded" packages after a conflict resolution

Not for this skill when

• The downgrades were intentional and reviewed
• The conflict is in package.json rather than the lockfile
• The lockfile is package-lock.json or pnpm-lock.yaml (same principle, different regen command)

Variant phrasings

• yarn.lock resolved with ours, packages downgraded
• lockfile conflict resolved to the wrong side
• silent downgrade after a merge
• yarn install needed after a conflict

Why it happens

"Ours" feels safe because it keeps a known-good file, but a lockfile encodes the other branch's upgrade decisions too. Keeping yours discards theirs without a trace, and nothing in the merge output flags the downgrade. The merge succeeded; the dependency set quietly regressed.

Edge cases

• If the bad merge already shipped, cut a follow-up PR that re-applies the dropped upgrades rather than rewriting history.
• The regen for the merged manifest can resolve differently from both sides; review the full diff, not just the conflicted hunks.
• In a monorepo, make sure the regen covers all workspaces so a sibling package does not keep the stale resolution.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW8te9JmNIgJMkrD_xNBmA