The problem
You paid for something once. It works. It's sitting inside one website.
Maybe it's a blog with an admin editor. Maybe it's a support ticket system, an invoice generator, a customer intake form that actually converts. Now you've got a second business, or a second site, or a partner who wants the same thing — and you're staring at three bad options:
- Copy the folder over and spend two days untangling what breaks.
- Pay to have it built again from scratch.
- Say "later" and never do it.
There's a fourth option, and it takes about twenty minutes of your AI's time.
The build pack
A build pack is one Markdown file. Two parts:
- The top is written for an AI: what this thing is, what it does, how to install it, and what to change for a new project.
- The bottom is every source file, embedded verbatim between marker lines.
That's it. One file you can email, drop in Drive, hand to a contractor, or attach to a chat and say "build this." Nothing to zip, nothing to lose, no repo access to hand out. The AI on the other end reads the header, extracts the files mechanically, rethemes it for the new project, and tells you it's done.
The format looks like this inside the file:
===== FILE: server/render.js =====
...the entire file, byte for byte...
===== END FILE =====
Boring on purpose. Boring is what survives a copy-paste through three tools.
Why this beats "just copy the folder"
A folder gives the next AI the code and nothing else. A build pack gives it the code plus the intent — what the feature is for, which parts are the reusable engine and which parts were specific to your old project, and what "finished" means.
That last part matters most. A good header ends with instructions like "retheme every surface to the target project's brand, then grep for leftovers from the original before you call it done." Without that, you end up with your new client's site quietly serving your old client's company name in a meta tag.
Prompt 1 — package the feature
Paste this into Claude Code, Cursor, or whatever AI tool has access to your project files.
I want you to package one working feature of my project into a single
portable Markdown file — a "build pack" — that I can hand to another AI
in a different project and say "build this."
Before you touch anything, ask me these three questions and wait for
my answers:
1. Which feature am I packaging, and where does the project live on
this machine?
2. What is the feature's boundary — is there anything bundled with it
that is specific to THIS project and should not travel?
3. Is there anything that must never leave: API keys, credentials,
client names, real customer data, private business logic?
Once I've answered, do this:
STEP 1 — MAP IT
Find every file the feature actually needs to run: server code, front
end, admin screens, config, dependency manifests, any local preview or
dev harness. List them for me with a one-line description each, and
call out anything you're unsure belongs. Wait for my okay.
STEP 2 — WRITE THE HEADER
At the top of the new file, write instructions addressed to the AI who
will receive this pack:
- What the feature is and what it does, in plain language
- The full feature list, so nothing gets quietly dropped in the rebuild
- Install steps: extraction, dependencies, environment variables,
where each piece is meant to be deployed
- A rethemeing instruction: every brand name, domain, color, logo and
piece of sample content from the original must be replaced with the
target project's, and the AI must grep for leftovers before
declaring it finished
- One discovery question the receiving AI should ask its user before
starting (topic, branding, or business context)
STEP 3 — EMBED THE SOURCE
Below the header, append every file from Step 1 in a stable order,
each wrapped exactly like this:
===== FILE: relative/path/to/file.js =====
<the entire file contents, unmodified>
===== END FILE =====
Before you write anything, confirm no source file already contains
that marker string. Preserve trailing newlines. Do not reformat,
minify, or "improve" any file on the way in.
STEP 4 — VERIFY, DON'T ASSUME
Do all three of these and show me the results:
a) Extract the pack into a fresh empty folder and diff it byte-for-byte
against the original files. It must be identical.
b) Install dependencies in that fresh folder and start the app.
c) Hit the main routes and confirm they work — not just the home page.
Pick a real, representative page, not a nav stub.
Then report back: file count, pack size, and anything you deliberately
left out of the pack and why.
Prompt 2 — rebuild it somewhere else
Attach the pack file in your new project and send this:
Attached is a build pack: an instruction header followed by every source
file embedded between "===== FILE: =====" markers.
Read the header first. Ask me the discovery question it tells you to ask.
Then extract every file, wire it into this project, retheme all of it to
this project's brand and content, and verify it runs before you tell me
it's done. Grep for any leftover names, domains, or sample content from
the original project and clean them out.
If you'd rather extract the files yourself first, this one-liner does it — point it at your pack and your target folder:
node -e 'const fs=require("fs"),path=require("path");const src=fs.readFileSync(process.argv[1],"utf8");const re=/^===== FILE: (.+?) =====\n([\s\S]*?)===== END FILE =====$/gm;let m,n=0;while((m=re.exec(src))){const p=path.join(process.argv[2],m[1]);fs.mkdirSync(path.dirname(p),{recursive:true});fs.writeFileSync(p,m[2]);n++}console.log("extracted",n)' ./BLOG-KIT.md ./my-new-project
What this looks like in practice
We did exactly this with the blog engine that runs the MCAFax notebook. It came out as a 30-file pack in a single 226 KB Markdown file: the server, the server-rendered public site, the React admin editor, and a local preview harness.
What travelled with it: the SEO machinery. Canonical tags, Open Graph and Twitter cards, JSON-LD on every article, a generated sitemap.xml, an llms.txt so AI crawlers can read the site, and an AI endpoint that fills in meta title, description, keywords, FAQ and image alt text on save.
What got left behind: everything specific to the original project. That's the discipline — a reusable pack is the engine, not your business.
And the verification step earned its place. The first smoke test grabbed a nav page instead of a real article and reported a clean pass. It wasn't wrong, it just wasn't testing anything. This is the most common way an AI build "succeeds" without working: it checks the easiest surface and stops. Make it name the exact page it tested.
Where people get stuck
- The boundary. Deciding what's the engine and what's the old project is a judgment call, and AI tends to over-include. Look at the file list in Step 1 and cut.
- Secrets riding along. Config files love to carry keys. Answer question 3 honestly and check the pack before you send it anywhere.
- Skipping verification. A pack that extracts but doesn't run is worse than no pack, because you won't find out for a month.
- Half-rethemed output. Grep for the old brand name yourself. It takes ten seconds.
If you hit a wall on any of this, email info@mcafax.com and we'll walk you through it — no charge, no pitch. We build these for our own businesses and we're happy to look at yours.
More free prompts:
- Add a blog and admin content system to your business website — the feature this build pack was made from, as a from-scratch prompt.
- The Stop the Spam Calls toolkit — if broker calls are eating your day, start here.
And if you're actually looking for money: we work with small business owners on funding, including SBA and government-backed options. Email info@mcafax.com and tell us what you're trying to do.