NotebookLM Skill: Setup, Access Checks, and Research Handoffs

A NotebookLM skill is a reusable procedure that an AI assistant runs to query your NotebookLM sources—so instead of manually opening NotebookLM, entering a question and copying the answer into your work session, the assistant does that step automatically when you invoke the skill. Tools like fenbs store the resulting decisions and follow-up tasks in a shared record, so the research findings do not stay locked inside one session or one person's account.

Note that NotebookLM was renamed Gemini Notebook in July 2026. Verify the current name and feature set on Google's own documentation before setting up an integration, as details change. The principles in this article apply to the product under either name.

What a NotebookLM skill automates

Without a skill, a research workflow looks like this: open NotebookLM, load the right notebook, ask your question, read the answer, copy the relevant finding into your work session, and carry on. That works, but each step is manual and the finding disappears when the session closes.

A skill wraps that sequence into one invocation. When you—or the assistant—calls the skill, it queries NotebookLM with a specified question, retrieves the answer and returns it in the current session. The assistant can then use the finding immediately, without manual copying.

The same pattern applies to other AI research tools. Connecting NotebookLM specifically as a Claude skill is a related setup covered in its own article.

Before you set up the skill: access checks

Before building the skill, verify three things about access:

1. Which notebooks can the skill reach? Skills run with the permissions of the account that set them up. Shared or restricted notebooks may not be accessible. Confirm which notebooks will be in scope.
2. Who else can invoke the skill? If the skill is shared with a team, every person who invokes it queries the same underlying notebooks. Check that the sources are appropriate for everyone with access.
3. What happens to the output? A skill that returns research findings into a session needs those findings to be recorded somewhere if they are going to inform decisions. Plan where the output goes: a task note, a decision record, a shared workspace.

How to write the skill procedure

A skill procedure is a short set of instructions that tells the assistant what to do when the skill is invoked. For a NotebookLM research skill, a minimal procedure looks like:

Skill: Research lookup - NotebookLM
When invoked with a research question:
1. Open the specified notebook in NotebookLM (or Gemini Notebook).
2. Ask the question exactly as provided.
3. Return the key finding in 2-3 sentences.
4. Note the source title and section if available.
5. Flag any conflicting evidence in the notebook.

Keep the procedure specific. A skill that says "look up the research" is harder to invoke consistently than one that specifies which notebook, what format the answer should take and what to do when sources conflict.

Scoping the question well

A skill is only as useful as the question it sends. A vague question—"what does the research say about pricing?"—returns a vague answer. A specific one—"what does source X say about pricing elasticity for SaaS products under $50/month?"—returns something you can act on.

Build question templates into the skill procedure for your most common research needs. A template like "What does [notebook] say about [topic] in the context of [use case]?" is easier to fill in than writing each question from scratch, and it produces more consistent outputs across sessions.

Testing the skill before you rely on it

Run the skill with a question you already know the answer to. Compare the output to what NotebookLM returns when you query it manually with the same question. If the outputs differ significantly, check whether the skill is querying the right notebook and whether the question was passed correctly.

Also test with a question the notebook cannot answer. The skill should return a clear "not found" rather than generating an answer that looks authoritative. A research skill that invents sources is worse than no skill.

Handling research handoffs

The most common problem with AI research tools is that findings live in one session and do not reach the person who acts on them. A lawyer finds a relevant case in NotebookLM, but the colleague drafting the document does not see it. A designer confirms a user preference in research, but the developer who implements the feature never hears about it.

The fix is to record research findings as structured outputs, not just session text. After invoking the skill, add the key finding as a comment on the relevant task, or write the decision it confirmed in Decisions and rules. That way the finding persists beyond the session and the assistant who reads it next can act on it.

For alternatives to NotebookLM for this kind of research workflow, see notebooklm alternatives. For examples of skills in other contexts, see claude skills examples.

How to do this with fenbs

1. Create a free account and add a project for the research area or body of work.
2. Write the NotebookLM skill procedure in fenbs Skills and prompts. Name it clearly: "Research lookup - [topic]."
3. Connect your AI assistant to fenbs from Integrations. When the skill returns a finding, ask the assistant to record any resulting decision in Decisions and rules and add follow-up tasks to the board.
4. At the start of each research session, ask the assistant to read the project context. It sees previous decisions and open tasks, so it can frame its research questions accordingly.
5. Before finishing a session, save progress: which questions were answered, which are still open and what the next step is.