Is your feature request related to a problem? Please describe.
--agent/-a on scaffold create already accepts a remote Git spec (org/repo/path@ref) that layers a third-party add-on's manifest and starter files over the adk base template (scaffold/utils/remote_template.py's parse_agent_spec). This is documented generically in references/flags.md ("or remote Git URL"), but the google-agents-cli-scaffold skill's "adk is the only template" framing gives no indication the mechanism exists or how it'd be used for a real integration. A coding agent following the skill today would never discover or suggest it, even though it works correctly.
I ship one of these myself (a Keel resilience add-on for ADK agents: MisterTK/keel/packaging/agents-cli-template), and only found the CLI still supported this cleanly by reading the source, not the skill.
Describe the solution you'd like
I'd tried opening a PR with the exact doc change, but pull requests appear to be disabled on this repo, so posting the proposed diff here instead in case it's useful to apply directly.
In skills/google-agents-cli-scaffold/SKILL.md, right after the existing "adk is the only template" blockquote:
### Layering a Vendor/Community Add-on
`--agent`/`-a` also accepts a remote Git spec (`org/repo/path@ref`) that layers a
vendor or community add-on's manifest and starter files over the `adk` base
template — a separate mechanism from the architecture choice above, and the
way a third-party library ships opinionated scaffolding (extra dependencies,
starter config) without agents-cli needing to know about it in advance.
Example: `keelrun` (zero-code retry/timeout/breaker/cache policy for ADK
agents) ships one:
\`\`\`bash
agents-cli scaffold create my-agent -a MisterTK/keel/packaging/agents-cli-template
\`\`\`
See `references/flags.md`'s `--agent` row for the full spec syntax.
And in skills/google-agents-cli-scaffold/references/flags.md, the --agent row's description gains one clause: ... or remote Git URL (org/repo/path@ref— also used to layer a vendor/community add-on's manifest + starter files over a base template, e.g.MisterTK/keel/packaging/agents-cli-template).
Describe alternatives you've considered
Leaving it undocumented — but that means the mechanism stays effectively invisible to anyone (human or coding agent) relying on the skill rather than reading the CLI's own source.
Is your feature request related to a problem? Please describe.
--agent/-aonscaffold createalready accepts a remote Git spec (org/repo/path@ref) that layers a third-party add-on's manifest and starter files over theadkbase template (scaffold/utils/remote_template.py'sparse_agent_spec). This is documented generically inreferences/flags.md("or remote Git URL"), but thegoogle-agents-cli-scaffoldskill's "adk is the only template" framing gives no indication the mechanism exists or how it'd be used for a real integration. A coding agent following the skill today would never discover or suggest it, even though it works correctly.I ship one of these myself (a Keel resilience add-on for ADK agents:
MisterTK/keel/packaging/agents-cli-template), and only found the CLI still supported this cleanly by reading the source, not the skill.Describe the solution you'd like
I'd tried opening a PR with the exact doc change, but pull requests appear to be disabled on this repo, so posting the proposed diff here instead in case it's useful to apply directly.
In
skills/google-agents-cli-scaffold/SKILL.md, right after the existing "adkis the only template" blockquote:And in
skills/google-agents-cli-scaffold/references/flags.md, the--agentrow's description gains one clause:... or remote Git URL (org/repo/path@ref— also used to layer a vendor/community add-on's manifest + starter files over a base template, e.g.MisterTK/keel/packaging/agents-cli-template).Describe alternatives you've considered
Leaving it undocumented — but that means the mechanism stays effectively invisible to anyone (human or coding agent) relying on the skill rather than reading the CLI's own source.