Stop Reading, Start Learning: My 10 Favourite NotebookLM Prompts for PDFs

I used to spend 45 minutes reading a report cover-to-cover — only to realize the 3 sentences that actually mattered were buried on page 37.

Now I get those 3 sentences - plus the context, the caveats, and a plan of action — in under 5 minutes.

The tool is Google's NotebookLM. Unlike general AI chatbots, NotebookLM is grounded entirely in your sources — it only answers from what you upload, so no hallucinations.

But grounding only gets you halfway there. The other half is the prompt. A vague prompt gets you a vague summary. A sharp prompt turns a 50-page report into a working asset.

Here are the 10 prompts I go back to every time — organized by what I'm actually trying to do with the document.

 

How to use these prompts Once you've uploaded your PDF to a new Notebook, head to the chat interface. Copy and paste the prompt, replacing the bracketed information [like this] with your specific details. For the best results, use the 'Pin' feature to save the most important responses for future reference.

 

Section 1: For Quick Understanding (The “First Read”)

Prompt 1.1 — The Beginner-Friendly Summary

PROMPT Summarize this PDF about [topic] for a [beginner/student/business owner/general reader]. Include: •     The PDF's main purpose •     Five key ideas •     Simple explanations •     Important facts or examples •     A “What this means for you” section Critical: Define all technical terms in plain language before using them. If a term is essential, explain it in parentheses the first time it appears (e.g., “machine learning (a type of AI that learns from data)”).

 

💡 PRO-TIP If the summary is too long, ask it to condense it further into a 'TL;DR' version using a follow-up prompt like, 'Now give me that in 3 bullet points.'

 

Prompt 1.2 — The Critical Review

PROMPT Critically review this PDF in a fair and balanced way. Evaluate: •     Main objective •     Argument strength •     Internal consistency (replaces “source reliability” — an LLM can't verify outside the PDF) •     Clarity •     Assumptions •     Bias •     Missing information •     Weak or contradictory points •     Practical usefulness Then provide three strengths, three weaknesses, claims requiring external verification (since you can't verify outside the PDF), further research questions, ideal readers, an overall score out of 10, and a short final verdict.

 

💡 THE 'TRUST METER' FOLLOW-UP After it gives the score out of 10, ask: 'What would need to change in this PDF for you to raise the score from [X] to a 9/10?' This gives you a concrete roadmap of the document's biggest flaws — and how to move ahead from there.

 

Section 2: For Deep Dives (The “Second Read”)

Prompt 2.1 — Detailed Notes From Every Section

PROMPT Convert this PDF into organized notes for [purpose]. For each chapter or section, include: •     Main idea •     Key supporting points •     Important facts, examples, dates, or statistics •     Key terms with simple definitions •     Practical lesson •     One-sentence summary Finish with the ten most important takeaways from the entire PDF.

 

💡 PRO-TIP After it generates the notes, ask: 'For the most complex sections, explain them as if you are teaching a college student who missed the last 3 classes.'

 

Prompt 2.2 — The Personal Tutor

PROMPT Act as a patient tutor and explain the most difficult parts of this PDF about [topic]. My knowledge level is [beginner/basic/intermediate]. For each difficult concept, include: •     A plain-language explanation •     A relatable analogy •     A real-world example •     Step-by-step breakdown •     Key term definitions •     One question to test my understanding End with the best order for learning the concepts.

 

💡 ASK FOR A 'LEARNING PATH' After it explains the concepts, follow up with: 'Based on these explanations, create a 3-day study schedule to master these concepts, starting from absolute zero.'

 

Section 3: For Information Extraction (The “Research Phase”)

Prompt 3.1 — Key Claims With Source References

PROMPT Identify the [10/15/20] most important claims, findings, or recommendations in this PDF. For each one, provide: •     The claim •     A simple explanation •     Why it matters •     Supporting evidence •     Page, section, or source reference •     Support level: –    Strong = direct evidence is provided within the PDF –    Partial = evidence is mentioned but not fully explained, or relies on assumptions –    Unclear = claim is stated but lacks specific evidence Do not include information that is not supported by the PDF.

 

💡 ASK FOR 'DIRECT QUOTES' VS. 'PARAPHRASING' Add to your prompt: 'For each reference claimed, provide ONE direct quote from the PDF that backs it up, AND one paraphrased explanation.' This gives you verbatim evidence to copy-paste into your own work.

 

Prompt 3.2 — Generate the Right Questions

PROMPT Create 15 important questions a reader should ask about this PDF on [topic]. Organize them into: •     Basic understanding •     Evidence •     Practical use •     Risks •     Limitations •     Missing information For each question, give the answer, source reference, and label it Complete, Partial, or Not Answered. Finish with the five most important unanswered questions. If you need more questions, ask for a follow-up batch of 15.

 

💡 ADD A 'MOST CONTROVERSIAL' CATEGORY In your prompt, add: 'Include a category called “Controversial Questions” — questions that challenge the core assumption of the PDF.' This is where the most valuable critical insights lie.

 

Section 4: For Practical Application (The “So What?”)

Prompt 4.1 — The Action Plan

PROMPT Turn the useful ideas in this PDF into an action plan for [business/studies/career/content/project]. For each action, include: •     Goal •     Recommended action •     Step-by-step instructions •     Why the PDF supports it •     Tools needed •     Possible challenge and solution •     Priority •     Suggested deadline Organize the actions into today, this week, this month, and long term.

 

💡 ASK FOR KPIS (KEY PERFORMANCE INDICATORS) Add: 'For each action, suggest 1–2 measurable ways to know if the action was successful.' This makes the plan accountable.

 

Prompt 4.2 — Compare the Main Ideas

PROMPT Compare the main ideas, strategies, methods, or options discussed in this PDF. Create a table covering: •     Purpose •     How it works •     Advantages •     Limitations •     Best use case •     Risks •     Key differences If the table becomes too wide or repetitive, simplify to just: Purpose, Advantages, Limitations, Best Use Case. Then explain which option is strongest, easiest, riskiest, and best for [specific situation], based only on the PDF.

 

 

Section 5: For Content Creation (The “Repurpose Phase”)

Prompt 5.1 — Repurpose Into Social Media Content

PROMPT Turn this PDF about [topic] into content for [Instagram/LinkedIn/X/YouTube]. Audience: [target audience] Tone: [friendly/professional/conversational] Create: •     Five hooks •     One [7/10]-slide carousel •     One caption •     One [30/60/90]-second video script •     Five engagement questions •     Three calls to action •     Ten future content ideas Keep every claim accurate and supported by the PDF.

 

 

Section 6: For Exam Prep

Prompt 6.1 — The Complete Study Guide

PROMPT This one is a 2-step process: Prompt 1: Turn this PDF into a study guide for [exam/course/topic] at a [beginner/intermediate/advanced] level. Include: •     Topic overview •     Section summaries •     Key terms •     Important facts, dates, formulas, or frameworks •     Commonly confused concepts •     Revision checklist Focus especially on [important topics]. Prompt 2 (follow-up): Now create 10 short-answer questions, 10 multiple-choice questions, and 5 scenario questions based on this study guide. Provide answers with explanations for each.

 

💡 GENERATE A 'WEAKNESS DETECTOR' Follow up with: 'Based on the questions you've created, which 3 topics would a student be most likely to fail? Create a “Danger Zone” checklist for these.'

 

One Last Thing: A Note on Accuracy

NotebookLM is grounded in your sources, but it's still AI. Always double-check critical claims — especially anything flagged “Partial” or “Unclear” in Prompt 3.1. Use it as a brilliant research assistant, not a replacement for your own judgment.

 

NotebookLM is a powerful tool, but it's the quality of your prompts that unlocks its true potential. These 10 prompts are my go-to arsenal for tackling any PDF, from academic papers to business reports. They save me hours, boost my comprehension, and help me turn information into action.

 

Now it's your turn. Pick one prompt from the list that resonates with your current project and try it out. Which prompt are you most excited to test? Let me know in the comments below!

From Coder to Orchestrator: Best Practices for Tech Leads Using Claude Code

The era of the Tech Lead as the "fastest coder in the room" is over.

"Beginners use Claude to avoid thinking. Intermediate users use Claude to think faster. Power users use Claude to think better."  

 

Today’s top engineering leaders aren't just writing code—they’re orchestrating AI agents that can generate it at superhuman speeds. The new core competency? Writing detailed prompts, reviewing massive amounts of code, and investing in shared tooling.

Claude Code has emerged as a powerhouse in this new landscape (crossing $1B in annualized revenue within six months of launch). But raw AI power without discipline is dangerous. Left unchecked, it can easily destroy a working codebase.

Here is a comprehensive guide to using Claude effectively across the entire software development lifecycle, synthesized from top engineering managers and the Claude Code team.

 

Part I: The Mindset Shift 

You Are the Tech Lead; Claude is Your Genius Junior The single most important shift is understanding your new role. Claude is your genius junior engineer: fast, brilliant, but requiring constant coaching and explicit rules. It can generate thousands of lines of code in minutes, but it needs clear specifications and architectural guardrails.

Think in Roles, Not Just Code Most developers open Claude and immediately ask it to build something. This is a mistake. Think of Claude in four roles: Architect, Tech Lead, Senior Engineer, and QA. Most people jump straight to Senior Engineer. A production-ready workflow requires Claude to act as the Architect and Tech Lead before writing a single line of code.

 

Part II: Architecting with Claude 

 

Start with Documentation, Not Code Before generating code, create a persistent foundation of documentation:

• 
  
  CLAUDE.md: Your project's persistent context (tech stack, standards, testing, security).
  
• ARCHITECTURE.md: System components, data flow, and security boundaries.
• FEATURES.md: Explicit feature definitions to prevent Claude from assuming a feature is "done" when it isn't.

Use Claude as Your Architect Your first prompt shouldn't be "Build the app." It should be:

"Read CLAUDE.md, ARCHITECTURE.md, and FEATURES.md. Act as a Principal Architect. Review the architecture. Identify design flaws, scalability concerns, and missing components. Do not write code."

This single step often saves days of rework. Always design database schemas and API contracts before implementation.

 

Part III: Implementation Planning 🗺️

The Plan-Act Loop Your mantra must be: Plan first, ship in slices. Let speed amplify good process—never replace it.

1. Plan: Force Claude to think through the approach.
2. Review: Check the plan across multiple axes (architecture, dependencies, scaling, single points of failure).
3. Act: Once approved, let Claude execute.

Use Plan Mode for Complex Tasks Using Plan mode is like repeatedly aligning requirements with a PM before development. Once the plan is confirmed, execution can be handed over to the AI to run automatically with minimal supervision.

 

Part IV: Code Implementation at Scale 

Run Multiple Sessions in Parallel The biggest productivity unlock is running 3–5 Claude sessions in parallel, each in its own git worktree. Use claude --worktree in the CLI. This breaks the traditional linear development mindset.

Multi-Agent Orchestration For large projects, use a lead-agent model. Prompt Claude to create a team, spin up teammate agents in isolated worktrees, and assign tasks (e.g., Backend API, Frontend React, DB migrations).

Delegate Research to Sub-Agents Context dilution is real. Keep your main thread focused by delegating heavy research and file-reading to sub-agents.

Implement Institutional Memory Set up a 'memory' folder for agents to automatically store important findings. This creates institutional memory that persists across sessions, preventing agents from redoing trivial research.

 

Part V: Code and Technical Reviews 

 

Verification is the #1 Practice The Claude Code team emphasizes that the most impactful tip is verification—giving Claude a way to check its own output. Use automated tests, CI/CD pipelines, and review agents. If you only adopt one practice from this article, make it this one.

Don't Let Claude Touch Git Directly Allow Claude to do most things, but reserve Git privileges for yourself. Do frequent diffs, commits, and pushes. Comprehension ≠ compliance. In one documented case, an agent pushed directly to main despite explicit instructions to open a PR—and then pushed its own apology directly to main!

 

Part VI: Security and Production Readiness

• Containerize Everything: Claude might attempt privilege escalation (like writing to /etc/shadow). Docker with no host mounts and restricted networks is non-negotiable.
• Use Bot Accounts: Give each agent instance its own GitHub bot account for transparency and fine-grained permissions.
• Make Tests Reliable: Flaky tests are worse than no tests. If CI is unreliable, the agent will use every failure as an excuse. Force the test harness to be reliable so it has to actually fix its bugs.
• Define Hard Rules: Encode critical rules in CLAUDE.md (e.g., "Every function gets a test," "Never use global mutable state," "Insist on descriptive error messages").

 

Part VII: Team Standardization

Left to their own devices, developers will build fragmented Claude setups. A team with a shared configuration is 3-5× more effective than devs working individually.

Standardize your CLAUDE.md, permission configs, and security practices across the team. Regularly let Claude update CLAUDE.md itself—it's essentially reinforcement learning through agent feedback.

 

Conclusion: The Elevated Tech Lead

The technical lead's role in the age of AI is not diminished—it is elevated. You are no longer just writing code; you are:

1. Framing the constraints and plans.
2. Teaching agents how work should be done.
3. Orchestrating parallel agents across worktrees.
4. Reviewing plans and code rigorously.
5. Standardizing team configurations.

Sometimes, it's more satisfying to watch the agents operate than to ship the feature yourself. But satisfaction aside, the real measure is impact. With the right practices, a single tech lead can orchestrate what once required entire teams.

Discipline is the only thing that makes AI coding reliable. Plan first, verify always, and never confuse speed with quality.

 

Over to you: What has been your biggest challenge in transitioning from writing code to orchestrating AI agents? Have you experimented with git worktrees or multi-agent setups yet? Let me know in the comments below! 👇

(If you found this valuable, consider subscribing to my Twitter or Plus91's AI Academy for more insights on engineering leadership and AI orchestration.)

 

When using Claude as a TL to carry out a Technical Lead Code Review, how do you review each Plan andImplementation Cycle on a separate chat?

The crux of this post is not just "How do you pass Context between chats?", but also how do you ensure relevant context is provided and nothing more. There is no need to waste tokens. 

For carrying out a technical review for every work package, i would like to open a new chat instead of keeping one huge thread open for days, my typical development cycle can last 6-7 days and runs across 25+ work packaged. What all should I add to the beginning of the chat for continuity. Is the 1st prompt enough or should I add the SRS and PRD and the original implementation plan or something else, or none of these

My Main Question --> When using Claude as a Reviewer, how do you review each Plan and execution on a separate chat?  

Here is what Claude guides us to do

Short answer: the full SRS and PRD — no, not needed. The specific WP's approved implementation plan — yes, that's the one document that actually matters every time. Here's the breakdown of what's load-bearing versus what's just bulk.

Include every time

1. The final approved implementation plan for that specific WP. This is the actual contract the code is being checked against — everything else is secondary to this. Attach it as a file. 
2. Repo access + exact branch/commit. State the branch name and current HEAD SHA up front, and confirm the repo is public (or however you're granting access). This alone would have saved several rounds of back-and-forth in this conversation.
3. The git add -N . step, stated as a given, not discovered. Just open with "diff generated via git add -N . && git diff --binary --no-ext-diff" from message one. We only found this was necessary after two rounds of incomplete diffs — no reason to relearn that per WP.
4. A one-line list of what's already merged and proven, e.g. "WP-01A (outbox fencing, rate limiter, scheduler lock), WP-01B-1 (RBAC, session ambient-transaction guard), WP-01B-2a (sealed delivery, confirmation contexts) are merged and their patterns are the baseline to match." This is a cheap sentence that saves me from re-deriving "is this consistent with prior work" from scratch.
5. The specific review ask, with this structure: numbered focus areas, the mandatory invariants unique to this WP, the Blocker/Important/Follow-up classification, and the exact verdict options. This has been doing real work — it's what keeps my reviews from wandering.

Don't bother re-attaching

• The full SRS or PRD. They're large, mostly stable between WPs, and pasting them wholesale risks me reasoning against a possibly-stale copy instead of the authoritative repo version. If a specific WP genuinely turns on an SRS clause, quote or link that one section instead.
• AGENTS.md / DECISION_LOG.md / the Technical Architecture doc, in full. These live in the repo and are the actual source of truth — if you give me a repo link (or raw file links, same pattern as the code), I can fetch the specific section I need rather than working from a copy you pasted that might already be one commit behind reality.
• Prior WPs' full review transcripts. The outcome of those reviews is now just... the merged code. I don't need the argument that got us there; I need the result, which is sitting in the repo.

One structural suggestion

Since AGENTS.md is apparently the living home for cross-WP invariants (transaction rules, fencing patterns, logging rules), it might be worth treating it as the one document that's always worth a fresh read at the start of each new WP chat — not because I need to be told about it, but because if it's been updated between WPs (which it should be, given how many corrections we've folded back into "the pattern" over this project), I want the current version, not my memory of an earlier one.

So, in practice: a short kickoff message (branch, HEAD, what's merged, the plan attached, the review ask) rather than a document dump. That's roughly the size of your very first message in this chat, just repeated per WP instead of accumulated.