Live data from Hacker News

Google Workspace CLI

github.com

221–230 of 316 posts

Re: Google Workspace CLI

#223
This is effectively why people want agents, right? To be able to bypass all the stuff companies "optimize", ie. the ad-filled websites. The inserted extra conversations that now literally get triggered BECAUSE you're chatting to someone else. The ...

In other words: this is the FANGs worst enemy. This is adblock * 1000, as far as consumers are concerned.

Re: Google Workspace CLI

#226
post #220

Earlier quoted context omitted.

We have been using something similar for editing Confluence pages. Download XML, edit, upload. It is very effective, much better than direct edit commands. It’s a great pattern.

I would be very interested in this if you could share? Maintaining a Knowledge Base without a Git workflow is a pain currently.

I'm afraid I can't easily share this, as we have embedded a lot of company-specific information in our setup, particularly for cross-linking between confluence/jira/zendesk and other systems. I can try explain it though, and then Claude Code is great at implementing these simple CLI tools and writing the skills.

We wrote CLIs for Confluence, Jira, and Zendesk, with skills to match. We use a simple OAuth flow for users to login (e.g., they would run jira login). Then confluence/jira/zendesk each have REST APIs to query pages/issues/tickets and submit changes, which is what our CLIs would use. Claude Code was exceptional at finding the documentation for these and implementing them. Only took a couple days to set these up and Claude Code is now remarkably good at loading the skills and using the CLIs. We use the skills to embed a lot of domain-specific information about projects, organisation of pages, conventions, standard workflows, etc.

Being able to embed company-specific links between services has been remarkably useful. For example, we look for specific patterns in pages like AIT-553 or zd124132 and then can provide richer cross-links to Jira or Zendesk that help agents navigate between services. This has made agents really efficient at finding information, and it makes them much more likely to actually read from multiple systems. Before we made changes like this, they would often rabbit-hole only looking at confluence pages, or only looking at jira issues, even when there was a lot of very relevant information in other systems.

My favourite is the confluence integration though, as I like to record a lot of worklog-style information in there that I would previously write down as markdown files. It's nicer to have these in Confluence as then they are accessible no matter what repo I am working in, what region I am working in, or what branch or feature I'm working on. I've been meaning to try to set something similar up for my personal projects using the new Obsidian CLI.

Re: Google Workspace CLI

#227

Earlier quoted context omitted.

I'm still confused, @googleworkspace is not affiliated with Google? Seems like it was made by Google employee: https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-ag...

[flagged]

Most projects under the "google" org will have exactly the same disclaimer about not being official Google products.

Re: Google Workspace CLI

#228
I think we all have been working on our own bespoke CLI tools. MCPs are bloated, insecure token hogs. CLIs are easy to write and you can cut it down to only what you need, saving thousands of tokens per prompt. This is another one I'll add to my repertoire of claude CLIs to replace the MCP.
Post reply on HN