Four doc additions that document new CC behavior the rest of the codebase already relies on (matrix entries already shipped in v7.84.0). No functional code changes. Closes 4 cc-adoption issues filed by the cron pipeline.
| Issue | Feature | CC | Category |
|---|---|---|---|
| #1639 | enterworktree_branches_from_local_head | 2.1.128 | breaking |
| #1641 | stale_installed_plugins_path_fix | 2.1.128 | breaking |
| #1644 | ctrl_r_history_global_default | 2.1.129 | breaking |
| (no GH issue, gap_score=5) | auto_mode_classifier_error_hint | 2.1.128 | new_field |
| Path | Change |
|---|---|
| src/skills/chain-patterns/references/worktree-agent-pattern.md | New "Branch base (CC 2.1.128+)" section — documents that EnterWorktree branches from local HEAD |
| src/skills/doctor/references/remediation-guide.md | Two new troubleshooting entries: stale plugin paths, auto-mode classifier hints |
| src/skills/setup/references/keybindings.md | New "CC built-in keys worth knowing" section — Ctrl+R global default, Ctrl+S to scope |
All four features are upstream behavior changes that we already gate on via the floor (v7.84.0 raised it to 2.1.132). The matrix entries in cc-version-matrix.ts were added by PR #1623 and the doctor skill already surfaces version-pinned features. What was missing was the human-facing remediation/usage notes that let a maintainer or contributor understand the new behavior when they're reading skill references — not searching the matrix.
## Hooks That Fire … ## Limitations - Worktree agents are slightly slower - Each worktree is a full copy - Merge conflicts possible if agents edit same files - Don't use for read-only agents
## Hooks That Fire … ## Branch base (CC 2.1.128+) EnterWorktree branches from local HEAD, not origin/<default-branch>. - Unpushed commits preserved - No need to push first - We floor at 2.1.132 — done. ## Limitations …unchanged…
npm run build regenerates plugins/ with the doc updates mirrorednpm run test:skills — frontmatter + structure unchangednpm run typecheck — no source changedNext groups (B–E) handle MCP hygiene, security-adjacent fixes, config behavior, and new distribution surfaces. See the per-group rationale in the chained roadmap.