A swipe file is the running collection of work you save because it's good — ad copy that landed, an email subject line that made you open, a landing page hero that made the offer obvious, a hook from a video that grabbed you in the first three seconds. Every working creative builds one. Few of them ever search the file once it exists.
That's the hard part. Saving is easy. Retrieval is the actual job. A swipe file only pays off when you can find the right reference at the moment you need it — the moment you're staring at a brief and trying to remember the structure of a hook that worked.
This guide is about building a swipe file in a notes vault that the agent can read, search, and pull patterns from on demand. The "vault you stay in" pattern is the same one we describe in how to build a content calendar from your notes — the swipe file feeds the calendar, the calendar pulls from the file.
What a swipe file is for, in practice
The swipe file is not a museum. It's a working reference. The job it does, when it does its job, is this: you sit down to write a cold email, and instead of staring at a blank page you ask the file for the three best opening lines you've ever seen for a cold email to a senior buyer. You get them in front of you in ten seconds. You write your version, informed by what's worked before.
Or you're designing a landing page hero and you ask for every above-the-fold layout you've saved that uses a single oversized photograph with a one-line headline. You get them. You see what the headline length range was, which ones used a primary CTA versus a secondary one, what the proportions felt like.
That's the work. The system needs to support that retrieval, not just the saving.
The shape that holds — one page per piece, plus a database
The swipe file works as one page per saved item, with a tabular view across all of them.
Each item gets its own page in a "Swipe" section. The page holds the artifact (a screenshot, a clipped paragraph, a transcript snippet, a PDF), a few notes about why you saved it, and tags for what kind of asset it is, the format, the source, and the year. The page is plain markdown — no proprietary format, no tool you'll outgrow.
Across the top of the section, an inline database via the :::database::: directive gives you the tabular view: title, type, format, source, tags, date saved. Filter by type to see all the cold-email examples. Filter by format to see all the long-form sales pages. Sort by date saved to see what's been added recently. The same swipe file, queried different ways for different jobs.
Unlimited page nesting means you can group by category if you want — ads, emails, landing pages, video hooks, podcast cold opens, design references, copy frameworks. Or keep it flat and let tags do the grouping. Either works.
The capture habit — small enough to actually do
The reason most swipe files fail is the capture step is too heavy. If saving an item takes two minutes, you'll save four things and then stop. If it takes ten seconds, you'll save four hundred.
The capture habit that holds:
- See something good.
- Open the swipe section.
- New page. Drop in the screenshot or the snippet.
- Type two lines: what it is and why you saved it.
- Add tags. Done.
That's the whole loop. The two lines of context matter more than the artifact — six months from now you won't remember why this specific email subject line caught you. The note tells future-you. "Used a contrarian framing in the first half, made the offer concrete by line two" is enough.
The agent can help with the bulk-import case. When you're starting the swipe file from a folder of screenshots you've been collecting in your camera roll, drop them in. PDFs auto-convert to markdown via docstrange so the agent can search them. For each one, ask the agent: "Look at this image and the URL it came from. Suggest a one-line description and three tags." You edit, accept, move on. Twenty items in fifteen minutes.
Tagging that survives a year
Tags are where most swipe files quietly fall apart. You start with five tags, add three more, then six months later you have forty and no two items use the same vocabulary.
A workable tagging system has three layers: type (what kind of asset), function (what job the asset is doing), and source (where you saw it). Nothing else. Type tells you whether you're looking at copy, design, or video. Function tells you whether the asset is selling, onboarding, retaining, educating. Source lets you trace it back if you want the full context.
Don't tag emotionally — "great hook," "love this," "amazing." Those tags don't help you find anything. Tag descriptively, so future-you searching for "cold-email opener directed at executive buyers in B2B SaaS" can actually find the page.
The agent can do the cleanup pass when the tags get messy. Ask: "Read every tag I've used in the swipe file. Group similar ones together and propose a consolidated taxonomy." You'll get a recommendation. You decide what to keep. Then ask the agent to apply the consolidation across all pages. Forty tags collapse into eighteen, all of them used the same way.
Pattern-finding — the part nobody talks about
The swipe file gets really useful when you stop using it as a lookup table and start using it as a research surface.
You're working on a launch. Ask the agent: "Read every product launch announcement in my swipe file. What structures recur? Which ones lead with a problem, which lead with the product, which lead with the founder story? Which formats got the best engagement signals according to my notes?" You get a synthesis of your own collected wisdom — a thing that took years to accumulate — surfaced in ninety seconds.
Or you're stuck on a positioning brief. Ask: "Pull every example in the swipe file where a company successfully positioned against a much bigger competitor. What rhetorical moves did they use?" The agent reads everything tagged competitor-positioning and writes you a short pattern report. You don't get a generic listicle. You get a synthesis grounded in the things you yourself decided were worth saving.
This is the move that turns a swipe file from passive storage into active research. The agent reads the whole archive in seconds — something you'd never do manually — and pulls the throughline.
Cross-referencing your own work
The most powerful version of the swipe file connects to your own past work. Your sent emails, your past landing pages, your old ad copy. Drop them into the vault next to the swipe file. Tag them with what kind of asset they are. The drafting move that pairs with this — pulling from the swipe file when you sit down to write — is documented in drafting emails, proposals, and newsletters inside your notes app.
Now you can ask: "Compare the cold-email openers I've written this year against the ones I've saved in the swipe file. Where am I copying patterns that work? Where am I missing patterns I'd recommend if a junior wrote it?" That's a real critique grounded in your own taste, applied to your own output. Embarrassing, useful, hard to get any other way.
When the swipe file feeds the writing
The eventual use case is the swipe file generating a starting point for new work. Not a finished draft — that's not what swipe files are for — but a structured first move.
Open a new page for the email you're writing. Drop in the brief at the top. Ask the agent: "Pull the three openers from my swipe file most relevant to this audience. Pull the two strongest CTAs I've saved. Don't write the email — just lay out the reference material so I can write from it." You get the swipe file's relevant pieces in one place, ready for you to actually do the writing.
That's the right division of labor. The agent fetches and arranges. You write. Working from your own collected references gives you a draft that sounds like the work you've decided is good — which is the only quality bar that matters.
Maintenance — the quiet part
A swipe file decays without occasional maintenance. Items get out of date. Tags drift. Pages accumulate that you can't even remember why you saved.
Once a quarter, a thirty-minute pass: ask the agent to pull every item not viewed in six months. Skim the list. Archive the ones that no longer earn their keep, retag the ones whose categories have shifted, demote any whose source URL is now dead and the screenshot lacks context. The file stays a working reference, not a junk drawer.
The same pass is also a chance to ask the agent what it sees: "Looking at the last quarter's additions, what categories am I overweight on? What categories haven't been added to in six months even though I work in them?" Sometimes the agent flags the gap you'd missed. The swipe file should reflect what you actually do, and it will drift if you don't pull it back occasionally.
The point underneath all of this
A swipe file is a bet on future-you. You're trusting that the work of capturing and organizing now will pay off when you sit down to write later. That bet only pays out when retrieval is fast and the system holds together over years.
A vault gives you the durable plain-markdown storage. Inline databases give you the tabular query. The agent gives you the search and the pattern-finding. Together they make a swipe file that earns its place — not just a folder of screenshots, but a working reference you actually open. If you came in from researching tools, our Notion comparison and Obsidian comparison cover where Docapybara's shape lands against block-based and local-first alternatives.
Try Docapybara free — sign up, drop in ten of your favorite saved references, and ask the agent what patterns it sees.