Skip to content

okf-notebooklm

Adapt an OKF matter for NotebookLM (Google's AI notebook). Use when the user mentions NotebookLM, Google NotebookLM, AI notebook, uploading/adapting/preparing an OKF matter for AI question-answering, or building sources/briefs for AI review of a matter. Builds a staging folder of upload-ready sources from the OKF tree: a Matter Brief (metadata + chronology + index + source map), per-counterparty/phase bundles, key documents kept individual, extracted-data CSVs, per-thread email bundles, and an upload guide with starter questions and Audio Overview prompts. Never modifies the matter itself.

Source: .opencode/skills/okf-notebooklm/SKILL.md — site rebuilt 2026-09-05.

OKF → NotebookLM

Turn an OKF matter folder into a staging folder you can drag into NotebookLM. NotebookLM doesn't read folder structure — it ingests flat files and answers with citations — so the skill flattens the OKF tree while keeping its semantics: OKF naming, the Chronology as the knowledge spine, and matter.yaml/README metadata as a map source.

When to run

  • The user wants an OKF matter in NotebookLM (Pro: 300 sources per notebook; one notebook per matter).
  • The user asks to "prepare/adapt/upload a matter for NotebookLM", "build sources", "make an AI brief".
  • A matter was updated (new OCR, new filings) and the notebook's sources need rebuilding.

Tooling

tools/okf_nblm_build.py does all the work. It is read-only on the matter; everything lands in a staging folder (default: sibling NotebookLM_<ref>\ next to the matter). tools/okf_nblm_daily.py is the once-a-day sweeper — discovers every matter under the OKF root and keeps each NotebookLM_<ref> in sync.

python <skill>/tools/okf_nblm_build.py <matter_root> [--dry-run] [--out <dir>] [--keep]
       [--config <json>] [--max-sources N] [--no-brief] [--no-guide] [--no-email]
       [--no-validate] [--drivesync <dir>]
python <skill>/tools/okf_nblm_build.py <matter_root> --check   # drift vs last build; exit 1 = rebuild needed
python <skill>/tools/okf_nblm_build.py <matter_root> --validate # integrity of the staged folder only
python <skill>/tools/okf_nblm_build.py <matter_root> --watch [--poll 30] [--quiet 60]   # auto-rebuild on change
python <skill>/tools/okf_nblm_daily.py [--okf-root <dir>] [--dry-run] [--max-sources N] [--no-email] [--drivesync <dir>] [--log <file>] [--matter <ref>]
  • --dry-run — plan only: source list, counts, warnings. ALWAYS run it first.
  • --config <json> — per-folder mode overrides: {"singles": ["02_Pleadings/03_Adjustments_Amendments"], "bundles": [...]} (key documents stay individual by default — see KEY_SINGLE_FOLDERS).
  • --keep — don't clear the output folder before rebuilding.
  • --max-sources N — cap (default 300, NotebookLM Pro). When the plan exceeds it, sources are merged by least impact instead of failing: sibling bundles in the same folder merge first, then key singles are folded into their phase bundle, then cross-folder merges (with a warning). Every merge is logged as a warning and in manifest.json.
  • --no-email — skip 00_Admin/Email_Archive bundles.
  • --check — compares the matter against the last build's fingerprint (stored in manifest.json); exit 0 = clean, 1 = dirty. Use it before sessions or in other skills' workflows.
  • --validate — integrity gate on the staging folder only (no rebuild): every manifest source present and non-empty, no unexpected files, per-source words within the 500k cap. Runs automatically at the end of every build (--no-validate disables that).
  • --drivesync <dir> — after the build, mirror the staging folder into a folder (e.g. G:\My Drive\NotebookLM\C_8689) so NotebookLM's "Add from Drive" sees the sources. Mirror semantics: unchanged files are skipped, stale files are removed.
  • --watch — polls the matter and rebuilds automatically when it changes. Rebuilds only after a quiet window (--quiet, default 60 s) so a mid-OCR run doesn't trigger a half-built staging folder; logs to NotebookLM_<ref>_watch.log next to the staging folder.

Auto-update

The staging folder stays in sync with the matter automatically — three mechanisms:

  • Daily sweep (recommended — one task for the whole workspace). tools/okf_nblm_daily.py discovers every matter under the OKF root and runs --check + rebuild where needed. Install it once per machine as a daily Task Scheduler job (07:00 by default; bootstrap prints the exact command on every run):
schtasks /create /tn "OKF_NotebookLM_Daily" /sc daily /st 07:00 /f /rl limited /tr "python '<skill>\tools\okf_nblm_daily.py' --okf-root '<OKF root>'"
# manual run / dry-run:
python "<skill>\tools\okf_nblm_daily.py" --dry-run
python "<skill>\tools\okf_nblm_daily.py" --okf-root "<OKF root>"
schtasks /query /tn "OKF_NotebookLM_Daily" /v /fo list
schtasks /run /tn "OKF_NotebookLM_Daily"
# bootstrap shows the concrete command for this machine on every run

Discovery = immediate children of the OKF root with matter.yaml or 00_Admin/ or 97_OCR_Log/ or 02_Pleadings//02_Contract_Documents/ (excludes Contentious_Template/NonContentious_Template, NotebookLM_* siblings, hidden folders). One rebuild per dirty matter; logs to %TEMP%\okf_nblm_daily.log + console. Pass --drivesync / --max-sources / --no-email through to the builder; limit to one matter with --matter <ref>.

  • --watch (per-matter, continuous). Keeps one staging folder current in the background (poll + quiet window so a mid-OCR batch does not trigger a half-build). Start in a terminal, or install at logon — one task per matter:
schtasks /create /tn "OKF_NotebookLM_<ref>" /sc onlogon /f /rl limited ^
  /tr "powershell -WindowStyle Hidden -Command \"python <skill>\tools\okf_nblm_build.py <matter> --watch\""

Logs to NotebookLM_<ref>_watch.log next to the staging folder. Use for a hot matter that changes intraday; daily sweep remains the safety net.

  • --check (one-shot drift gate). Exit 0 = staging matches the matter, exit 1 = rebuild needed (fingerprint in manifest.json vs matter). Run before relying on a notebook, or call from okf-ocr after a batch (okf-worker already does this and reports the STAGING: line).

  • NotebookLM has no API or sync: the skill keeps the staging folder fresh, but changed sources still need re-uploading into the notebook. The daily/watch logs record each rebuild so you know when to re-upload.

  • --drivesync: mirror the staging folder into a Google Drive folder — then "Add from Drive" in NotebookLM picks up new sources; still re-select/re-add after a rebuild. Pass it to the daily sweeper to mirror every rebuilt matter at once.

Content rules (the script enforces these)

  • Digital PDF (text layer, PyMuPDF check) → the PDF itself is the source (NotebookLM keeps formatting).
  • Scan PDF with _V1_OCR.txt sidecar → the verbatim sidecar is the source.
  • Unprocessed scan (no text layer, no sidecar) → SKIPPED with a warning — tell the user to run the okf-ocr skill first. Never ingest an unreadable scan silently.
  • CSVs (e.g. 03_Productions\05_Extracted_Data) → individual sources; NotebookLM reads CSV tables natively.
  • Emails → 00_Admin\Email_Archive per-thread bundles (the reviewable email layer), one source per thread.
  • Over-cap bundles (auto) → any bundle over 500,000 words is split into NN_<bundle>_partNN.md chunks; a single file larger than the cap is sliced at word-boundary in the staging copy only with (continued, part N) headings. OKF source files are never modified; every staged source stays under the cap so VALIDATE passes.
  • Skipped: 97_OCR_Log, 98_Inbox_ToProcess, images, .eml/.msg (raw), .gdoc stubs, _SRC originals (dupes of filed copies), README/Chronology/matter.yaml (absorbed into the Brief).

Workflow

  1. Identify the matter. User gives a path, or a matter ref from the OKF root. Confirm template type (contentious vs non-contentious — the script detects it from matter.yaml or the folder layout).
  2. Dry-run. Run the build with --dry-run and show the user the plan: source count, bundles vs singles, email threads, warnings (unprocessed scans, oversized sources, over-cap). If the user wants a different split (e.g. more singles for trial prep, or fewer bundles), apply --config overrides and re-dry-run.
  3. Build. Run without --dry-run. Default output: NotebookLM_<ref>\ next to the matter. The Brief is written FIRST so its source map is already populated when the other sources land.
  4. QA the Brief. Read 00_Matter_Brief.md: parties/case block complete, Chronology present and current, Document Index section present, Source Map rows match the staged files (names, modes), warnings section sensible. Fix gaps by re-running (idempotent — the output folder is rebuilt cleanly).
  5. Report. Give the user:
  6. Output path + source count (must be ≤ 300) + any warnings
  7. What to do: new notebook → drag the folder's files → pin 00_Matter_Brief.md
  8. Offer the starter questions from the guide, and note which documents were skipped (unprocessed scans → run okf-ocr first).

Rules

  • Never write into the matter. All output goes to the staging folder; the OKF tree stays untouched.
  • Never modify document content. The script passes sidecars/PDFs through verbatim; no redaction of without-prejudice, privileged or confidential material — flag that the user decides what is uploaded (the guide says so too).
  • Cap discipline. One matter per notebook, ≤ 300 sources. When the plan exceeds the cap, the skill merges the least-impact pairs automatically (sibling bundles → key singles folded into their phase → cross-folder, ties broken by smallest size). Merges appear as warnings in the plan, the Brief and manifest.json; a cross-folder merge also triggers an advisory to raise the cap or split the matter. Nothing is ever silently dropped.
  • Rebuild after change. Any OKF update (OCR, re-filing) → re-run the skill → user re-uploads changed sources (NotebookLM has no diffing).
  • QA before handover. Always read the Brief and spot-check 2-3 sources against the matter (right sidecar for the right scan, chronology current) before telling the user it's ready.

Self-learning

learnings.md sits next to this SKILL.md. Before a run, read it; after a run, append any new lessons (script quirks, template variants, NotebookLM behavior) as dated bullets. Never delete old entries.

Example

User: "Put matter C_8689 into NotebookLM." → locate the matter folder (or the OKF root), dry-run, show plan, build, QA the Brief, report: staging path, source count, warnings (e.g. "3 unprocessed scans skipped — run okf-ocr"), upload steps, and offer to open the guide's starter questions.