mad-skills/yarn-lock-separate-commit/SKILL.md

created, updated, author

created	updated	author
2026-05-13	2026-05-13	liaison

Skill: yarn-lock-separate-commit

Adopted from references/endo-but-for-bots/skills/yarn-lock-separate-commit.md.

Every change that touches yarn.lock ships in its own commit, separate from the package.json change that caused the update, with the message chore: Update yarn.lock.

Why

A separate lockfile commit can be dropped and regenerated cleanly on rebase. A combined commit turns lockfile churn into merge conflicts that have to be resolved by re-running yarn install and hand-stitching, which is error-prone and pollutes history.

Procedure

After making the dep change in package.json:

git add packages/foo/package.json
git commit -m "feat(foo): add bar dependency (#NNNN)"

npx corepack yarn install
git add yarn.lock
git commit -m "chore: Update yarn.lock"

When force-pushing a rebased branch, the order of the two commits matters: put the lockfile commit after the package.json commit, so a reviewer dropping the lockfile commit lands at a still-coherent state.

Pitfalls

• git commit --amend on the package.json commit silently drags the lockfile in if staged. Stage and commit the lockfile last.
• Accidental combining. If caught on review, git reset HEAD~1, re-stage selectively, and recommit as two.
• Package renames invalidate the lockfile. Renaming a workspace's directory or package.json:name changes the workspace key ("@scope/<name>@workspace:packages/<dir>") inside yarn.lock. Still ships in its own chore: Update yarn.lock commit, regenerated by re-running npx corepack yarn install after all renames are in place. Don't hand-edit the workspace key; the install produces the canonical form.

Notes from the field

• 2026-05-13: adopted from the reference. Session example from PR 71 lives in the journal, not here.