app-rebuild-kit

Hamza Khalid's Rebuild Kit for recreating an app's behavior with Claude, clean-room: 7 prompts (behavior spec, build, parity test, map the app, trace a flow, clean spec, build), 10 ready blueprints for small creator tools, house rules for looking inside apps you own, Agent Team prompts and a clean-room checklist. Use when the user wants to rebuild or clone how an app works, write a behavior spec, or build one of the blueprint tools.

SKILL.md

# The Rebuild Kit
Paid member gift from AI In Public. This page goes with the issue "I Tested the Viral GitHub Repo That Reverse Engineers Anything." Duplicate it into your own Notion workspace before you start.

---

> 💡

### What This Is

Everything you need to run the issue's method from start to finish: the 7 prompts for each step, 10 finished blueprints you can build tonight, the house-rules file for looking inside apps you own, the Agent Team prompts for bigger apps, and a clean-room checklist.

> 💡

### Why I Built This

The issue teaches the method. The method only pays off once you've rebuilt your first tool and cancelled your first subscription. This page removes every blank-page moment between reading and doing.

> 💡

### Before You Start

Know your door.
Watch From Outside: every app you only pay for. Needs only claude.ai.
Look Inside: apps you own, built, or that are open-source. Needs Claude Code and REA, Mac or Linux.
If you're unsure which door an app belongs to, watch it from outside.

☐ I have a Claude account with Opus 5.5 selected
☐ I've picked one feature, not a whole app
☐ I know which door I'm using

> 💡

### What's Inside

1. The 7 Prompts
1. 10 Rebuild Blueprints
1. Extended House Rules (Look Inside)
1. Agent Team Prompts
1. Clean-Room Checklist

> 💡

### Who This Is For

Solopreneurs, creators, and freelancers who pay monthly for tools they use one feature of, or who own a tool nobody can explain anymore. No coding background needed to watch from outside.

> 💡

### How to Use It

Fastest path: skip to Part 2, pick a blueprint, paste it into Prompt 2, and test it with Prompt 3. You'll have a working tool in under 30 minutes. Use Prompt 1 later, when you want to rebuild a feature that isn't in the blueprints.

---

## Part 1: The 7 Prompts

> 💡

### Prompt 1: The Behavior Spec

Use at: Step 2, Write the spec. Swap the second sentence for your own one-line description of the feature.

```text
Here is a feature from a paid app, described in one sentence. The feature takes one image and resizes it for Instagram, Stories, a YouTube thumbnail, X and LinkedIn, so every size can be downloaded in one click.

Write a behavior spec so someone who has never seen this app could build the same feature.

Describe only what the feature does. Never guess at how the app's code works.

Include:
1. What goes in: file types, sizes, and every setting.
2. What comes out: files, names, sizes, and order.
3. What each setting changes.
4. What happens with odd inputs: a tiny image, a huge image, the wrong file type.
5. Ten test cases written as "input → expected output".

Leave out the app's name, logo, colors, icons, and exact wording.
Mark anything you are guessing as GUESS.
```

The key line is "Describe only what the feature does." It keeps the original's code out of your spec, which keeps your rebuild yours.

> 💡

### Prompt 2: The Build

Use at: Step 3, Open a fresh chat and build. Always in a fresh chat that has never seen the original's screenshots. Paste your spec or a blueprint from Part 2 directly under the word SPEC.

```text
Build the tool described in the spec below as a single-page artifact.

I am not a developer. It must work by drag and drop in the browser with no install.
Use your own simple, clean design. Do not imitate any existing brand.
Follow the spec exactly. If something in the spec is unclear, make the simplest choice and tell me what you chose.

When you're done, list which of the test cases you expect to pass and which might not.

SPEC:
```

> 💡

### Prompt 3: The Parity Test

Use at: Step 4, Test, fix, keep. Run the same 3 inputs through the original and your version, then paste both results below the prompt.

```text
I ran the same 3 inputs through the original app and through my rebuild. Below are both results for each input.

For each input, tell me: Match, Small difference, or Broken.
Then give me the top 3 fixes in order of importance, written as instructions I can paste straight back into my build chat.
```

The key line is "instructions I can paste straight back." You get fixes you can use immediately instead of feedback you have to translate.

> 💡

### Prompt 4: Map the App

Use at: Looking inside an app you own (first). Run this in Claude Code with REA connected, not in a regular Claude chat. Only for apps you own or open-source apps. This example uses Flameshot, a free open-source screenshot and editing app. Install it first with: brew install --cask flameshot (or download it from flameshot.org). If your app lives somewhere else, drag it into the Claude Code window and swap in that path.

```text
I want to rebuild the core features of Flameshot, a free, open-source screenshot app (GPL-3.0). It is installed at /Applications/flameshot.app

Use REA to open it. Do not start deep analysis yet.

Give me:
1. What kind of app this is (native, Electron, .NET, or other), what it is built with, and which REA tool you used.
2. How big it is: number of functions, main parts.
3. Every user-facing feature you can find from the readable text inside the app: button labels, tool names, menu items, settings, keyboard shortcuts, error messages.
4. Where you would look first to understand the capture, edit and save flow.

Write it in plain English for a non-developer.
Label every point SAW IT, GUESSING or DON'T KNOW, and show the evidence for SAW IT.
Keep it under 300 words.
```

> 💡

### Prompt 5: Trace the Capture, Edit and Save Flow

Use at: Looking inside an app you own (second). Same Claude Code window as Prompt 4.

```text
Now trace the main flow from start to finish:

1. Capture: how the user starts a screenshot and selects an area.
2. Edit: every editing tool (for example arrow, rectangle, text, pen, marker, blur or pixelate). For each tool, tell me what it does, what the user can change (color, thickness, size) and its shortcut key.
3. Undo and redo: how they work.
4. Output: every way to finish (save to file, copy to clipboard, pin, cancel), the file format, and the default file name.

Use the readable text in the app first, then the most-called functions to confirm.
Explain it like I run a small business, not like I'm an engineer.
Label every claim SAW IT, GUESSING or DON'T KNOW, with evidence.
Stop when the flow is covered. Do not analyze anything else.
```

> 💡

### Prompt 6: Write the Clean Spec

Use at: Looking inside an app you own (third). Same Claude Code window. Copy the spec it writes. Flameshot is GPL-licensed, so this spec must describe behavior only. That keeps your rebuild your own code.

```text
From everything you found, write a behavior spec for a new, original screenshot tool called SnapKit.

Describe behavior only:
- Capture: how the user starts, selects an area, and cancels.
- Edit tools: arrow, rectangle, text, pen, highlighter and blur. For each, what it does and what the user can adjust.
- Undo and redo.
- Output: save as PNG, copy to clipboard, and the file naming pattern.
- Keyboard shortcuts.
- Error cases: permission denied, empty selection, cancelled capture.
- Ten test cases written as "input → expected output".

Do not include code, function names, file names, addresses, icons, or wording copied from Flameshot. Use your own names for every tool and setting.
Someone who has never seen Flameshot must be able to build SnapKit from this spec alone.
Save it as SNAPKIT-SPEC.md in this folder, then show it to me.
```

> 💡

### Prompt 7: Build SnapKit

Use at: Looking inside an app you own (fourth). Start a fresh Claude Code session in a new, empty folder so the builder never sees the Flameshot analysis. Copy SNAPKIT-SPEC.md into that folder first.

```text
Read SNAPKIT-SPEC.md in this folder and build SnapKit exactly as described.

Rules:
- One HTML file called snapkit.html that opens in Chrome by double-clicking. No install.
- Capture: use the browser's screen capture so I can pick a screen or window, then let me drag to select an area. Also let me paste a screenshot from my clipboard (Cmd+V) as a second way in.
- Use your own clean, simple design. Do not imitate any existing app.
- Build version 1 only. No extra features.

When it is done:
1. Open it and run every test case in the spec. Report each as Pass or Fail.
2. Fix anything that fails, then report again.
3. Tell me in plain English how to use it, in five short steps.
```

---

> 💡

## Part 2: 10 Rebuild Blueprints

Each blueprint is a finished spec. Copy the whole block, paste it under SPEC in Prompt 2, and send. Platform sizes are common defaults, so check them against the platform's current guidelines and change any number before you build.

### Blueprint 1: Carousel Splitter

```text
TOOL: Carousel splitter

INPUT: One image (PNG or JPG), dragged onto the page.
SETTINGS:
- Slide size: 1080x1350 (default), 1080x1080, or custom width and height.
- Slide numbers: on or off. When on, show "1/N" in the bottom right corner, 40px from each edge, white text with a soft dark shadow.
- Fit mode: "Cut to height" (default) or "Equal slices".
OUTPUT:
- Cut to height: scale the image to the slide width, then cut top to bottom into slides of the slide height. Pad the last slide with white if it's short.
- Equal slices: user picks 2 to 20 slides; image is scaled and split into that many equal slides.
- Show a preview strip of all slides. A "Download all" button saves a ZIP of PNGs named slide-01.png, slide-02.png, and so on.
EDGE CASES:
- Image shorter than one slide: produce one slide, centered, with white padding.
- Wrong file type: show "Please drop a PNG or JPG."
TESTS:
1. 1080x4050 image, default settings → 3 slides, no padding.
2. 1080x3000 image, default → 3 slides, last one padded at the bottom.
3. 800x2000 image → scaled to 1080 wide first, then cut.
4. Slide numbers on, 4 slides → "1/4" to "4/4" in the bottom right.
5. A PDF dropped in → error message, no crash.
```

### Blueprint 2: Link-in-Bio Page Builder

```text
TOOL: Link-in-bio page builder

INPUT: A form with name, one-line bio, an optional profile photo (upload), and up to 12 links (label + URL).
SETTINGS:
- Theme: light, dark, or warm.
- Button style: rounded or square.
- Drag to reorder links.
OUTPUT:
- A live mobile-width preview on the right that updates as you type.
- An "Export" button that downloads a single self-contained HTML file of the finished page, ready to host anywhere.
EDGE CASES:
- URL without https:// → add it automatically.
- Empty label → use the URL as the label.
- More than 12 links → disable the "Add link" button and say why.
TESTS:
1. Name, bio, 3 links → preview shows all 3 buttons in order.
2. Drag link 3 to the top → preview and export both update.
3. "example.com" entered → saved as "https://example.com".
4. Dark theme → exported file opens in dark theme.
5. Export and open the file with no internet → it still renders.
```

### Blueprint 3: Caption Formatter

```text
TOOL: Multi-platform caption formatter

INPUT: One block of pasted text.
SETTINGS:
- Platform: LinkedIn, X, Instagram, Threads.
- Character limit per platform, editable, with defaults: LinkedIn 3000, X 280, Instagram 2200, Threads 500.
- Line spacing: keep as is, or add an empty line between paragraphs.
- Hashtags: move all hashtags to the end, or remove them.
OUTPUT:
- A formatted caption with a live character count, which turns red when over the limit.
- For X, if over 280, split into a numbered thread (1/, 2/, ...) without breaking words.
- A "Copy" button.
EDGE CASES:
- Emojis count as 2 characters on X.
- Empty input → disable "Copy".
TESTS:
1. 500-character text, X → thread of 2 or 3 posts, no broken words.
2. Text with 5 hashtags inline, "move to end" → hashtags appear at the end only.
3. Three paragraphs, "add empty line" → one blank line between each.
4. 3,100 characters, LinkedIn → count shows red.
5. Copy → clipboard matches the preview exactly.
```

### Blueprint 4: Thumbnail Safe-Zone Checker

```text
TOOL: YouTube thumbnail safe-zone checker

INPUT: One image (PNG or JPG).
SETTINGS:
- Overlay toggles: timestamp box (bottom right), small-size preview, grayscale check.
OUTPUT:
- The thumbnail shown at 1280x720 with a translucent box over the bottom-right corner, roughly where YouTube's video length label sits.
- A row of previews at three smaller sizes so the user can check readability on mobile.
- A grayscale version to check contrast.
- A warning if the image is not 16:9.
EDGE CASES:
- Image smaller than 1280x720 → show it, with a warning that it may look blurry.
- Wrong file type → "Please drop a PNG or JPG."
TESTS:
1. 1280x720 image → no warnings, overlay visible.
2. 1080x1080 image → "not 16:9" warning.
3. 640x360 image → blur warning.
4. Grayscale toggle → grayscale preview appears.
5. Toggle overlay off → box disappears.
```

### Blueprint 5: Multi-Platform Image Resizer

```text
TOOL: One image, every platform size

INPUT: One image.
SETTINGS:
- Tick which sizes to export. Editable defaults: Instagram portrait 1080x1350, Instagram square 1080x1080, Story 1080x1920, YouTube thumbnail 1280x720, X post 1600x900, LinkedIn post 1200x627.
- Fit mode: crop to fill (default) or fit with background color.
- Background color picker for fit mode.
- Drag the crop area on each preview to choose what stays in frame.
OUTPUT:
- One preview per ticked size.
- "Download all" → ZIP of PNGs named by platform and size.
EDGE CASES:
- No sizes ticked → disable download.
- Very small source image → warn that outputs may be blurry.
TESTS:
1. 3000x2000 photo, all sizes → 6 files with exact dimensions.
2. Fit mode with black background → bars are black, nothing cropped.
3. Move the crop on the square preview → only that export changes.
4. Untick everything → download disabled.
5. File names include platform and size.
```

### Blueprint 6: YouTube Chapters Formatter

```text
TOOL: Chapter list formatter

INPUT: Pasted lines in any rough format, like "0:00 intro", "2.15 - setup", "1:02:30 Q and A".
OUTPUT:
- A clean chapter list, one per line: "00:00 Intro", "02:15 Setup", "1:02:30 Q and A".
- Titles start with a capital letter.
- A "Copy" button.
CHECKS (shown as warnings, not blockers):
- First chapter must be 00:00.
- At least 3 chapters.
- Each chapter at least 10 seconds after the previous one.
- Timestamps in increasing order.
EDGE CASES:
- Line with no timestamp → flag the line and skip it.
- Mixed separators (dot, colon, dash) → normalize all of them.
TESTS:
1. "0:00 intro / 2.15 setup / 5:40 demo" → three clean lines.
2. First chapter at 0:05 → warning about 00:00.
3. Two chapters 4 seconds apart → warning.
4. Over an hour → hours shown as 1:02:30.
5. Line "thanks for watching" with no time → flagged and skipped.
```

### Blueprint 7: Simple Invoice Generator

```text
TOOL: One-page invoice generator

INPUT: A form with my business name and details, client name and details, invoice number, date, due date, currency, line items (description, quantity, rate), optional tax percentage, and payment notes.
OUTPUT:
- Live invoice preview with automatic line totals, subtotal, tax, and grand total, rounded to 2 decimals.
- "Download PDF" through the browser's print dialog, with the page styled for A4 and Letter.
- Auto-suggest the next invoice number (INV-001 → INV-002).
EDGE CASES:
- Empty line item → ignored in totals.
- Quantity or rate that isn't a number → field turns red.
TESTS:
1. 2 items: 3 x 100 and 1 x 250 → subtotal 550.
2. 10% tax → total 605.
3. Currency set to EUR → every amount shows €.
4. Rate "abc" → red field, totals unchanged.
5. Print → fits on one page with no cut-off text.
```

### Blueprint 8: Content Calendar Board

```text
TOOL: Weekly content calendar

INPUT: Cards with title, platform, status (Idea, Drafting, Scheduled, Posted), date, and notes.
OUTPUT:
- A board with 7 day columns for the current week, plus an "Unscheduled" column.
- Drag cards between days. Color by platform.
- Previous and next week buttons.
- Export the week as CSV.
- Cards are saved in the browser so they're still there after a refresh.
EDGE CASES:
- Card with no date → "Unscheduled" column.
- Delete asks for confirmation.
TESTS:
1. Add 3 cards → each lands on its date.
2. Drag Monday's card to Thursday → date updates.
3. Refresh the page → cards are still there.
4. Next week → empty columns, and the cards come back on the way back.
5. Export → CSV has one row per card.
```

### Blueprint 9: UTM Link Builder

```text
TOOL: Tracked link builder

INPUT: Base URL, source, medium, campaign, optional content and term.
SETTINGS:
- Saved presets, for example "newsletter / email / weekly-issue".
- Lowercase everything (default on). Replace spaces with dashes (default on).
OUTPUT:
- The full tracked URL, live as you type, with a "Copy" button.
- A history list of the last 20 links built, saved in the browser.
EDGE CASES:
- Base URL already has a "?" → add parameters with "&".
- Missing source, medium or campaign → disable "Copy" and say which is missing.
TESTS:
1. example.com + newsletter/email/october → https://example.com?utm_source=newsletter&utm_medium=email&utm_campaign=october
2. URL with "?ref=1" → parameters added with "&".
3. Campaign "Black Friday" → "black-friday".
4. Missing medium → "Copy" disabled with a message.
5. Refresh → history is still there.
```

### Blueprint 10: Post Preview and "See More" Checker

```text
TOOL: Post preview checker

INPUT: Pasted post text.
SETTINGS:
- Platform: LinkedIn or X.
- Cut-off point in characters, editable (start with 210 for LinkedIn and adjust it to what you see on your own feed).
- Device: desktop or mobile width.
OUTPUT:
- A mock post card showing exactly what appears before the "...see more" cut.
- The text after the cut shown faded underneath.
- Live character count and word count.
- A note if the first line is longer than 80 characters.
EDGE CASES:
- Text shorter than the cut-off → no "see more" shown.
- Line breaks count toward the cut.
TESTS:
1. 400-character post, cut at 210 → first 210 shown, rest faded.
2. 150-character post → full post, no "see more".
3. Change cut-off to 150 → preview updates live.
4. Mobile width → card narrows, text wraps.
5. 95-character first line → note appears.
```

---

> 💡

## Part 3: Extended House Rules (Look Inside)

Save this as CLAUDE.md inside your rebuild-lab folder. Use it when looking inside an app you own.

```text
# Reverse engineering house rules

## Permission
- Only analyze apps I own, built, or that are open-source. If you are unsure, stop and ask me.
- Never help bypass a license, a login, a paywall, or copy protection.

## Honesty
- Label every claim as SAW IT, GUESSING, or DON'T KNOW.
- Show the evidence for each claim: the text, location, or behavior you found.
- Keep what you saw in the file separate from what would happen when the app runs. Never claim something runs a certain way just from reading it.

## Working style
- Start with the smallest overview. Never dump the whole app.
- Go deeper only when I ask a specific question.
- Reuse the session that's already open. Never repeat an analysis you've already done.
- Work on the most-used parts of the app first.
- If code looks deliberately scrambled, stop and tell me. Do not keep grinding.

## Rebuilding
- Specs describe behavior only: what goes in, what comes out, settings, errors.
- Never copy code, icons, fonts, text, sounds or other assets into anything we build.
- Every behavior in the spec needs a test case before we call it done.

## Communication
- Explain everything in plain English for a small business owner.
- End each answer with one suggested next question.
```

---

> 💡

## Part 4: Agent Team Prompts

For apps too big for one chat. One chat (the coordinator) splits the work and keeps names consistent. Several other chats (the workers) each handle one piece. Only use this on apps you own.

### The Coordinator

```text
You are the coordinator for analyzing an app I own. I will give you the app's map from REA.

1. Group the app's functions into clusters of related work, and order the clusters starting with the ones used most.
2. Write a short brief for each cluster that I will hand to a separate worker chat. Never analyze a function yourself.
3. Keep a running glossary of every name already decided (data types, features, settings) and include it in every brief, so all workers use the same names.
4. When a worker reports confidence below 6 out of 10, write a second brief for that piece with context from the pieces around it.
5. After each cluster, give me a one-paragraph plain-English summary of what we now know.
```

### The Worker

```text
You are a worker. You get one function from an app I own, plus the glossary of names decided so far.

Return exactly:
- What it does, in one plain-English sentence.
- Confidence from 1 to 10.
- Names from the glossary that it uses.
- Any new names you had to create.
- Anything that looks wrong, risky, or missing.

Always reuse glossary names. Never invent a second name for something already named. Handle this one function only, then stop.
```

---

> 💡

## Part 5: Clean-Room Checklist

Run this before you share, publish, or sell anything you rebuilt. If any box stays unticked, fix it first. This checklist is not legal advice. If you plan to sell, read the original tool's terms and talk to a lawyer.

☐ I only watched the paid app from outside (screenshots of its own window, its visible behavior). I never opened its code.
☐ The build chat never saw the original's screenshots. It only saw my written spec.
☐ My tool's name is my own, not a play on the original's name.
☐ No logos, icons, fonts, colors, sounds, templates or wording copied from the original.
☐ Any icons or fonts I used are my own, free to use, or openly licensed, and I've noted where each came from.
☐ Any file formats my tool reads or writes come from public standards, not from another app's code.
☐ If I looked inside: the app is mine, built for me with rights transferred, or open-source, and I've followed its license.
☐ I've run the parity test and fixed everything marked Broken.

---

> 💡

### Your Next Step

Tonight: pick one blueprint, paste it into Prompt 2, test it with Prompt 3, and publish it. Then reply to the newsletter and tell me which subscription you cancelled.

We tested it in public. Now go use it in private.

**Make Yourself Irreplaceable with AI. LLMs don't think; you do.**

1 file

SKILL.md23.0 KB

--- name: app-rebuild-kit description: "Hamza Khalid's Rebuild Kit for recreating an app's behavior with Claude, clean-room: 7 prompts (behavior spec, build, parity test, map the app, trace a flow, clean spec, build), 10 ready blueprints for small creator tools, house rules for looking inside apps you own, Agent Team prompts and a clean-room checklist. Use when the user wants to rebuild or clone how an app works, write a behavior spec, or build one of the blueprint tools." metadata: author: "Hamza Khalid" source: "https://smart-scabiosa-77d.notion.site/The-Rebuild-Kit-3f9816ad5f7180df967ed97a83a0994c" newsletter: "https://www.aiinpublic.com" title: "The Rebuild Kit" post: "https://www.aiinpublic.com/p/how-to-build-your-own-app-using-rea" note: "Copied from the creator's free page. Removed only page furniture: image placeholders, empty callouts, coffee/share call-outs, lines pointing at embedded posts that did not carry over, and the closing PS." --- # The Rebuild Kit Paid member gift from AI In Public. This page goes with the issue "I Tested the Viral GitHub Repo That Reverse Engineers Anything." Duplicate it into your own Notion workspace before you start. --- > 💡 ### What This Is Everything you need to run the issue's method from start to finish: the 7 prompts for each step, 10 finished blueprints you can build tonight, the house-rules file for looking inside apps you own, the Agent Team prompts for bigger apps, and a clean-room checklist. > 💡 ### Why I Built This The issue teaches the method. The method only pays off once you've rebuilt your first tool and cancelled your first subscription. This page removes every blank-page moment between reading and doing. > 💡 ### Before You Start Know your door. Watch From Outside: every app you only pay for. Needs only claude.ai. Look Inside: apps you own, built, or that are open-source. Needs Claude Code and REA, Mac or Linux. If you're unsure which door an app belongs to, watch it from outside. ☐ I have a Claude account with Opus 5.5 selected ☐ I've picked one feature, not a whole app ☐ I know which door I'm using > 💡 ### What's Inside 1. The 7 Prompts 1. 10 Rebuild Blueprints 1. Extended House Rules (Look Inside) 1. Agent Team Prompts 1. Clean-Room Checklist > 💡 ### Who This Is For Solopreneurs, creators, and freelancers who pay monthly for tools they use one feature of, or who own a tool nobody can explain anymore. No coding background needed to watch from outside. > 💡 ### How to Use It Fastest path: skip to Part 2, pick a blueprint, paste it into Prompt 2, and test it with Prompt 3. You'll have a working tool in under 30 minutes. Use Prompt 1 later, when you want to rebuild a feature that isn't in the blueprints. --- ## Part 1: The 7 Prompts > 💡 ### Prompt 1: The Behavior Spec Use at: Step 2, Write the spec. Swap the second sentence for your own one-line description of the feature. ```text Here is a feature from a paid app, described in one sentence. The feature takes one image and resizes it for Instagram, Stories, a YouTube thumbnail, X and LinkedIn, so every size can be downloaded in one click. Write a behavior spec so someone who has never seen this app could build the same feature. Describe only what the feature does. Never guess at how the app's code works. Include: 1. What goes in: file types, sizes, and every setting. 2. What comes out: files, names, sizes, and order. 3. What each setting changes. 4. What happens with odd inputs: a tiny image, a huge image, the wrong file type. 5. Ten test cases written as "input → expected output". Leave out the app's name, logo, colors, icons, and exact wording. Mark anything you are guessing as GUESS. ``` The key line is "Describe only what the feature does." It keeps the original's code out of your spec, which keeps your rebuild yours. > 💡 ### Prompt 2: The Build Use at: Step 3, Open a fresh chat and build. Always in a fresh chat that has never seen the original's screenshots. Paste your spec or a blueprint from Part 2 directly under the word SPEC. ```text Build the tool described in the spec below as a single-page artifact. I am not a developer. It must work by drag and drop in the browser with no install. Use your own simple, clean design. Do not imitate any existing brand. Follow the spec exactly. If something in the spec is unclear, make the simplest choice and tell me what you chose. When you're done, list which of the test cases you expect to pass and which might not. SPEC: ``` > 💡 ### Prompt 3: The Parity Test Use at: Step 4, Test, fix, keep. Run the same 3 inputs through the original and your version, then paste both results below the prompt. ```text I ran the same 3 inputs through the original app and through my rebuild. Below are both results for each input. For each input, tell me: Match, Small difference, or Broken. Then give me the top 3 fixes in order of importance, written as instructions I can paste straight back into my build chat. ``` The key line is "instructions I can paste straight back." You get fixes you can use immediately instead of feedback you have to translate. > 💡 ### Prompt 4: Map the App Use at: Looking inside an app you own (first). Run this in Claude Code with REA connected, not in a regular Claude chat. Only for apps you own or open-source apps. This example uses Flameshot, a free open-source screenshot and editing app. Install it first with: brew install --cask flameshot (or download it from flameshot.org). If your app lives somewhere else, drag it into the Claude Code window and swap in that path. ```text I want to rebuild the core features of Flameshot, a free, open-source screenshot app (GPL-3.0). It is installed at /Applications/flameshot.app Use REA to open it. Do not start deep analysis yet. Give me: 1. What kind of app this is (native, Electron, .NET, or other), what it is built with, and which REA tool you used. 2. How big it is: number of functions, main parts. 3. Every user-facing feature you can find from the readable text inside the app: button labels, tool names, menu items, settings, keyboard shortcuts, error messages. 4. Where you would look first to understand the capture, edit and save flow. Write it in plain English for a non-developer. Label every point SAW IT, GUESSING or DON'T KNOW, and show the evidence for SAW IT. Keep it under 300 words. ``` > 💡 ### Prompt 5: Trace the Capture, Edit and Save Flow Use at: Looking inside an app you own (second). Same Claude Code window as Prompt 4. ```text Now trace the main flow from start to finish: 1. Capture: how the user starts a screenshot and selects an area. 2. Edit: every editing tool (for example arrow, rectangle, text, pen, marker, blur or pixelate). For each tool, tell me what it does, what the user can change (color, thickness, size) and its shortcut key. 3. Undo and redo: how they work. 4. Output: every way to finish (save to file, copy to clipboard, pin, cancel), the file format, and the default file name. Use the readable text in the app first, then the most-called functions to confirm. Explain it like I run a small business, not like I'm an engineer. Label every claim SAW IT, GUESSING or DON'T KNOW, with evidence. Stop when the flow is covered. Do not analyze anything else. ``` > 💡 ### Prompt 6: Write the Clean Spec Use at: Looking inside an app you own (third). Same Claude Code window. Copy the spec it writes. Flameshot is GPL-licensed, so this spec must describe behavior only. That keeps your rebuild your own code. ```text From everything you found, write a behavior spec for a new, original screenshot tool called SnapKit. Describe behavior only: - Capture: how the user starts, selects an area, and cancels. - Edit tools: arrow, rectangle, text, pen, highlighter and blur. For each, what it does and what the user can adjust. - Undo and redo. - Output: save as PNG, copy to clipboard, and the file naming pattern. - Keyboard shortcuts. - Error cases: permission denied, empty selection, cancelled capture. - Ten test cases written as "input → expected output". Do not include code, function names, file names, addresses, icons, or wording copied from Flameshot. Use your own names for every tool and setting. Someone who has never seen Flameshot must be able to build SnapKit from this spec alone. Save it as SNAPKIT-SPEC.md in this folder, then show it to me. ``` > 💡 ### Prompt 7: Build SnapKit Use at: Looking inside an app you own (fourth). Start a fresh Claude Code session in a new, empty folder so the builder never sees the Flameshot analysis. Copy SNAPKIT-SPEC.md into that folder first. ```text Read SNAPKIT-SPEC.md in this folder and build SnapKit exactly as described. Rules: - One HTML file called snapkit.html that opens in Chrome by double-clicking. No install. - Capture: use the browser's screen capture so I can pick a screen or window, then let me drag to select an area. Also let me paste a screenshot from my clipboard (Cmd+V) as a second way in. - Use your own clean, simple design. Do not imitate any existing app. - Build version 1 only. No extra features. When it is done: 1. Open it and run every test case in the spec. Report each as Pass or Fail. 2. Fix anything that fails, then report again. 3. Tell me in plain English how to use it, in five short steps. ``` --- > 💡 ## Part 2: 10 Rebuild Blueprints Each blueprint is a finished spec. Copy the whole block, paste it under SPEC in Prompt 2, and send. Platform sizes are common defaults, so check them against the platform's current guidelines and change any number before you build. ### Blueprint 1: Carousel Splitter ```text TOOL: Carousel splitter INPUT: One image (PNG or JPG), dragged onto the page. SETTINGS: - Slide size: 1080x1350 (default), 1080x1080, or custom width and height. - Slide numbers: on or off. When on, show "1/N" in the bottom right corner, 40px from each edge, white text with a soft dark shadow. - Fit mode: "Cut to height" (default) or "Equal slices". OUTPUT: - Cut to height: scale the image to the slide width, then cut top to bottom into slides of the slide height. Pad the last slide with white if it's short. - Equal slices: user picks 2 to 20 slides; image is scaled and split into that many equal slides. - Show a preview strip of all slides. A "Download all" button saves a ZIP of PNGs named slide-01.png, slide-02.png, and so on. EDGE CASES: - Image shorter than one slide: produce one slide, centered, with white padding. - Wrong file type: show "Please drop a PNG or JPG." TESTS: 1. 1080x4050 image, default settings → 3 slides, no padding. 2. 1080x3000 image, default → 3 slides, last one padded at the bottom. 3. 800x2000 image → scaled to 1080 wide first, then cut. 4. Slide numbers on, 4 slides → "1/4" to "4/4" in the bottom right. 5. A PDF dropped in → error message, no crash. ``` ### Blueprint 2: Link-in-Bio Page Builder ```text TOOL: Link-in-bio page builder INPUT: A form with name, one-line bio, an optional profile photo (upload), and up to 12 links (label + URL). SETTINGS: - Theme: light, dark, or warm. - Button style: rounded or square. - Drag to reorder links. OUTPUT: - A live mobile-width preview on the right that updates as you type. - An "Export" button that downloads a single self-contained HTML file of the finished page, ready to host anywhere. EDGE CASES: - URL without https:// → add it automatically. - Empty label → use the URL as the label. - More than 12 links → disable the "Add link" button and say why. TESTS: 1. Name, bio, 3 links → preview shows all 3 buttons in order. 2. Drag link 3 to the top → preview and export both update. 3. "example.com" entered → saved as "https://example.com". 4. Dark theme → exported file opens in dark theme. 5. Export and open the file with no internet → it still renders. ``` ### Blueprint 3: Caption Formatter ```text TOOL: Multi-platform caption formatter INPUT: One block of pasted text. SETTINGS: - Platform: LinkedIn, X, Instagram, Threads. - Character limit per platform, editable, with defaults: LinkedIn 3000, X 280, Instagram 2200, Threads 500. - Line spacing: keep as is, or add an empty line between paragraphs. - Hashtags: move all hashtags to the end, or remove them. OUTPUT: - A formatted caption with a live character count, which turns red when over the limit. - For X, if over 280, split into a numbered thread (1/, 2/, ...) without breaking words. - A "Copy" button. EDGE CASES: - Emojis count as 2 characters on X. - Empty input → disable "Copy". TESTS: 1. 500-character text, X → thread of 2 or 3 posts, no broken words. 2. Text with 5 hashtags inline, "move to end" → hashtags appear at the end only. 3. Three paragraphs, "add empty line" → one blank line between each. 4. 3,100 characters, LinkedIn → count shows red. 5. Copy → clipboard matches the preview exactly. ``` ### Blueprint 4: Thumbnail Safe-Zone Checker ```text TOOL: YouTube thumbnail safe-zone checker INPUT: One image (PNG or JPG). SETTINGS: - Overlay toggles: timestamp box (bottom right), small-size preview, grayscale check. OUTPUT: - The thumbnail shown at 1280x720 with a translucent box over the bottom-right corner, roughly where YouTube's video length label sits. - A row of previews at three smaller sizes so the user can check readability on mobile. - A grayscale version to check contrast. - A warning if the image is not 16:9. EDGE CASES: - Image smaller than 1280x720 → show it, with a warning that it may look blurry. - Wrong file type → "Please drop a PNG or JPG." TESTS: 1. 1280x720 image → no warnings, overlay visible. 2. 1080x1080 image → "not 16:9" warning. 3. 640x360 image → blur warning. 4. Grayscale toggle → grayscale preview appears. 5. Toggle overlay off → box disappears. ``` ### Blueprint 5: Multi-Platform Image Resizer ```text TOOL: One image, every platform size INPUT: One image. SETTINGS: - Tick which sizes to export. Editable defaults: Instagram portrait 1080x1350, Instagram square 1080x1080, Story 1080x1920, YouTube thumbnail 1280x720, X post 1600x900, LinkedIn post 1200x627. - Fit mode: crop to fill (default) or fit with background color. - Background color picker for fit mode. - Drag the crop area on each preview to choose what stays in frame. OUTPUT: - One preview per ticked size. - "Download all" → ZIP of PNGs named by platform and size. EDGE CASES: - No sizes ticked → disable download. - Very small source image → warn that outputs may be blurry. TESTS: 1. 3000x2000 photo, all sizes → 6 files with exact dimensions. 2. Fit mode with black background → bars are black, nothing cropped. 3. Move the crop on the square preview → only that export changes. 4. Untick everything → download disabled. 5. File names include platform and size. ``` ### Blueprint 6: YouTube Chapters Formatter ```text TOOL: Chapter list formatter INPUT: Pasted lines in any rough format, like "0:00 intro", "2.15 - setup", "1:02:30 Q and A". OUTPUT: - A clean chapter list, one per line: "00:00 Intro", "02:15 Setup", "1:02:30 Q and A". - Titles start with a capital letter. - A "Copy" button. CHECKS (shown as warnings, not blockers): - First chapter must be 00:00. - At least 3 chapters. - Each chapter at least 10 seconds after the previous one. - Timestamps in increasing order. EDGE CASES: - Line with no timestamp → flag the line and skip it. - Mixed separators (dot, colon, dash) → normalize all of them. TESTS: 1. "0:00 intro / 2.15 setup / 5:40 demo" → three clean lines. 2. First chapter at 0:05 → warning about 00:00. 3. Two chapters 4 seconds apart → warning. 4. Over an hour → hours shown as 1:02:30. 5. Line "thanks for watching" with no time → flagged and skipped. ``` ### Blueprint 7: Simple Invoice Generator ```text TOOL: One-page invoice generator INPUT: A form with my business name and details, client name and details, invoice number, date, due date, currency, line items (description, quantity, rate), optional tax percentage, and payment notes. OUTPUT: - Live invoice preview with automatic line totals, subtotal, tax, and grand total, rounded to 2 decimals. - "Download PDF" through the browser's print dialog, with the page styled for A4 and Letter. - Auto-suggest the next invoice number (INV-001 → INV-002). EDGE CASES: - Empty line item → ignored in totals. - Quantity or rate that isn't a number → field turns red. TESTS: 1. 2 items: 3 x 100 and 1 x 250 → subtotal 550. 2. 10% tax → total 605. 3. Currency set to EUR → every amount shows €. 4. Rate "abc" → red field, totals unchanged. 5. Print → fits on one page with no cut-off text. ``` ### Blueprint 8: Content Calendar Board ```text TOOL: Weekly content calendar INPUT: Cards with title, platform, status (Idea, Drafting, Scheduled, Posted), date, and notes. OUTPUT: - A board with 7 day columns for the current week, plus an "Unscheduled" column. - Drag cards between days. Color by platform. - Previous and next week buttons. - Export the week as CSV. - Cards are saved in the browser so they're still there after a refresh. EDGE CASES: - Card with no date → "Unscheduled" column. - Delete asks for confirmation. TESTS: 1. Add 3 cards → each lands on its date. 2. Drag Monday's card to Thursday → date updates. 3. Refresh the page → cards are still there. 4. Next week → empty columns, and the cards come back on the way back. 5. Export → CSV has one row per card. ``` ### Blueprint 9: UTM Link Builder ```text TOOL: Tracked link builder INPUT: Base URL, source, medium, campaign, optional content and term. SETTINGS: - Saved presets, for example "newsletter / email / weekly-issue". - Lowercase everything (default on). Replace spaces with dashes (default on). OUTPUT: - The full tracked URL, live as you type, with a "Copy" button. - A history list of the last 20 links built, saved in the browser. EDGE CASES: - Base URL already has a "?" → add parameters with "&". - Missing source, medium or campaign → disable "Copy" and say which is missing. TESTS: 1. example.com + newsletter/email/october → https://example.com?utm_source=newsletter&utm_medium=email&utm_campaign=october 2. URL with "?ref=1" → parameters added with "&". 3. Campaign "Black Friday" → "black-friday". 4. Missing medium → "Copy" disabled with a message. 5. Refresh → history is still there. ``` ### Blueprint 10: Post Preview and "See More" Checker ```text TOOL: Post preview checker INPUT: Pasted post text. SETTINGS: - Platform: LinkedIn or X. - Cut-off point in characters, editable (start with 210 for LinkedIn and adjust it to what you see on your own feed). - Device: desktop or mobile width. OUTPUT: - A mock post card showing exactly what appears before the "...see more" cut. - The text after the cut shown faded underneath. - Live character count and word count. - A note if the first line is longer than 80 characters. EDGE CASES: - Text shorter than the cut-off → no "see more" shown. - Line breaks count toward the cut. TESTS: 1. 400-character post, cut at 210 → first 210 shown, rest faded. 2. 150-character post → full post, no "see more". 3. Change cut-off to 150 → preview updates live. 4. Mobile width → card narrows, text wraps. 5. 95-character first line → note appears. ``` --- > 💡 ## Part 3: Extended House Rules (Look Inside) Save this as CLAUDE.md inside your rebuild-lab folder. Use it when looking inside an app you own. ```text # Reverse engineering house rules ## Permission - Only analyze apps I own, built, or that are open-source. If you are unsure, stop and ask me. - Never help bypass a license, a login, a paywall, or copy protection. ## Honesty - Label every claim as SAW IT, GUESSING, or DON'T KNOW. - Show the evidence for each claim: the text, location, or behavior you found. - Keep what you saw in the file separate from what would happen when the app runs. Never claim something runs a certain way just from reading it. ## Working style - Start with the smallest overview. Never dump the whole app. - Go deeper only when I ask a specific question. - Reuse the session that's already open. Never repeat an analysis you've already done. - Work on the most-used parts of the app first. - If code looks deliberately scrambled, stop and tell me. Do not keep grinding. ## Rebuilding - Specs describe behavior only: what goes in, what comes out, settings, errors. - Never copy code, icons, fonts, text, sounds or other assets into anything we build. - Every behavior in the spec needs a test case before we call it done. ## Communication - Explain everything in plain English for a small business owner. - End each answer with one suggested next question. ``` --- > 💡 ## Part 4: Agent Team Prompts For apps too big for one chat. One chat (the coordinator) splits the work and keeps names consistent. Several other chats (the workers) each handle one piece. Only use this on apps you own. ### The Coordinator ```text You are the coordinator for analyzing an app I own. I will give you the app's map from REA. 1. Group the app's functions into clusters of related work, and order the clusters starting with the ones used most. 2. Write a short brief for each cluster that I will hand to a separate worker chat. Never analyze a function yourself. 3. Keep a running glossary of every name already decided (data types, features, settings) and include it in every brief, so all workers use the same names. 4. When a worker reports confidence below 6 out of 10, write a second brief for that piece with context from the pieces around it. 5. After each cluster, give me a one-paragraph plain-English summary of what we now know. ``` ### The Worker ```text You are a worker. You get one function from an app I own, plus the glossary of names decided so far. Return exactly: - What it does, in one plain-English sentence. - Confidence from 1 to 10. - Names from the glossary that it uses. - Any new names you had to create. - Anything that looks wrong, risky, or missing. Always reuse glossary names. Never invent a second name for something already named. Handle this one function only, then stop. ``` --- > 💡 ## Part 5: Clean-Room Checklist Run this before you share, publish, or sell anything you rebuilt. If any box stays unticked, fix it first. This checklist is not legal advice. If you plan to sell, read the original tool's terms and talk to a lawyer. ☐ I only watched the paid app from outside (screenshots of its own window, its visible behavior). I never opened its code. ☐ The build chat never saw the original's screenshots. It only saw my written spec. ☐ My tool's name is my own, not a play on the original's name. ☐ No logos, icons, fonts, colors, sounds, templates or wording copied from the original. ☐ Any icons or fonts I used are my own, free to use, or openly licensed, and I've noted where each came from. ☐ Any file formats my tool reads or writes come from public standards, not from another app's code. ☐ If I looked inside: the app is mine, built for me with rights transferred, or open-source, and I've followed its license. ☐ I've run the parity test and fixed everything marked Broken. --- > 💡 ### Your Next Step Tonight: pick one blueprint, paste it into Prompt 2, test it with Prompt 3, and publish it. Then reply to the newsletter and tell me which subscription you cancelled. We tested it in public. Now go use it in private. **Make Yourself Irreplaceable with AI. LLMs don't think; you do.**