Laojin ChuhaiAI · GO GLOBAL
Back to list
AI WorkflowsPublished Jul 21, 2026·8 min read

I Built My AI a “Skill Factory”: From One Google CLI to a Fully Automated Pipeline

It started with a simple question — does Google have an official CLI? It ended as a pipeline that turns hard-won experience into reusable agent skills and auto-publishes them after a human gate. Any team can copy it.


It started with a very ordinary question

This week I asked my AI a simple question: "Does Google have an official CLI that agents can manage and integrate with?"

It does — gws (the Google Workspace CLI), released in March 2026. One command line operates Gmail, Calendar, Drive, Sheets and the rest of the suite, and it is designed for AI agents from day one: structured JSON output, 40+ bundled agent skills, and a command surface generated dynamically from Google's own Discovery Service.

But the tool itself is not the story. What happened next is: from install to reusable skill to automated public release, the whole pipeline ran with just a few instructions from me. This article is about that pipeline — and a playbook any team can copy: turn scars into skills, and turn skill publishing into an assembly line.

Step one: turn scars into assets

Setting up gws was not smooth. Three traps, each worth recording:

  1. You can no longer create OAuth clients from the command line. Halfway through, gws auth setup tells you Google removed programmatic client creation — the Cloud Console is mandatory. The new Google Auth Platform UI is full of forms and chip inputs (you must press Enter after typing an email, or validation silently fails).
  2. A client secret is shown in full only once, at creation. Since 2025, Google masks secrets forever afterwards (****-xxxx). My first two clients lost their secrets; on the third I captured the creation response via network interception and extracted it.
  3. Testing mode requires test users. Until the consent screen is published, only accounts listed under Test users can authorize. Miss this and login fails with a generic "Access blocked" that tells you nothing.

Every one of these traps will catch the next person too. So we wrote them into the skill's references/setup-guide.md: eight steps from zero to a working OAuth login, traps flagged. What blocks 90% of newcomers now takes five minutes.

That is the first principle: experience only becomes an asset when it is written as steps someone else — or another AI — can execute. What lives only in your memory is just an anecdote.

Step two: the skill factory (skill-forge)

One distilled skill is a start. What I really wanted was a pipeline that recovers experience from *every* AI tool I use:

Say "extract this into a skill" in any AI tool → auto-extract + generalize (strip accounts, project IDs, local paths) → secret scan (11 rules: tokens, private keys, emails, home paths) → publish to the private skill repo (365Skill-private) → ask me once: go public? → on approval → whitelist merge → public repo syncs automatically (GitHub Actions, no second PR) → website skill card + announcement article

The pipeline is itself a skill, called skill-forge. Via the repo's install.sh it now lives in my Claude Code, Codex and Kimi — symlinks to one source, so one edit updates all three clients.

Two design details carry its soul:

  • The secret scan genuinely works. While writing the pipeline docs, the scanner caught my own local machine paths left in a reference file. Running it before every publish beats any human review.
  • The public gate. Private is the default; going public requires explicit approval. Distill boldly, publish cautiously — that gate is not bureaucracy, it is what makes a team comfortable distilling at all.

Field test: a digest skill end-to-end in 20 minutes

Talk is cheap. We rehearsed with a weekly mail+calendar digest that had already run for real for a week:

  • Extract: pulled the workflow from run logs into a SKILL.md, a digest template, and 10 positive + 10 negative bilingual trigger cases.
  • Private publish: after the PR merged, gws-weekly-digest appeared in all three AI clients' skill lists.
  • Go public: I approved at the gate, the whitelist PR merged, and the public repo automatically received a chore: sync public mirror commit — no second PR, no manual copy-paste.

Then the website's skill page went from three cards to six and Vercel deployed it. The very path that led you to this article ran on that pipeline.

Why bother

After a year of heavy AI-tool use, one thing becomes clear: the moat is not the model — it is how much reusable working method you have stockpiled.

Models rotate every few months and prompt tricks expire, but battle-born methods — the three OAuth traps, a five-step dev workflow, draft-first release safety — only compound. The problem is they usually die inside one conversation. As skills, they become assets your team (and every future AI tool) can call.

One more point: skills are portable. SKILL.md is an open directory format understood by Claude Code, Codex and Kimi alike. What you distill in tool A today still works in tool B tomorrow. In an era of fast model turnover, storing your working methods in a neutral format is the cheapest hedge there is.

Links

  • 365Skill public repo (Apache-2.0, stars welcome): https://github.com/laojin1900/365Skill
  • gws-workspace (operate the Google suite via CLI + from-zero setup guide): https://github.com/laojin1900/365Skill/tree/main/skills/gws-workspace
  • gws-weekly-digest (weekly mail+calendar briefing workflow): https://github.com/laojin1900/365Skill/tree/main/skills/gws-weekly-digest

Install in one line: clone the repo and run ./install.sh gws-workspace — the script detects Claude Code, Codex and Kimi on your machine and links the skill in.