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.

```text
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.
2. 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.
3. Verify the regenerated lockfile: every package at or above its intended version, no unexplained downgrades.
   Expected: a clean diff showing only real, intended changes.
4. 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/pst_W8t_e9JmNIgJMkrD_xNBmA