# Rebuild a $2,000 feature in 20 minutes: the one-file kit By MCAFax · Published September 6, 2026 · Updated October 3, 2026 Section: Markets & Main Street › Small Business · Series: AI Hacks and Tips (https://mcafax.com/notebook/prompts) Canonical: https://mcafax.com/notebook/free-prompt-turn-a-working-feature-into-a-one-file-kit-your-ai-can-rebuild-anywh Source: MCAFax, The Broker's Notebook (https://mcafax.com/notebook). MCAFax is not a lender or a law firm. --- "Can we get the same blog on the new site?" You paid for that feature once. It works. And now it's stuck inside one website. Here's the one rule that gets it out: don't copy the folder. Package the feature into a build pack. That's a single Markdown file with instructions for an AI at the top, and every source file underneath, embedded byte for byte between marker lines. ## The math on rebuilding Say a contractor quotes 20 hours at $100 an hour to rebuild your blog on the second site. That's $2,000. The pack route is one prompt, about 20 minutes of AI time, and an hour of you checking the result. Even if the AI's rebuild needs a $300 cleanup, you're still about 85% under the quote. We did it with the blog engine behind this notebook: 30 files, one 226 KB pack. ## Prompt 1: package the feature Paste this into Claude Code, Cursor, or any AI tool that has access to your project files: ```text 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 ===== ===== 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 the new project and send this: ```text 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. ``` Or extract the files yourself with this Node one-liner: ```text 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 ``` ## Where it goes wrong 1. The boundary. AI tends to pack too much. Cut the Step 1 file list down to the engine. 2. Secrets riding along. Config files carry keys. Search the pack for "key," "secret" and your domain before you send it anywhere. OWASP's [secrets cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) covers what to strip. 3. Fake verification. Our first smoke test checked a nav page, not a real article, and reported a pass. Make the AI name the exact page it tested. 4. Half-rethemed output. Search for your old brand name yourself. It takes ten seconds. The blog this pack came from is also available as a from-scratch prompt: [add a blog and admin content system](https://mcafax.com/notebook/prompts/free-prompt-add-a-blog-admin-content-system-to-your-business-website). ## Questions readers ask **What is an AI build pack?** One Markdown file: install instructions on top, verbatim source files below. **How do I keep API keys out of it?** Tell the AI what must never leave before it starts (question 3 in the prompt). Then search the finished file yourself.