I Pasted a Claude Skill Into NotebookLM and It Worked. Until It Did Not.

What the failure taught me about which tools belong in which layer of an AI workflow.

Photo by Mary Anne Twimbers on Unsplash

I want to say upfront that I am not an expert in any of this. I am a small business operator who has been using AI tools for the last two years to do work I would otherwise have to hire someone for. The way I learn what these tools can and cannot do is by trying things, watching what happens, and writing down the patterns. This article is one of those patterns.

The reason I am writing it is that the AI tool space, right now, feels like walking through a building with the lights off. The tools are all there. The walls are real. But none of us — the people actually using these tools every day to make decisions — has a complete map of where the walls are. Every test that produces a clear result, even a negative one, is a small light. The map gets clearer one bulb at a time.

The test I want to describe in this article gave me a clear result. The result was not what I was expecting. And the lesson it taught me is, I think, more useful than the experiment itself.

The hack

Three weeks ago I was thinking about whether I could push NotebookLM further than its default use case. I had been running it for analysis work — load sources, ask questions, get grounded answers — and I wondered what would happen if I took something I knew worked well in Claude and tried to make NotebookLM run it instead.

The thing I tried to move across was a Claude skill — one of the markdown files I have built over the past six months that tell Claude how I want a particular kind of task done. Skills work in Claude because they sit in the context and shape every response the model gives me when that task comes up. I wanted to see if NotebookLM could play the same role for the right kind of work.

The setup was simple. I copied the contents of a skill into the About message field of a NotebookLM notebook — the customise area where you can write a brief that the tool reads alongside your sources. Then I added the source material the skill was supposed to operate on: ten PDFs, a mix of supplier data, marketplace pricing, and product analysis. The notebook now had two things sitting underneath every question I asked it — the skill telling it how to behave, and the sources telling it what to think about.

Then I ran tests. Not just one. I want to be clear about the scope of what I am about to describe, because a single failed run could just be bad luck. I have now run this same hack across eleven of the skills I use weekly — the maibo skills that handle everything from supplier vetting to listing generation to stock decisions. The pattern is consistent enough that I trust it. Extraction-shaped skills land near-perfect. Analysis-shaped skills land near-perfect. Decision-shaped skills wander.

What worked

The first test was the maibo-price-research skill. This is a knowledge extraction tool I use across UK marketplace data — it takes pricing inputs from any seller platform and produces a structured comparison output, ranked by margin and competitive density. The skill is built to be transferable across countries and channels, so it is essentially pure extraction with a little structural shaping on top. Exactly the kind of work NotebookLM is built for, given that RAG-grounded retrieval (where the tool answers from your sources rather than from its training data) is the thing it does best.

The skill, sitting in the About message, did its job. The output came back in the format the skill specified, with citations to the original sources, and the data was accurate. I went through it line by line against the source PDFs. Out of maybe a hundred individual data points across the comparison, I found fewer than one or two that I would have wanted to phrase differently. Practically speaking, this was a clean run. Call it ninety-nine percent.

The second test was an analysis task — not yet a decision, but pattern recognition that goes a step beyond raw extraction. Take the same source material, identify what is moving and what is not, weight the evidence, surface conclusions the raw data alone would not show. This is closer to the edge of what NotebookLM is comfortable with, but the skill in the About message gave it a clear analytical framework to follow.

The output, again, was strong. The patterns the skill asked it to look for came back identified, weighted, and supported by source citations. Two for two on the first two tests, both at near-perfect quality. I started to think the hack might be more powerful than I had expected.

Then I ran the third test.

What did not work

The third test was the maibo-stock-decision skill. The structure of this skill is genuinely a decision tree — it takes input on margin (in the high teens or above for me to commit), supplier rating, stock depth, and recent demand signal, and applies a sequence of conditional rules to produce a commit, hold, or walk-away recommendation. The skill is essentially if-then logic with real money attached to whether the rules hold.

The output NotebookLM produced was not wrong in any obvious way. The format looked right. The reasoning sounded plausible. The citations were still attached. But when I read it line by line against the rules in the skill, something was off. Two items that should have been flagged risky on margin were marked as moderate. One item that should have failed the supplier-rating check passed without comment. The model had read the rules — it referenced them in its reasoning — but it was treating them as suggestions rather than as enforcement. The underlying logic of the skill had been quietly softened.

I tried again. I ran the same prompt with a clarifying nudge — please apply the margin threshold strictly. The second pass was closer. I ran it again. The third pass was closer still. By the fourth or fifth iteration, with small corrections each time, the output finally converged on something close to what the skill was supposed to produce on the first run.

This is the part of the failure that took me the longest to understand. The decision skills do not fail completely. They almost work. The model can find the right answer. It just cannot apply the rule consistently on the first pass the way Claude does, and the cost of getting there is four or five rounds of back-and-forth — exactly the kind of token-burning iteration the original test was supposed to eliminate.

I ran the maibo-competitor-intelligence skill next. Same pattern. Output that nodded at the rules but did not enforce them. The same multi-iteration recovery curve. By the time I had tested across eleven different skills in this category, the picture was clear. The limit was not a bug in any single run. It was structural.

The reason

NotebookLM does conditional branching the way someone gives directions when they have not actually been to the destination — close enough to feel right, wrong enough to get you lost.

The technical explanation, as best as I can put it, comes down to how the two tools are built. NotebookLM is RAG-grounded (retrieval-augmented, meaning the tool prioritises answering from your sources). Claude is instruction-following (meaning the tool prioritises applying the rules you give it). About message in NotebookLM is not a system prompt — it does not enforce behaviour the way a system prompt would. It is more like additional context the tool considers alongside the sources, and when there is tension between what the rules say and what the sources say, the sources tend to win.

This works fine when the task is extraction or analysis, because there is no real tension — the rules are about how to look at the sources, not about overriding them. The sources contain the answer, the rules just shape how to present it.

It breaks down on conditional branching, which is the heart of any decision-making skill. The kind of logic that says if X then do A, otherwise do B requires the tool to actually choose a branch and commit to it, even when the sources are pulling in a different direction. NotebookLM does not enforce that choice. It blends the rule into the source-driven reasoning and produces output that nods at the branch without actually taking it.

This is the conditional branching enforcement (the consistent application of if-then logic) gap, and it is the specific limit I had not seen before running the test. Knowing it exists changes how I think about which work belongs in which tool.

The downstream effect

There is a smaller, related issue that comes from the same source. Decision-making skills often require the tool to monitor its own output — what people in this space call meta-cognitive (self-monitoring) behaviour. The skill might say if you are about to recommend a commit but you have not seen the margin data, stop and ask for it. For that to work, the tool has to be able to look at what it is about to produce and check it against the rule.

When the conditional branching is already loose, the self-monitoring fails too — because there is nothing for the monitor to check against. The rule is a suggestion, the branching is a vibe, the output is whatever the sources push it toward. The whole layer of disciplined behaviour the skill was supposed to enforce gets quietly diluted, and you do not always notice unless you are reading the output carefully against the rules.

This is the part that matters most for someone making real decisions on this output. The output looks right. It feels right. The discipline you thought you had built into the skill is not actually there, and you only find out when a recommendation that should have been a hard no comes back as a soft maybe.

What this changed about my workflow

The practical takeaway is straightforward. NotebookLM and Claude are not competing tools. They are different layers of the same workflow.

NotebookLM goes at the front — extraction, analysis, comparison, pattern recognition. The work where source material is the asset and the tool’s job is to organise and surface what is in it. The skill-in-About-message hack is genuinely useful here, because the rules in the skill are about format and method, not about enforcement. Knowledge extraction with skill-shaped output is something close to ninety-nine percent. I now run a lot of my upstream research this way and it has been clean.

Claude goes at the back — decisions, hard rules, format-critical output, anything where the discipline of the skill needs to actually hold. The output from NotebookLM gets handed to Claude with the source citations intact, and Claude applies the decision logic the way the skill specifies. The two tools doing two different jobs, rather than competing for the same job.

The mistake I almost made — and that I think most people in this space are making, based on the way the tools are usually framed — was treating them as alternatives. They are not alternatives. They are layers. Putting a tool in the wrong layer wastes time on output that looks right and quietly fails.

What this means more generally

I started this article saying I am not an expert. I want to repeat it, because the lesson I took from this test is one I think generalises well past my specific situation, and I do not want to oversell it.

The lesson is that the limits of a tool matter more than the features of a tool. Every popular AI tool right now has a long list of features and a much shorter list of explicitly stated limits. Most of what gets written about these tools is feature-focused — what they can do, what is new, what is impressive. Almost none of it is limit-focused — what they cannot do reliably, what they do badly, where they break.

The result is that most professionals using these tools are doing what I was doing for months. They are using the tools confidently inside the part of the territory the marketing has shown them, and stepping unknowingly across limits they do not know exist. The confidence is misplaced. The unknown limits are where the time gets quietly wasted.

The thing that helped me, and the thing I would suggest to anyone else trying to navigate this, is to test the limits explicitly. Pick a tool you use regularly. Pick a task you assume it handles well. Push that task to the edge — give it an extra layer of complexity, a stricter rule, a harder constraint. See where it breaks. The break point is the most useful piece of information you can have about that tool, and it is the one piece of information no marketing material will ever give you.

A question, because I genuinely want to know. What is the next AI tool you have been using whose limits you have never actually tested? The answer to that question, in my experience, is the place where most professionals quietly waste the most time.

I have spent twenty years on the supply side of consumer electronics and the last 2 years building AI workflows for the daily decisions of two small companies. I am not an AI expert. I am someone who tests these tools against real work and writes down what happens.