Notebooklm kb

notebooklm knowledge base

NotebookLM answers are grounded in the user's real sources (papers, blogs, videos, docs) with citations. Prefer it over model memory for anything in a registered domain — it hallucinates less on this material than you do.

first run: CLI or auth missing?

This skill needs the notebooklm CLI + auth + registry. If notebooklm is not on PATH (check ~/.local/bin/notebooklm too) or notebooklm auth check fails, tell the user and run:

curl -fsSL https://raw.githubusercontent.com/Triippz/notebooklm-bridge/main/install.sh | bash

Interactive: installs deps, walks auth, bootstraps the registry. On a headless server it prints headless auth options instead — recommended: master token (notebooklm login --master-token --account <email>, self-healing, no browser), or transfer auth from a logged-in machine: run curl -fsSL https://raw.githubusercontent.com/Triippz/notebooklm-bridge/main/scripts/auth-export.sh | bash there, paste result into this machine's terminal. Verify with notebooklm auth check --test.

workflow

1. Read the registry: ~/.config/notebooklm-kb/registry.md. It maps notebook ids to domains.
2. If the current question matches a registered domain, query it:

   notebooklm ask --notebook <NOTEBOOK_ID> "<focused question>"
   

   (notebooklm lives at ~/.local/bin/notebooklm. If auth fails: tell the user to run notebooklm login or notebooklm auth check --test.)
3. Ask focused, single-topic questions. Multiple angles → multiple ask calls. Use --json when you need structured source references.
4. Combine the grounded answer with local ground truth (code, configs in the repo). On conflict between model memory and a cited NotebookLM answer, trust the citation.

mandatory output contract

Every answer that used NotebookLM must include:

• which notebook was queried (name + id)
• the source citations the answer relied on (titles as returned)
• verification link: https://notebooklm.google.com/notebook/<NOTEBOOK_ID>

natural-language requests → actions

user says (any phrasing)	action
"save this to notebooklm / reference later"	pick target notebook from registry (ask if ambiguous); write content to a temp .md; notebooklm source add <file> -n <id>; confirm with link
"create video/audio/report explaining X"	artifact recipe below
"what do my notebooks say about X"	query matching notebooks
"make a notebook for X / repo memory"	creating-notebooks flow below
"stop using / unregister notebook X"	remove its registry row (notebook itself untouched)
"delete notebook X"	notebooklm delete — destructive, confirm explicitly first

registration consent (hard rule)

NEVER add a notebook to the registry without the user explicitly approving that notebook and its topics. Auto-deriving topics (notebooklm summary -n <id> --topics) is fine as a proposal; the add happens only after user says yes. Some notebooks are intentionally private/unregistered — absence from the registry is a choice, not drift. Never "helpfully" register everything notebooklm list returns.

unregistering

Remove the notebook's row from ~/.config/notebooklm-kb/registry.md — agents stop querying it immediately (next session for the injected copy). The notebook and its sources stay in NotebookLM. scripts/registry-sync.sh --prune only removes rows whose notebooks were deleted upstream.

multi-notebook and cross-repo questions

• The registry is user-level (~/.config/notebooklm-kb/registry.md) — same registry in every repo/session.
• Question spans multiple registered domains → query EACH matching notebook, synthesize, cite per notebook (citations grouped under each notebook link).
• Comparing repo code against research: query the notebook for the grounded claim, read local code for current truth, report both with the delta.

creating notebooks (repo memory, specialized domains)

notebooklm create "<name>"                  # returns notebook id
notebooklm source add <file|url|text> -n <id> # PDFs, markdown, URLs, YouTube, raw text

• ALWAYS register immediately after creating: append a registry row, else no agent will ever query it.
• Repo-memory pattern: one notebook per repo. Seed with design docs, ADRs, architecture markdown; append PR/change summaries over time. Registry topics: "<repo> architecture, decisions, change history".

artifacts (studio generation)

NotebookLM can turn notebook content into artifacts — use for explainers on code changes, briefings, onboarding material:

notebooklm generate report "<instructions>" --format briefing-doc -n <id> --wait
notebooklm generate audio "<focus instructions>" -n <id> --wait   # podcast-style explainer
notebooklm generate slide-deck|video|quiz|flashcards|mind-map|infographic "<instructions>" -n <id>
notebooklm download report -n <id>   # fetch finished artifact

Code-change explainer recipe: write a markdown summary of the change (what/why/files) → source add it to the repo's notebook → generate report --format blog-post or generate audio scoped to that source → download and hand the user the file + notebook link.

maintaining the registry

The registry is a plain markdown table — you may edit it directly when the user asks.

• update topics: user says a notebook covers more/different domains → edit that row's "knows about" + "query when" columns in ~/.config/notebooklm-kb/registry.md.
• add notebooks: only when the user asks. Propose topics via notebooklm summary -n <id> --topics, get explicit approval per notebook, then append the row (see registration consent rule).
• deleted notebooks / self-heal: if notebooklm ask fails with "No notebook found", verify with notebooklm list; if gone, remove the row and tell the user.
• bulk sync: scripts/registry-sync.sh (next to this skill's plugin root) reports drift; --prune removes deleted rows.

when NOT to query

• No registered domain matches — answer normally, do not fish.
• Pure code questions answerable from the repo itself.
• The registry file is missing or empty — say so once, continue normally.