The problem

An AI coding session can begin without the decisions and conventions that made the previous session useful. Repeating all that context is tedious, and an answer that sounds confident may not follow the project’s standards.

NotebookLM Memory is a Claude Code plugin organized around two kinds of context: a personal notebook for decisions and session notes, and a standards notebook for engineering references. It packages setup, consultation and wrap-up commands around that workflow.

The workflow

  1. Prepare the references. Build or reuse a standards notebook from a configurable source list.
  2. Consult before making changes. Ask the notebook about the conventions relevant to the task.
  3. Build and inspect. Use the answer as supporting context for code, tests and review.
  4. Preserve useful decisions. Save a session summary so the next session can recover the reasoning.

A repeatable setup, with visible results

The Python builder looks up a notebook by name, lists its existing sources, and skips source URLs already present. New additions receive bounded timeouts. The script then polls ingestion status and reports ready, failed and still-pending sources separately.

That structure is valuable because an integration can partially succeed. A notebook existing is different from every intended source being ready to answer a question.

# From the installed plugin directory
python scripts/build_sdlc_notebook.py   --name "SDLC Standards Brain"   --sources scripts/sdlc-sources.txt

# Ask a specific engineering question
notebooklm ask "How should I test this change?"   -n <your-notebook-id>

AI helps with context. Engineering still owns the answer.

The notebook can retrieve supporting material, but a retrieved answer is not an approval or a test result. The workflow still needs review of the relevant source, an explicit task boundary, and validation of the resulting code.

The repository uses the community notebooklm-py CLI and requires its authenticated session. It is a personal integration rather than an official Google or Anthropic product. Service changes, stale references and partial ingestion are practical constraints to handle.

What I would improve next

I would add an integration fixture for changed CLI response shapes, surface pending ingestion as a distinct outcome, and track the age of reference material. Session summaries should record the reason for a decision and its open questions, not only a list of completed steps.

Inspect the orchestration.

The notebook builder is a compact example of tool orchestration: resolve state, skip existing work, bound retries and report what happened.

Read the Python builder ↗

Based on the public repository’s README and builder script, reviewed at commit 6efa07e. This page describes the project design and source behavior, without claiming a measured productivity improvement.