Polish retcon and yarn-lock-separate-commit for this workspace

Prune references to other kriscendobot/garden skills and roles
(fixer, weaver, judge's panel, boatman/ferry, journal entries,
references/endo-but-for-bots) and per-PR session lore. Replace the
garden's created/updated/author frontmatter with name + a
trigger-first description. Keep the two skills cross-linked, since
both now live here, and credit upstream with links pinned to the
source commits.

retcon: tag pre-retcon tip as a numbered step; verify with a single
empty `git diff pre-retcon HEAD`; drop `git -C project`.
yarn-lock-separate-commit: promote the rebase --skip recipe from
field notes to its own section.

Generated-by: Claude Opus 5.5

yarn-lock-separate-commit/SKILL.md

@@ -1,51 +1,69 @@
 ---
-created: 2026-05-13
-updated: 2026-05-17
-author: liaison, gardener
+name: yarn-lock-separate-commit
+description: yarn.lock in its own commit — use when changing Yarn dependencies (package.json deps, workspace renames, yarn install), when organizing or reviewing commits that touch yarn.lock, when a rebase conflicts on yarn.lock, or during a retcon. Every lockfile change ships alone as `chore: Update yarn.lock`, after the package.json commit that caused it.
 ---
 
-# Skill: yarn-lock-separate-commit
+# yarn.lock in a 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`.
+Every change that touches `yarn.lock` ships in its own commit, with the
+message `chore: Update yarn.lock`. It stays separate from the
+`package.json` change that caused it.
 
 ## 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.
+A separate lockfile commit can be dropped on a rebase and cleanly
+regenerated. A combined commit turns lockfile churn into merge
+conflicts, and those get resolved by re-running `yarn install` and
+stitching by hand. That's error-prone and clutters the history.
 
 ## Procedure
 
-After making the dep change in `package.json`:
+After the dependency change in `package.json`:
 
 ```sh
 git add packages/foo/package.json
-git commit -m "feat(foo): add bar dependency (#NNNN)"
+git commit -m "feat(foo): add bar dependency"
 
 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.
+Order matters. Put the lockfile commit **after** the `package.json`
+commit, so dropping the lockfile commit still leaves a coherent state.
+
+## Rebasing past a lockfile conflict
+
+If another PR changed dependencies in the meantime, rebasing onto the
+moved base usually conflicts on `yarn.lock`. Don't hand-merge it. Drop
+the old lockfile commit and regenerate the lockfile:
+
+```sh
+git rebase origin/<base>
+# conflict on yarn.lock
+git rebase --skip                 # drop the old lockfile commit
+# ... any other fixes on top ...
+npx corepack yarn install         # regenerate against the new base
+git add yarn.lock
+git commit -m "chore: Update yarn.lock"
+```
 
 ## 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.
+- **`git commit --amend` on the `package.json` commit** quietly pulls
+  the lockfile in if it's staged. Stage and commit the lockfile last.
+- **Combined by accident:** run `git reset HEAD~1`, restage selectively,
+  and recommit as two commits.
+- **Package renames change the lockfile.** Renaming a workspace's
+  directory or its `package.json` `name` changes the workspace key
+  (`"@scope/<name>@workspace:packages/<dir>"`) in `yarn.lock`. Once all
+  the renames are in, regenerate with `npx corepack yarn install`.
+  Commit the result on its own as usual, and don't hand-edit the key.
 
-## Notes from the field
+## See also
 
-- _2026-05-13_: adopted from the reference. Session example from PR 71 lives in the journal, not here.
-- _2026-05-17_: a PR carrying `chore: Update yarn.lock` typically conflicts on the lockfile when rebased onto a moved base (any other PR that touched dependencies has landed in the interim). The workflow that resolved it cleanly: skip the old lockfile commit during rebase, apply any review-feedback fixes on top, then regenerate the lockfile against the new base as its own commit. Source: PR #238 fixer, `journal/entries/2026/05/17/200805Z-message-fixer-3e9fd0.md`.
-
-  ```sh
-  git rebase origin/<base>
-  # conflict on yarn.lock
-  git rebase --skip                     # drop the old lockfile commit
-  # apply review-feedback fixes on top
-  npx corepack yarn install             # regenerate lockfile against new base
-  git add yarn.lock
-  git commit -m "chore: Update yarn.lock"
-  ```
+- [Retcon](../retcon/SKILL.md) applies this rule to a whole branch's
+  history after the fact.
+- Adapted from
+  [the yarn-lock-separate-commit skill in kriscendobot/garden](https://github.com/kriscendobot/garden/blob/f6fd8db6abe012366aa4c843874c07adae46e7f7/skills/yarn-lock-separate-commit/SKILL.md)
+  (May 2026).