Summary
Please consider refactoring the generated Google Workspace CLI skills from many separate top-level skills into a smaller number of canonical skills that use references/ markdown files for the detailed sub-guides.
Concretely, instead of installing dozens of independent skills such as gws-gmail-send, gws-gmail-read, gws-calendar-insert, gws-sheets-read, etc., ship something closer to:
google-workspace/
SKILL.md
references/
gmail.md
gmail-send.md
gmail-read.md
calendar.md
calendar-insert.md
drive.md
sheets.md
docs.md
chat.md
admin.md
workflows.md
The top-level SKILL.md would act as the routing layer: explain when to use the skill, summarize available capability areas, and point agents to the relevant reference file(s) for task-specific details.
Motivation
Agent skill overhead is a real cost. Many agent runtimes expose the installed skill index to the model on every turn, even when the full skill body is not loaded. A repo that contributes dozens of top-level skills can meaningfully increase prompt size and skill-selection noise for every downstream agent session.
At the moment, this repo still appears to expose many top-level skill directories. From the GitHub contents API, I currently see approximately:
- 44
gws-* skill directories
- 41
recipe-* skill directories
- 10
persona-* skill directories
- 95 total directories under
skills/
That makes the CLI very capable, but it is costly for agents that already have many other domain skills installed.
This is especially painful because the gws-* skills are highly related and often cross-reference each other. For an agent, the problem is not only token count; it is also routing ambiguity. Similar top-level skills like gws-gmail, gws-gmail-send, gws-gmail-read, gws-gmail-reply, and gws-gmail-reply-all compete in skill selection even though they are really chapters of the same Workspace operating manual.
Prior art / related issue
This is related to #82, which was closed as completed, but the current repo layout still seems to include dozens of top-level generated skills. If there has already been a newer consolidation path, it would be useful to document it clearly for downstream agent frameworks and skill installers.
Proposed direction
A possible structure:
- Keep one canonical
google-workspace or gws skill as the main entry point.
- Move detailed service/action documentation into reference files under that skill:
references/gmail.md
references/gmail-send.md
references/calendar.md
references/drive.md
references/sheets.md
- etc.
- Keep the root
SKILL.md short and index-like:
- prerequisites/auth
- global CLI conventions
- service routing table
- pointers to the relevant reference files
- Optionally keep a few truly distinct top-level skills only where they represent a different persona/workflow, not every individual command.
- Provide a migration path or compatibility alias for users who installed the older granular skills.
Why this helps
- Lower prompt/token overhead for agents
- Less skill-selection ambiguity
- Easier maintenance: shared auth/conventions live in one place
- Better fit for emerging skill patterns where
SKILL.md is a concise router and references/ holds detailed docs
- Less risk of stale or conflicting instructions across dozens of near-duplicate skills
Acceptance criteria suggestion
- The default installation path exposes a small number of top-level skills for Google Workspace.
- Detailed generated operation docs are accessible as linked reference files from the canonical skill.
- The canonical
SKILL.md clearly tells agents which reference file to load for each service/task.
- Existing granular skill users have a documented migration path.
Summary
Please consider refactoring the generated Google Workspace CLI skills from many separate top-level skills into a smaller number of canonical skills that use
references/markdown files for the detailed sub-guides.Concretely, instead of installing dozens of independent skills such as
gws-gmail-send,gws-gmail-read,gws-calendar-insert,gws-sheets-read, etc., ship something closer to:The top-level
SKILL.mdwould act as the routing layer: explain when to use the skill, summarize available capability areas, and point agents to the relevant reference file(s) for task-specific details.Motivation
Agent skill overhead is a real cost. Many agent runtimes expose the installed skill index to the model on every turn, even when the full skill body is not loaded. A repo that contributes dozens of top-level skills can meaningfully increase prompt size and skill-selection noise for every downstream agent session.
At the moment, this repo still appears to expose many top-level skill directories. From the GitHub contents API, I currently see approximately:
gws-*skill directoriesrecipe-*skill directoriespersona-*skill directoriesskills/That makes the CLI very capable, but it is costly for agents that already have many other domain skills installed.
This is especially painful because the
gws-*skills are highly related and often cross-reference each other. For an agent, the problem is not only token count; it is also routing ambiguity. Similar top-level skills likegws-gmail,gws-gmail-send,gws-gmail-read,gws-gmail-reply, andgws-gmail-reply-allcompete in skill selection even though they are really chapters of the same Workspace operating manual.Prior art / related issue
This is related to #82, which was closed as completed, but the current repo layout still seems to include dozens of top-level generated skills. If there has already been a newer consolidation path, it would be useful to document it clearly for downstream agent frameworks and skill installers.
Proposed direction
A possible structure:
google-workspaceorgwsskill as the main entry point.references/gmail.mdreferences/gmail-send.mdreferences/calendar.mdreferences/drive.mdreferences/sheets.mdSKILL.mdshort and index-like:Why this helps
SKILL.mdis a concise router andreferences/holds detailed docsAcceptance criteria suggestion
SKILL.mdclearly tells agents which reference file to load for each service/task.