notebooklm-skill: When Claude Code Stops Retrieving and Starts Asking
A browser-automated bridge that lets Claude use NotebookLM as a source-grounded research layer, with smart notebook routing, recursive metadata discovery, and zero vector-database plumbing.
- This repo treats NotebookLM as a synthesis engine that Claude Code can ask, not a retrieval stack it has to rebuild.
- Its smartest move is recursive metadata discovery, where the tool queries a notebook to learn how to file the notebook itself.
- Browser automation is the enabling layer, which makes the project powerful enough to use and fragile enough to notice.
- The real trade-off is product leverage over API elegance, and that is exactly why the approach feels interesting.
The easiest way to understand this repo is to flip the usual RAG story. Claude Code is not doing the heavy lifting here. It is acting like a control plane that hands questions to NotebookLM, then uses the answer as if it came from a private, source-grounded expert.
That inversion matters because it sidesteps chunking, embeddings, and the context-window tax. The project does not try to outbuild a retrieval system. It borrows Google’s and focuses on the last mile: asking the right notebook at the right time.
Why this beats rebuilding RAG
NotebookLM is the differentiator. It is not just a place to store documents. It is already a synthesis layer, which means the skill can lean on Gemini’s source-grounded response path instead of reconstructing that logic locally.
| Approach | What you manage | Where the synthesis happens | Main trade-off |
|---|---|---|---|
| Claude reads raw docs | Chunking, prompts, token budget | Inside Claude | Fast to start, weak on scale |
| Local RAG | Embeddings, vector DB, retrieval tuning | Inside your stack | Flexible, but heavy to maintain |
| notebooklm-skill | Notebook selection and browser automation | Inside NotebookLM | Leverages Google, but depends on UI stability |
| NotebookLM MCP server | Protocol integration and persistent sessions | Inside NotebookLM | Broader tool support, more moving parts |
Use this skill to query your Google NotebookLM notebooks directly from Claude Code for source-grounded, citation-backed answers from Gemini.
The agent loop inside the skill
The repo is organized like a small, opinionated control system. SKILL.md tells Claude when to use the scripts. run.py bootstraps a local virtual environment. ask_question.py opens the browser, types the question, waits for the answer to stabilize, and returns the response.
# Simplified data path
user_question -> SKILL.md routing -> scripts/run.py -> scripts/ask_question.py
-> browser session -> NotebookLM query -> Gemini answer -> Claude response
# The point is not parsing documents locally.
# The point is selecting the right notebook and asking it well.This is the part that makes the project feel bigger than a connector script. The notebook is not just added to a list. It is interviewed first, and the answer becomes part of the routing layer.
How it survives Google’s UI
The reliability story is browser choreography, not API elegance. The project leans on persistent authentication, Chrome profile state, and human-like typing and mouse movement to keep NotebookLM usable across sessions.
That makes the system practical, but it also defines the ceiling. The skill depends on selectors, DOM behavior, and a web app that was never designed as a public automation surface. If the UI shifts, the bridge needs repairs.
| Layer | What it does | Why it exists |
|---|---|---|
| Persistent browser profile | Keeps login state alive | Avoids repeating Google auth |
| State file | Stores cookies and session data | Makes the browser context reusable |
| Human-like input | Typing and movement heuristics | Reduces bot-like behavior |
| Selector polling | Waits for NotebookLM output to settle | Prevents scraping partial answers |
What breaks, and why that matters
The fragility is not a bug in the thesis. It is part of it. This repo chooses a working product surface over architectural purity, which is exactly why it is interesting to people building agents today.
Compared with local RAG, the setup burden drops sharply. Compared with a protocol-native integration like an MCP server, the scope narrows. In return, you get a direct path into a knowledge product that already knows how to synthesize documents into answers.
| Question | Raw docs | Local RAG | notebooklm-skill |
|---|---|---|---|
| Need embeddings? | No | Yes | No |
| Need vector DB? | No | Yes | No |
| Need browser automation? | No | Sometimes | Yes |
| Need UI stability? | No | No | Yes |
| Need source-grounded synthesis? | Not by default | Maybe | Yes |
That is the larger bet. Browser automation is becoming a shadow API for tools that expose power through interfaces instead of clean endpoints. This repo is a crisp example of that shift, and it does so with unusually little ceremony.
