Add gemini-extension.json manifest with correct array-format settings, symlink skills/last30days/SKILL.md to root SKILL.md for Gemini skill discovery, add Gemini install paths to bash for-loop in both main and open variant, and add Gemini CLI install instructions to README. Incorporates the good parts of PR #53 (manifest, paths, README) while avoiding duplicate SKILL.md, tool name scattering, and allowed-tools pollution that would have created maintenance issues. Closes #45 Co-Authored-By: Alex Ferrari <alex@thealexferrari.com> Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
8.6 KiB
title, type, status, date
| title | type | status | date |
|---|---|---|---|
| review: PR #53 - Gemini CLI Support | review | active | 2026-03-08 |
Review: PR #53 - Gemini CLI Support (alexferrari88)
Verdict: MODIFY - Accept concept, reject implementation approach
PR #53 by @alexferrari88 adds Gemini CLI extension support. The intent is good and closes issue #45, but the implementation has structural problems that would create the exact maintenance nightmare we just fixed in v2.9.5.
PR Summary
| File | Changes | Assessment |
|---|---|---|
gemini-extension.json |
+67 new file | Accept with fixes |
skills/last30days/SKILL.md |
+693 new file (full copy) | Reject - duplicate SKILL.md |
SKILL.md |
+9/-6 (tool name scattering) | Reject - wrong approach |
variants/open/SKILL.md |
+4/-1 | Partially accept (path resolution yes, tool names no) |
README.md |
+6 install instructions | Accept |
Critical Issues
1. Duplicated SKILL.md (BLOCKER)
The PR creates skills/last30days/SKILL.md as a full 693-line copy of the root SKILL.md. This is the exact problem we just spent hours debugging - PR merges on March 7 regressed v2.9.4's save-section removal because branches had stale copies. A second SKILL.md guarantees this happens again.
The Codex compatibility work (see docs/plans/2026-02-14-feat-codex-skill-compatibility-plan.md) explicitly chose one SKILL.md for all platforms to avoid this. Gemini CLI should follow the same pattern.
Fix: Delete skills/last30days/SKILL.md. Gemini CLI discovers skills from the extension's skills/ directory, but we can either:
- (a) Symlink:
skills/last30days/SKILL.md -> ../../SKILL.md - (b) Use the root SKILL.md directly and configure
contextFileNamein gemini-extension.json to point to it - (c) Have
skills/last30days/SKILL.mdbe a thin wrapper that says "See root SKILL.md" (least ideal)
2. Based on v2.9.1, not v2.9.5 (BLOCKER)
The PR's copy of SKILL.md is based on v2.9.1 and includes:
- The "Save Research to Documents" section (removed in v2.9.4, re-removed in v2.9.5)
- Old agent mode line referencing deleted section
- Missing
--save-dir=~/Documents/Last30Daysflag - Old version number
Fix: Rebase on current main (v2.9.5).
3. "Or" tool name scattering (REJECT)
The PR adds WebSearch or google_web_search(...) and similar patterns throughout SKILL.md. This is the wrong approach because:
- LLMs already translate intent to tools. When Gemini reads "do a WebSearch for X", it knows to use
google_web_search. When Claude reads it, it usesWebSearch. The model handles this mapping natively. - Clutters the prompt. SKILL.md is a 640-line prompt. Adding "or alternative_name" to every tool reference makes it harder for the model to parse.
- Maintenance burden. Every new platform means adding more "or" alternatives.
Fix: Remove all "or" alternatives. Keep Claude Code tool names in the SKILL.md body (they work as intent descriptions). If Gemini needs explicit tool mapping, that belongs in GEMINI.md (Gemini CLI's context file), not scattered through the skill instructions.
4. allowed-tools pollution (RISKY)
Adding run_shell_command, read_file, write_file, ask_user, google_web_search to allowed-tools:
allowed-tools: Bash, Read, Write, AskUserQuestion, WebSearch, run_shell_command, read_file, write_file, ask_user, google_web_search
Risk: If Claude Code's parser is strict and rejects unknown tool names, this breaks the skill for all Claude Code users. If it silently ignores unknown names, it's harmless but noisy.
Finding: Gemini CLI only recognizes name and description in SKILL.md frontmatter. It ignores allowed-tools entirely. So adding Gemini tool names to allowed-tools provides zero benefit to Gemini users while potentially breaking Claude Code users.
Fix: Remove Gemini tool names from allowed-tools. They serve no purpose on either platform.
What to Accept
1. gemini-extension.json (with fixes)
The manifest file is the right approach. However:
- Verify settings format. The PR uses object-key format (
"SCRAPECREATORS_API_KEY": { ... }). Gemini CLI docs show array format ([{ "name": "...", ... }]). Need to confirm which is correct for the current Gemini CLI version. The researcher found array format in the docs. - Update version from
2.9.1to2.9.5 - Consider adding
contextFileNameto point to root SKILL.md instead of duplicating
2. Path resolution additions
Adding these to the bash for loop is correct and low-risk:
"${GEMINI_EXTENSION_DIR:-}" \
"$HOME/.gemini/extensions/last30days-skill" \
"$HOME/.gemini/extensions/last30days" \
This should be in both SKILL.md and variants/open/SKILL.md.
3. README.md install section
Clean and appropriate. Adding Gemini CLI install command before Claude Code section.
Proposed Changes to Request from Contributor
Must-fix (before merge)
- Delete
skills/last30days/SKILL.md- no duplicate. Either symlink or usecontextFileNamein manifest. - Rebase on main (v2.9.5) - the PR is based on stale code.
- Remove all "or" tool name alternatives from SKILL.md and variants/open/SKILL.md body text.
- Remove Gemini tool names from
allowed-toolsin all SKILL.md files. - Verify
gemini-extension.jsonsettings format against current Gemini CLI docs (array vs object).
Nice-to-have
- Add a
GEMINI.mdcontext file (optional) - can include a short note like "When this skill references 'WebSearch', usegoogle_web_search. When it references 'Bash', userun_shell_command." This is the clean way to handle tool name translation. - Update sync.sh to optionally deploy to
~/.gemini/extensions/last30days/(debatable - Gemini users may prefergemini extensions installinstead). - Add
.gemini/to the path check in sync.sh import verification.
Testing Plan
Before merging, verify:
gemini extensions installworks from the repo (orgemini extensions link .for local dev)- Skill activates in Gemini CLI and the model can find
scripts/last30days.py GEMINI_EXTENSION_DIRenv var resolves correctly in the bash for-loop- Claude Code still works with no regressions (run
/last30days test topic --mockor similar) allowed-toolswith only Claude Code tool names doesn't break Gemini CLI skill loading
Comment Template for PR
Thanks for the contribution! Gemini CLI support is great to have, and the `gemini-extension.json` manifest and path resolution additions are solid.
A few things need changing before we can merge:
**Must-fix:**
1. **Remove `skills/last30days/SKILL.md`** - We maintain one SKILL.md to avoid sync drift (we literally just fixed a regression from this exact problem yesterday). Either symlink it or use `contextFileName` in the manifest to point to the root SKILL.md.
2. **Rebase on `main`** - The PR is based on v2.9.1 but we're now at v2.9.5. The "Save Research to Documents" section in your copy was removed, `--save-dir` was added to the bash command, and the version was bumped.
3. **Remove "or" tool name alternatives** from SKILL.md body (e.g., `WebSearch or google_web_search`). LLMs handle tool name translation natively - Gemini knows to use `google_web_search` when the skill says "search the web". Scattering alternatives clutters the prompt.
4. **Remove Gemini tool names from `allowed-tools`** - Gemini CLI ignores `allowed-tools` (it only reads `name` and `description` from SKILL.md frontmatter), so these provide no benefit. And they risk breaking Claude Code if its parser rejects unknown tool names.
5. **Verify `gemini-extension.json` settings format** - The Gemini CLI docs I found show settings as an array (`[{ "name": "...", ... }]`), not object keys (`{ "KEY": { ... } }`). Can you confirm which format your Gemini CLI version expects?
**Optional but recommended:**
6. Consider adding a `GEMINI.md` context file with a short tool-name translation note (e.g., "When this skill says 'WebSearch', use `google_web_search`"). This is the clean way to bridge tool names.
Happy to help work through any of these! The core approach (manifest + path resolution) is right.
Sources
- PR #53: https://github.com/mvanhorn/last30days-skill/pull/53
- Issue #45: https://github.com/mvanhorn/last30days-skill/issues/45
- Gemini CLI extension docs: https://geminicli.com/docs/extensions/writing-extensions/
- Gemini CLI extension reference: https://geminicli.com/docs/extensions/reference/
- Gemini CLI skills docs: https://geminicli.com/docs/cli/creating-skills/
- Codex compatibility plan:
docs/plans/2026-02-14-feat-codex-skill-compatibility-plan.md - v2.9.5 regression fix: commit
8f7fb5a(today)