Building My Second Brain on OpenClaw (Part 2)
How to Install Skills + Installing gog skill + Setup workflows
Welcome back to another Articles by Victoria, the place where I randomly write things I'm curious about.
In Part 1, I walked through what OpenClaw is, how it works under the hood, and how to get it running on Oracle Cloud's free tier with Telegram connected. If you have not read that yet, I recommend starting there.
This part is about making your assistant actually useful. We are going to install the gog skill and connect it to Gmail, Google Calendar, and Google Drive through Google's OAuth setup. By the end, your OpenClaw assistant will be able to read your emails, check your calendar, and access your Drive, all from a Telegram message.
A Word Before You Install Anything
Skills extend what your assistant can do, and that comes with real responsibility. A skill you install gets access to your workspace and potentially your credentials. High download count on Clawhub (the place where you can find skills for Openclaw) does not mean a skill is trustworthy. Before installing any skill, use openclaw skills info <slug> to read what it does and what permissions it requests. Make that a habit.
Here are the core commands you will use when managing skills:
| Action | CLI Command | Notes |
|---|---|---|
| Search | openclaw skills search <query> |
Browses ClawHub for specific skill names or categories. |
| Install | openclaw skills install <slug> |
Installs a skill directly into your active workspace. |
| Info | openclaw skills info <slug> |
Displays details, permissions, and metadata before installation. |
| List | openclaw skills list |
Shows all currently installed and active skills. |
| Update | openclaw skills update --all |
Syncs and updates all locally installed skills to their latest versions. |
| Direct Setup | npx clawhub install <slug> |
To directly install the skill. |
Step 1: Install the gog Skill
There are three ways to install gog (Google Workspace CLI for Gmail, Calendar, Drive, Contacts, Sheets, and Docs) depending on your preference.
Method 1: Install via ClawHub CLI
npx clawhub install gog
Or if ClawHub is already installed on your Openclaw:
clawhub install gog
Your terminal will confirm when the skill is installed.
Method 2: Install via OpenClaw CLI
openclaw skills install https://clawhub.ai/steipete/gog
Method 3: Install via OpenClaw Dashboard
First, open an SSH tunnel to your server:
ssh -i ~/.ssh/oracle-cloud.key -L 18789:127.0.0.1:18789 ubuntu@<instance_public_ip_here>
Then start the dashboard:
openclaw dashboard
You can browse installed and built-in skills from there:
To install via the Chat feature, first run:
openclaw config set tools.sessions.visibility all
Then in the Chat interface, send:
Run a one-time subagent task to install the gog skill from ClawHub
Wait a minute or two and the assistant will confirm when it is done.
The screenshot below shows me installing a different skill using dashboard method. I used Method 1 for gog itself.
Step 2: Set Up Google Cloud Console
For gog to access your Google services, you need to create OAuth credentials through Google Cloud Console. This is how you authorize OpenClaw to act on your behalf without handing over your password. Also, I recommend creating a new Google Account for this so in the worst case scenario, OpenClaw will not be able to access your primary account's data.
Side Note
The new Google account I created did get banned after a day I created it and tested Openclaw on it. Probably it detected that it's a bot account.
I just appealed and explained that I'm using this account for personal use. The next day, appeal was approved and all is good.
Back to business, go to console.cloud.google.com and create a new project.
Once your project is created, go to APIs & Services, then Enabled APIs & Services.
Search for each API you want OpenClaw to access and enable it.
For a full second brain setup, I enabled:
Gmail API
Google Calendar API
Google Drive API
Google Docs API
Google Sheets API
Configure the OAuth Consent Screen
Once your APIs are enabled, go to APIs & Services and click OAuth Consent Screen.
Click Get Started. Fill in an app name and your email address. Set the audience to External, add your contact email, agree to the terms, and click Create.
After that, go to Audience and add yourself as a test user under Add Users.
Create OAuth Credentials
Go to Credentials, click Create Credentials, then OAuth client ID.
Select Desktop app as the application type, give it a name, and download the JSON file. It will be named something like client_secret_xxxx.json. Keep this file safe, it contains your OAuth client credentials.
Step 3: Register Credentials with OpenClaw
Now you need to install gogcli on your Oracle Cloud server and link your credentials to it.
Install Homebrew
sudo apt update && sudo apt install build-essential curl file git -y
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
Add Homebrew to your PATH:
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> ~/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"
Verify:
brew --version
Install gogcli
brew install gogcli
Verify:
gog --version
Link Your Credentials
Transfer your downloaded JSON file to the server, then run:
gog auth credentials path/to/your/client_secret.json
Then start the auth flow:
gog auth add your-email@gmail.com --manual
A URL will appear in your terminal. Open it in your local browser and complete the Google login. When the "Google hasn't verified this app" warning appears, click Advanced, then Go to OpenClaw (unsafe). Review the permissions list carefully before approving.
Copy the full http://127.0.0... URL from your browser address bar and paste it back into your terminal. You will then see:
Enter passphrase to unlock "/home/ubuntu/.config/gogcli/keyring":
This means the OAuth flow completed successfully. gogcli uses a local keyring to encrypt and store your access tokens so you do not have to log in every time. You are being asked to create a password that protects that storage.
Optional: Disable the Keyring
If you would rather skip the keyring passphrase, you can use the no-keyring mode. Add this to your ~/.openclaw/.env file:
GOG_NO_KEYRING=1
Then re-authenticate:
export GOG_NO_KEYRING=1
gog auth add your-email@gmail.com --manual
No passphrase will be requested this time. Restart OpenClaw to apply:
openclaw gateway restart
What My Setup Actually Looks Like
Once you have gog authenticated, the real question is: what do you actually do with it? Let me walk through how I structured my own setup, including the security decisions I made and the workflows I have running today.
Using a Dedicated Bot Account
As mentioned earlier, the first thing I did before connecting anything was create a separate Gmail account specifically for the bot: bot@gmail.com. I did not connect my personal Gmail directly to OpenClaw.
The reason is straightforward. Your OpenClaw instance lives on a cloud server. Even with good security practices, you are still extending trust to a piece of software running remotely. Connecting your main personal Gmail would mean the assistant has access to every email you have ever sent or received, your full contacts list, and everything in your Drive.
A dedicated bot account lets you be precise about what you expose. You share only the calendars, inboxes, and documents that actually need automation. Everything else stays untouched. It is the same principle as creating a service account for an API integration: minimal access, clearly scoped, easy to revoke.
Connecting Four Calendars
I have four Google Calendars that matter to my work, and I share them with limited permissions with the bot account:
The bot account's own calendar (bot@gmail.com) where the assistant can full access to write/delete/edit my events
My personal calendar (victoria@gmail.com), shared as writer access so the assistant can see, edit and create events on my behalf, cannot delete
The ragTech calendar (rt@gmail.com), just read access to view our podcast planning and scheduling
Women Developers SG (wds@gmail.com), read-only because I only need visibility into community events, not the ability to modify them
The access levels matter. Read-only for calendars where I am an external collaborator. Writer access only for calendars I own or co-manage. Giving the assistant unnecessary write access to a shared organizational calendar is a risk I do not need to take.
To fetch events across all of them in a single query:
GOG_KEYRING_PASSWORD=** gog calendar events --account=bot@gmail.com --all --json \
--from 2026-04-29T00:00:00+08:00 \
--to 2026-04-29T23:59:59+08:00
The --all flag fetches across every calendar the account has access to. The assistant consolidates the results and gives me a clean summary of the day.
I also set up a cron job that runs every morning at 7 AM Singapore time and posts that day's events to my Telegram Productivity topic. I never have to ask. It is just there when I open Telegram in the morning.
For reminders, I have another cron job that checks the calendar daily and creates 15-minute-before reminder jobs for every event that has a specific start time. All-day events and public holidays are excluded. These reminders also land in the Productivity topic, so my assistant is effectively acting as my EA.
With calendar access, I can also easily add events via my OpenClaw agent:
Logging to Google Sheets
One of my favourite workflows is using OpenClaw to log data to a Google Sheet I call my Life Trackers. It has four tabs: mood, workout, expenses, and health.
For expenses, I just mention them naturally in conversation. If I say something like "lunch $23", the assistant picks that up, categorises it as Food, and appends a row to the Expenses tab with the date, amount, description, and predicted category. The command under the hood looks like this:
GOG_KEYRING_PASSWORD=** GOG_ACCOUNT=bot@gmail.com \
gog sheets append 'SHEET_ID' 'Expenses!A:E' \
'["2026-04-29", "23", "lunch", "DBS yuu card", "Food"]'
For workouts, there is a 9 PM daily prompt that asks whether I exercised. If yes, the assistant asks for the type and logs it.
Everything will be logged to my Sheets.
For mood tracking, a 10 PM cron job runs a sentiment analysis on my conversations throughout the day and logs a mood score from 1 to 10 with notes. I never have to open a spreadsheet.
The key thing that makes this work is that the bot account has edit access to the sheet. I shared it to bot@gmail.com with editor permissions, and OpenClaw writes to it via the Sheets API through gog. It is only allowed to edit, not create or delete.
Collaboration Email Evaluator
For email, I set up a Gmail filter on the bot account that labels Collaboration types of incoming enquiries automatically. Collaboration enquiries for the ragTech podcast get labelled and automatically forwards to the bot account. OpenClaw cannot access ragTech's account directly.
Every morning at 8 AM, a cron job reads new emails under that label and evaluates them, whether or not this is a good collaboration opportunity. Of course, I have given my agent the criteria to score and the definition of what a good collab opportunity is. If you are curious what that evaluation looks like in practice, I will cover the full scoring framework in Part 3.
After deciding whether to ACCEPT or REJECT the opportunity, my agent drafts a reply and saves it to the bot account's Gmail drafts. I review and then send it myself via ragTech's account, nothing goes out without my approval.
This is the pattern I recommend for any email automation: the assistant reads and drafts, you send manually. Giving an AI assistant permission to send emails autonomously is not something I am ready to trust it with.
A Summary of the Security Guardrails
Looking back at everything, here are the principles that shaped how I set this up:
Use a dedicated bot account. Keep your personal Google account out of the picture. Share only what the assistant needs and nothing more.
Scope access levels carefully. Read-only for external shared calendars. Writer access only where you actually need the assistant to create or modify things.
Never auto-send. For anything that goes outside your own system, whether emails, messages, or external API calls, keep a human review step in the loop. Drafts are fine. Autonomous sending is not.
Audit your OAuth scopes. Go back to your Google Cloud Console periodically and check what scopes are actually in use. If you enabled the Sheets API six months ago and never used it, revoke it. The smaller the OAuth surface, the less there is to exploit.
Conclusion
With gog connected and a few workflows running, OpenClaw starts to feel less like a chatbot and more like an assistant that actually knows your life. It sees the same four calendars I do, logs to the same sheets, reads the same emails. The key to making it work well was being deliberate about access: dedicated account, scoped permissions, human review before anything leaves the system.
Stay tuned for Part 3, where I will be setting up more automations and scheduled tasks to make the assistant proactively useful without me having to ask.
Thanks for reading! I am curious to know your own personal thoughts and experiences on this topic! Feel free to connect, send me an email (my inbox is always open) or let me know in the comments! Cheers!
Part 1: https://lo-victoria.com/building-my-second-brain-on-openclaw-part-1
