Ivo Nikolov All free resources

free guide1 page · 4 min read

The own-website check prompt, plus the message to send whoever built your site

REA is a free, open-source add-on (MIT license) that lets Claude look inside apps and websites. Here's how to point it at your own website first, see what any visitor's browser already gets, and pass what you find to the person who built the site. As of October 26, 2026.

Hi, it's Ivo. Most videos about REA point it at someone else's app. I'd start with my own business. Your website sends its code to every visitor's browser, so whatever is in that code, a stranger can read too. REA just makes it fast to see.

Everything below follows REA's own docs.

The one rule first

Only your own website, or one you have written permission to check. That's the project's own rule: REA is for "software you own or are authorized to examine" (README and DISCLAIMER.md on github.com/morluto/rea).

Their disclaimer also says it plainly: "Public availability of software ... does not by itself establish permission." A site being online doesn't mean you may examine it. If an agency built your site and hosts it, ask them before you start. This is not legal advice. When in doubt, don't.

What you need

The own-website check prompt

Open Claude Code in an empty folder and paste this. Put your own address where it says so.

Paste this

Use REA to check my own website: [paste your website address]. I own this site. Start a separate Chrome window with a fresh test profile for this, on a local debugging port only, and close it when you're done. Don't log in, don't fill in forms, and don't send anything. In plain English, list: 1. The page addresses you can find in the site's code, including any that aren't in the menu. 2. The outside tools and services the site loads. 3. The servers and web addresses its code talks to. 4. Whether the site publishes source maps that show the original code. For each item, show the evidence and say how sure you are. Mark anything you're guessing.

Claude will ask before it starts the browser and runs REA's tools. Read each step before you say yes.

What each finding means

  1. Page addresses in the code. REA's docs call these "route candidates". An old offer page or a test page that's no longer in the menu can still be listed here. Not every address is a real, open page.
  2. Outside tools. The docs call these "vendor fingerprints": chat widgets, analytics, payment or booking tools your site loads. It's a good moment to ask if you still use all of them.
  3. Servers it talks to. "Endpoint candidates": the web addresses your site's code calls. Anyone can see these. What matters is that they only answer what they should.
  4. Source maps. These files map the shrunk code a browser gets back to the original code. MDN describes them as "allowing the original code to be reconstructed". If your site publishes them, anyone can read your original code. Many builders turn them off for the live site.

The message to send whoever built your site

Copy, fill in, send:

Paste this

Hi [name], I ran a check on our own website with an AI tool called REA. It listed a few things I'd like you to look at: - Page addresses in the code: [paste] - Outside tools the site loads: [paste] - Servers the site talks to: [paste] - Source maps: [found / not found] Can you tell me which of these should be public, and remove anything that shouldn't? Thanks.

The honest part

As of October 26, 2026, REA has over 380,000 stars on GitHub. Menus, versions and plans change.

Sources: github.com/morluto/rea (README, DISCLAIMER.md, docs/browser-observation.md), read October 26, 2026; developer.mozilla.org (Glossary: Source map).