Files
max-sixty__worktrunk/gemini-extension.json
T
Maximilian Roos d7e33efc6c refactor(plugin): relocate Gemini extension to repo root (#2807)
Follow-up from a full review of the plugin implementation.

**The finding:** Gemini hard-probes `${extensionPath}/{hooks,skills}/`
at the extension root with no manifest path indirection, and `gemini
extensions install owner/repo` reads `gemini-extension.json` only at the
clone root. The `plugins/gemini/` sibling dir fought that — it needed a
`skills` symlink and a byte-identical bundled `wt.sh` purely to survive
`gemini extensions install`'s `fs.cp`, and github-URL install was broken
entirely (manifest invisible under a subdir). One install-fragile
artifact (`wt.sh`) was bundled to solve this; the other (`skills`) was
left a symlink that the guard test actively pinned — so the extension
shipped no skills to real users.

**The fix:** treat Gemini's manifest as the loader-mandated root pointer
it is — the third tool pointer alongside Claude's
(`.claude-plugin/marketplace.json`) and Codex's
(`.agents/plugins/marketplace.json`). With the manifest at the repo
root, `${extensionPath}` is the repo root, so `${extensionPath}/skills/`
resolves to the real single-sourced repo-root `skills/` and the hooks
call the canonical `${extensionPath}/plugins/worktrunk/hooks/wt.sh` by
its real path. This is net deletion: the symlink, the duplicated
`wt.sh`, and its drift guard all go away, and native `gemini extensions
install owner/repo` now works.

Verified with `gemini extensions validate .` against gemini-cli 0.42. A
true end-to-end `gemini extensions install` was not exercised — it
blocks on an interactive trust prompt — so the native-install claim
rests on documented Gemini behaviour plus `validate`, not a live
install.

Also hardens `test_plugin_layout_is_consolidated` (two other review
findings):

- Every repo-root `skills/` subdir must be listed in the Claude
`plugin.json` `skills` array. Claude has no skill auto-discovery
(confirmed against the official plugin reference), so an unlisted skill
is silently invisible to Claude while Codex/Gemini pick it up — this
turns that latent drift into a build failure.
- All four manifest descriptions (Claude ×2, Codex, Gemini) must share
the canonical product opening sentence. Byte-identical across all four
is schema-impossible (Codex omits the activity clause, Gemini says
"extension"), but the shared stem is a meaningful cross-tool drift
guard.

`CLAUDE.md` and `plugins/worktrunk/CLAUDE.md` updated: the repo root now
carries one loader-mandated pointer per tool (three, not two); tree
diagram, path-resolution rules, and the `wt-switch-create`
shared-`skills/` tradeoff all extended to Gemini.

Full pre-merge gate green locally: 3745 tests, 0 skipped; all lints; no
snapshot churn.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-19 10:09:18 -07:00

6 lines
362 B
JSON

{
"name": "worktrunk",
"version": "0.1.0",
"description": "Worktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows. This extension provides configuration guidance (LLM commit messages, project hooks, worktree paths) and automatic activity tracking (🤖/💬 indicators in `wt list` showing active Gemini CLI sessions)."
}