LaunchRepoThis is the walkthrough I wish I had before my own launch: what actually happens, in order, when you point Claude Code at the LaunchRepo repository and ask it to launch your product on directories. It follows the repository’s own documents — START.md, ONBOARDING.md and BROWSER-SETUP.md — but in plain words, with the parts where you have to act called out. Nothing here is specific to Claude Code that would not also work with Codex or Cursor; the agent pages cover the differences. Claude Code is simply the one I use.
Two expectations to set. First, this is not a one-click launch: the agent does the repetitive work, but you connect the browser, approve the copy, solve CAPTCHAs and confirm what is live. Second, no step below promises a listing — every directory decides for itself what it publishes, and many free tiers take weeks.
Step 0: what you need
- The repository. After purchase you get an invitation to a private GitHub repository. Clone it.
- Python 3.10 or newer on macOS or Linux. The tracker, the dashboard and the helper scripts are plain Python with no dependencies to install.
- Claude Code with a browser integration. A terminal alone cannot fill forms; the repository’s browser setup uses Chrome DevTools MCP, which needs Node.js for
npx. - Chrome 144 or newer, with your Google account and your mailbox signed in — the one you want the directories to know.
- Your product facts: name, URL, a real description, pricing, launch stage, genuine screenshots and a logo. Not marketing wishes; what exists today.
Step 1: the start prompt
Open the cloned folder in Claude Code and paste the prompt from START.md, exactly as written:
Read AGENTS.md, then follow “Start the dashboard for the owner”. Create my private workspace if I do not have one yet, start the dashboard, and give me the link.
The prompt is in English and stays in English; the agent will talk to you in your language once it has read the instructions. What happens next is deterministic: the agent reads AGENTS.md, creates a private workspace next to the checkout — your products and credentials never live in the delivery repository — starts the local dashboard and answers with a 127.0.0.1 link. Open it. Everything from here on can be done in that tab or in the chat; the dashboard forms write the same files the agent reads.
If you prefer to do that step yourself, the repository documents two commands: one initialises the workspace at a destination of your choice, the other starts the dashboard. A --demo flag serves a throwaway sample workspace with a fictional product if you just want to look around first.
Step 2: the onboarding interview
ONBOARDING.md tells the agent to lead your first session one phase at a time and to read existing files before asking anything twice. In practice it feels like an interview.
Where we are. The agent explains what the workspace is and asks for your first product’s name, URL and the local folder with its code or notes. It inspects those sources before asking follow-up questions, and it determines your OS, your agent and which browser tools it can actually call — it is told explicitly not to claim tools the current session does not have.
A private home. The agent helps you create your own private remote for the workspace and explains, plainly, that reusable login details stored there are readable by everyone with access to that repository, including its history. You decide whether credentials go into the workspace, into a secret manager (references only), or nowhere. The workspace file records that choice.
The product. A script creates a product folder from a short slug; then the agent fills product.json from your answers: audience, problem, differentiator, real features, pricing or free trial, launch stage, screenshots and logo. A copy workshop turns that into copy.md with variants for different field limits. Unknowns stay empty — the agent is told not to derive capabilities from competitors or to turn planned features into available ones.
This phase also sets the earliest launch date. Many free-tier directories queue submissions for review; confirmation can take weeks. The agent asks whether there is a date before which nothing should post, writes it into product.json, and the tracker refuses to mark anything scheduled before that date.
Identity. identity.json holds the public name, the email you want directories to use, your nickname and the organisation facts you are willing to publish. A short PR briefing session follows, where you correct how the agent describes you before any of that reaches a public listing.
Step 3: connecting Chrome and your mailbox
This is the step people skip and then wonder why the agent cannot log in. The agent needs a browser you can see and supervise. BROWSER-SETUP.md gives two routes.
Route A: your existing Chrome. Check chrome://version (144+), open chrome://inspect/#remote-debugging in the Chrome you want the agent to use and enable remote debugging there. Then add Chrome DevTools MCP to Claude Code’s MCP configuration with --autoConnect. Trigger a harmless browser action from the agent and approve Chrome’s connection prompt yourself, in the intended window. A running MCP process is not proof of browser access; a visible tab moving is.
Route B: a dedicated profile. Launch Chrome with its own user-data directory inside the workspace and a local remote-debugging port, sign in to the accounts you need in that window, and point the MCP configuration at --browserUrl instead of --autoConnect. Never both at once, never with the port exposed beyond localhost.
On macOS, only grant the Automation, Accessibility or Screen Recording permissions your integration actually requires; a pure DevTools connection usually needs none of them. Chrome’s connection prompt may recur after reconnects — that is a security control, not a bug, and the repository tells the agent not to promise it away.
Then the smoke check: the agent opens a fresh tab, navigates to a public directory homepage, reads its main heading and tells you which tab it used. You watch the same window. Next it signs in to a target directory and checks the account menu for the right identity — completing OAuth is not proof of being logged in on the destination site. Finally it confirms mailbox access, because verification emails are how account registrations get finished. Manual forwarding of codes is a supported fallback; the tracker records it as a human handoff, not as automated access.
Step 4: permissions, once per product
Before anything is submitted, the agent reads WEBSITE-AND-EMAIL.md and asks a handful of questions it will not ask again: where your website code lives, how it deploys, which branch is production, whether it may add required directory badges to the footer and push them, and whether free registrations, free final submissions and the specific verification-email actions are authorised. The answers, the date and the exact scope go into authorizations.json. Spending stays at zero — the agent is told to decline every paid upsell.
Refusing the badge question is fine; it simply rules out the directories that require one. What you should not do is grant one product’s permissions to another. The file is per product on purpose.
Step 5: the first useful result
Now the agent runs doctor.py, which separates missing setup from permissions you declined, and picks three to five directories from the playbook index and the catalog that fit your product — it explains the fit and the prerequisites, and starts with one accessible free route. For each directory the playbook drives the same loop: search for an existing listing first, verify you are on the right site, prepare copy within the field limits, confirm nothing costs money, submit only within your grant, and record the real outcome.
Expect handoffs. A CAPTCHA, a two-factor prompt, an unclear account state or a required badge stops the run: the agent records prepared_needs_human, the dashboard lists the platform under “needs you”, and you finish that step in your own browser. That is by design — the repository forbids evasion or stealth changes.
A good first result is often a submitted review, not a live page. That is normal.
Step 6: what the tracker states mean
Every outcome goes through record.py into submissions.csv, and the dashboard shows the same eleven states. Each is tied to a minimum observation, so a “done” cannot be inflated. In my words:
- draft — the work is prepared, but the final submission was not confirmed.
- prepared_needs_human — something specific blocks it and only you can act: CAPTCHA, 2FA, an unclear account.
- submitted_pending_review — the platform explicitly received the submission and moderation is still pending.
- queued — the platform confirmed a queue position or waiting-list state.
- scheduled — the platform confirmed a launch date on or after your earliest launch date; any outstanding approval stays in the note.
- live — a public listing was verified with no pending label. Needs the public URL and your confirmation.
- already_listed — an existing public listing was found and verified; same URL and attestation requirement as live.
- blocked — eligibility, account capacity or a mandatory missing fact prevents progress.
- deferred_paid — the only usable route requires payment; nothing was bought.
- not_a_fit — the product does not meet the audience or listing criteria.
- unavailable — the route or platform cannot currently be used; the observed problem is noted.
Three consequences follow. A thank-you screen is not live. A partner-distribution checkbox on one site does not count as a second submission until the second platform confirms. And scheduled on a free tier can still take weeks to post. The tracking guide goes into how to keep those apart.
Step 7: leaving a resumable workspace
At the end of a session the agent updates the onboarding checklist only for things it actually observed, writes non-sensitive evidence and open steps to SESSION.md, puts the next dates into FOLLOW-UP.md and runs a git privacy check before pushing to your private remote. The next session — yours or a different agent’s — reads the tracker first, prioritises handoffs and scheduled launches due for verification, then pending submissions whose review window has elapsed. It rechecks existing records instead of submitting again to move up a queue.
That resumability is the whole point. Your second product reuses the browser setup, the identity, the authorisations pattern and the playbooks; only product.json and the copy are new.
Where to go from here
The Claude Code page has the same start prompt, the handoff list and the browser notes on one screen. How it works shows the six steps with the founder video. The directory catalog is where you can read a few public playbooks before deciding, and the pricing page is where the repository is bought, once.
Sources: START.md, ONBOARDING.md, BROWSER-SETUP.md and RUNBOOK.md in the LaunchRepo repository (release notes on the changelog); the start prompt is quoted verbatim from prompts/start.md. No timing or outcome figures are given because none were measured across customers.