Your repo already knows your product — let your AI marketing read it

AI marketing copy fails for a boring reason: the writer does not know the product. Not "does not know it well" — has never encountered it. Given your product name and a sentence-shaped hole where a specific belongs, a language model fills the hole with the average of every product that has ever had a name like yours. Fluent, confident, and about a feature you never built.

The usual fix is to type a product description into a settings box. That helps, and it is also the least reliable document in your project, because you write it once, when you are impatient, from memory.

Meanwhile there is a document in your project that is exhaustive, current, and cannot lie about what is implemented, because it is what is implemented. It is your repository.

So IndieBob does not try to read your repo. It gives you a prompt to run inside it, with the AI assistant you already have open there.

Why a prompt and not an integration

An integration would need a token with read access to your source code, on our server, forever. For a one-person product whose only asset is trust, that is an expensive thing to ask for and an expensive thing to hold.

The prompt costs nothing to grant. You paste it into Claude Code, Cursor, Copilot — whatever is already sitting in that repo with the context loaded — and it emits three blocks you paste back. Your code never leaves your machine. The thing that leaves is a page of prose about your product, which you read before it goes anywhere.

It is also a better read than an integration would be. The assistant in your repo already has the working set: which routes exist, which handler is a stub, what the settings screen actually exposes. A scraper would get the README, which is exactly the document we are trying not to trust.

What the prompt asks for

Three fenced blocks, and the shape of them is dictated by what IndieBob actually reads, not by taste.

A facts sheet in free markdown — nothing parses it, it is pasted verbatim into every content prompt — under conventional headings: what it is, who it is for, features, what it does NOT do, pricing, platforms and requirements, numbers that may be cited. Under 4,000 characters, because that is where the corpus slicer cuts each source before it reaches a prompt. Most important facts first is not a style note; past that cut, the model has never seen it.

An audience paragraph and a tone paragraph, each under 600 characters. These are stored as their own rows and emitted as their own lines, so they never spend the sheet's character budget. Describing your reader does not cost you a feature.

The instructions that do the real work are the negative ones:

HOW TO RESEARCH IT
Work from the code, not from the marketing copy or from what the project name
suggests. In particular:
- Read the README, the package manifest, and any docs/ directory.
- Derive the FEATURE LIST from what is actually implemented — routes,
  commands, exported API, UI pages, settings screens. A feature branch, a TODO,
  a stubbed handler or a commented-out block is NOT a feature.
- Look for pricing in the code: plan definitions, Stripe price IDs, a pricing
  page, a limits/quota table. If pricing exists only in a README claim, say so.
- Note the platform and runtime requirements the code actually imposes.
- If the repo states an audience or a voice (README intro, docs tone,
  CONTRIBUTING, landing copy), use it. Do not invent a persona.

RULES — these override any instinct to write good marketing copy
1. Every line must be traceable to something you read in this repo.
2. Never invent statistics, benchmarks, customer counts, testimonials, awards
   or integrations. If you did not read a number, no number appears.
3. Where you are unsure, write the line anyway and append
   [VERIFY: what needs checking] — do not guess, and do not silently drop it.
4. Write what the product does NOT do. This section is what stops the AI
   inventing features later, so it is the most valuable part of the sheet.
5. Plain declarative sentences. No adjectives that cannot be checked
   ("blazing fast", "powerful", "seamless"). No first person plural.
6. Do not describe the codebase — describe the product a user gets. Internal
   architecture belongs in the sheet only when a user can observe it
   (e.g. "runs entirely offline", "data stays on your machine").

Rule 3 is the one I would defend hardest. Confabulation is what a generator does when it has no legal way to output "I don't know". Give it one — a marker, on its own line, that survives into the sheet — and not-knowing becomes a visible, greppable result instead of a confident sentence. A facts sheet that comes back with four [VERIFY] lines has just told you the four things about your own product that your repo does not actually establish.

Rule 4 is the one people skip and should not. The "what it does NOT do" section is what stops a blog draft in three weeks from inventing an integration. It is the cheapest insurance in the whole system.

The test case is a repo that lies

The prompt is exercised against a fixture repository built to contain the four traps it has to survive, because a prompt that only works on honest repos is not worth shipping.

The fixture is a browser tab manager. Its README opens:

The last tab manager you will ever need. Blazing fast, AI-powered, and trusted by thousands of developers worldwide.

Every one of those claims is a trap:

"AI-powered" is the good one. The grouping function is nine lines, and the comment directly above it says so outright: group by registrable domain — this is the whole "AI" in the README. It strips a leading www. off the hostname and buckets by what is left. An assistant that skims the README ships "AI-powered tab grouping" into your marketing copy, and you will not notice until a user does.

"Trusted by thousands of developers" has nothing behind it anywhere in the repo. Under rule 2, no number that was not read appears — so it simply does not survive into the sheet.

The roadmap sits directly under the install instructions: cloud sync, a mobile companion app, team-shared tab groups. Prose, no code. A correct run puts those in "what it does NOT do", which is the difference between a sheet that protects you and one that sets you up.

A stubbed export function throws not implemented behind a TODO comment, and there is a TODO-gated feature flag beside it. Both read as features if you skim. Neither is one.

And then the facts the repo genuinely does establish, which are the ones you actually want in your marketing: a real plan table — free capped at five groups, pro at $4 a month, unlimited — a real processing limit of 500 tabs scanned per run, and a manifest that requests exactly three permissions and no host permissions at all. That last one is the kind of fact only the code can give you, and it is a better selling point than anything in the README: the extension cannot read the contents of your pages, and you can prove it.

The bar the fixture sets is that a correct run keeps the fourth category, demotes the first two, and never lists the third as a feature.

Fifteen minutes, once

Open a project in IndieBob and go to its connect page. It gives you the prompt with your project's name and domain already filled in, tells you where to paste each of the three blocks back, and shows a worked example of a finished sheet so you know what good looks like before you start.

The whole thing is one assistant session in a repo you already have open. What you get for it is that every blog draft, social post, meta description and email IndieBob writes for you afterwards is drawing on what your product actually does — and has somewhere honest to put the things it does not know.

Your repo already knows your product. This is just the part where you let the marketing read it.