Hey, Mark Masters here.

Your swipe file is probably a graveyard.

Mine was for years. A folder full of PDFs, screenshots, bookmarked URLs, and a Google Doc with quotes I promised myself I'd come back to. I never came back to it. I'd start a project, remember the folder existed, open it, scroll for four minutes, close it, and go write the hard way.

The problem isn't that you don't have good reference material. You do. The problem is that a folder of files isn't a working resource. It's a pile.

I rebuilt mine last quarter as a Claude Project with structured metadata and a handful of query prompts I use every time I sit down to write. Now it answers questions like "what have I saved that handles a skeptical B2B audience at the awareness stage of 'knows the problem, hates the usual solutions'" in about thirty seconds.

Here's the full build.

Most working copywriters have the same broken setup. A folder somewhere with screenshots and saved PDFs. A bookmark collection. Maybe a Notion database that looked promising for a week.

Somewhere in there is two hundred pieces of excellent copy that taught you something when you saved it.

You never reference any of it.

When you sit down to write a cold email for a mid-market SaaS client, you don't scroll back through three years of saved Halbert letters. You write the email from scratch, using whatever patterns are currently in your head. The swipe file might as well not exist.

The issue is retrieval. You can't search a pile of screenshots for "how did anyone handle a price objection in the first 50 words of an email." You can search by filename if you were disciplined about naming, and most of us weren't. So the file sits there, accumulating, earning nothing.

The Swipe File Engine fixes this by doing two things. It turns each piece of reference copy into a structured entry Claude can actually reason about.

And it gives you a set of query prompts you run when you're stuck or starting a new project, so the swipe file gets pulled into the work instead of sitting next to it.

At a high level: one Claude Project holds your entire swipe file. Each piece of reference copy becomes a short structured entry with the full text plus metadata about what the copy is doing, who it's targeting, and what problem it solves. Your project instructions teach Claude how to read those entries and how to respond when you ask questions. A small set of query prompts handles the retrieval work.

You build it once. After that, every project you start can pull relevant reference material without you doing the work of remembering what you have.

Three components.

Component #1: The Entries. Each piece of saved copy gets an entry in a standard format. This is the piece most people skip. They upload a folder of PDFs to a Claude Project and expect magic. You'll get better results if each entry is structured so Claude knows what it's looking at.

Component #2: The Project Instructions. A system prompt that tells Claude how to use the entries. What questions to expect, how to cite entries when it pulls them, and what to do when there's no good match in the swipe file.

Component #3: The Query Prompts. A few saved prompts you use depending on what you're working on. Headline research. Structural pattern lookup. Objection handling. Opening line pull. These are the prompts that turn the Project into a daily working tool instead of something you built once and forgot.

Let me walk through each.

Go to claude.ai/projects and create a new Project. Name it "Swipe File Engine" or whatever makes sense to you. The name doesn't matter. What matters is that it has its own Project so the knowledge base is isolated and the instructions apply every time you open it.

Under project instructions, paste this as a starting point:

A few notes on why it's structured this way.

The "reference librarian" framing matters. Without it, Claude tends to drift into generating new copy when you ask for examples. You want retrieval first. Generation second, only on request.

The "cite which entry it came from" instruction prevents hallucination. If Claude can't cite an entry, you know it made something up. That's the trust check that makes the system usable under deadline pressure.

The "if nothing matches, say so" rule is the one I spent the most time on. Early versions of this had Claude pulling weak matches and pretending they were strong. It would cite a B2C email when I asked for a B2B example and paper over the mismatch. Adding explicit permission to say "nothing fits" fixed most of that.

This is where the work is. Each piece of reference copy gets an entry that looks like this:

You need one of these for every piece in your swipe file. I know. That's the part that sounds tedious.

Here's how to make it less tedious. You don't need to convert your entire swipe file in one sitting. You need to convert the next twenty pieces you reference. Then the next twenty. Within a month you'll have the ones that matter and you'll stop converting the rest because you'll realize you were never going to use them anyway.

To speed up the conversion itself, use Claude to help. Give it the raw copy (paste the text, upload the screenshot) and this prompt:

That prompt does about eighty percent of the work. You read through, fix the guesses, and save the entry. I can do five or six pieces in ten minutes this way. Over a week of casual work, you'll have a meaningful library.

Save each entry as its own file in a folder. Once you have a batch, upload them to the Claude Project as knowledge files. You can upload up to several hundred documents per Project, which is more than most working copywriters will have in a usable swipe file.

This is the part that turns the Project from a static knowledge base into a working tool. Here are the four I use most.

Query Prompt 1: Headline Pattern Lookup

This replaces the thing I used to do when I'd stare at a blank page trying to remember a headline pattern I knew I'd seen somewhere. Now I just run the query. Thirty seconds, and I have three patterns to adapt.

Query Prompt 2: Objection Handling

Objection handling is the place where my swipe file earns the most for me. I don't have to remember the specific email that handled "your product is too expensive" well. I just ask.

Query Prompt 3: Opening Move

Opening moves are pattern-dense. Copywriters who've been around a while have fifteen openings they cycle through without thinking. The Engine gives you access to the ones that aren't already top-of-mind.

Query Prompt 4: Structural Pattern Match

That last line is the one that matters. Without it, Claude will reassure you that your structure is fine. With it, you get actual comparison material. The point of the swipe file is to learn from people who solved the problem before you. Reassurance isn't learning.

A few things I had to fix after using this for a few weeks.

Claude will occasionally hallucinate entries. If you ask for something the swipe file doesn't have, and your project instructions aren't tight, it'll make up a plausible example. This happened to me twice before I added the explicit "if nothing fits, say so" rule. Test this deliberately. Ask for something you know isn't in there. If it invents an entry, tighten your instructions.

Metadata quality determines retrieval quality. I added fifty entries in a hurry one weekend and did a lazy job on the DOES WELL field. When I ran my query prompts, Claude couldn't find good matches because my own descriptions were vague. "Strong emotional hook" is useless metadata. "Uses a specific sensory detail in the first 15 words to create scene" is useful. Spend the extra thirty seconds on that field.

The Engine gets better as you add entries, up to a point. Around 80-100 entries, I stopped seeing meaningful improvement in retrieval quality. What I saw instead was Claude pulling redundant examples. If you have three emails that all handle price objections with the same reframe, the Engine will pull all three. You don't need that. Curate as you add. If a new entry is doing something you already have represented, skip it or retire an older one.

You will start saving better reference material. This is the part I didn't expect. Once the Engine existed, I started noticing copy in the wild differently. Instead of "that's a good email, I'll screenshot it," my brain started asking "what would the DOES WELL field say?" The act of articulating why a piece of copy is worth saving makes you read copy more carefully. That's a second-order win I'd pay for on its own.

If you build this properly, a normal session looks like this. You open a new client project. You read the brief. You run Query Prompt 1 against the Engine to see if anything in your swipe file handles the setup. You get back three headline patterns to adapt. You run Query Prompt 3 for opening lines. You start writing.

The Engine doesn't write for you. It shortens the distance between "staring at a blank page" and "I have three directions I trust." That's the entire value.

First drafts still come from you. The Engine just makes sure you're drawing from the best material you've saved instead of defaulting to the five patterns you can recall under pressure.

A swipe file that sits in a folder is a museum. A swipe file you can query is infrastructure.

The difference is thirty minutes of metadata work per entry and one Claude Project. Build it this week.

The first time it saves you forty-five minutes on a deadline, you'll wonder why you waited.

More clicks, cash, and clients,
Mark Masters