FAQ

Straight answers, limits included.

Why is there no CI?

It would be theatre. No GitHub Actions here, none in a generated repo. That is a choice, not an oversight.

The checks are real, and they run on your machine:

• validate checks every manifest, path collision, slot, the template lint and the contribution gate.
• combos generates every single battery and every pair in memory and checks the output.
• matrix installs the stack, each battery, each preset, 10 curated combos and (with --pairs) every pair that can coexist. It typechecks, lints and runs the unit tests in each. With --build it also builds the app and loads every static route.
• matrix --db --browser adds two lanes: a fresh database on local Postgres per combo with the repo's own migrations and seeds, then the repo's own Playwright specs for sign-in, the app shell, checkout and the admin pages.
• snapshot proves the same selection still gives the same bytes.

A hosted runner would run the same commands later, on someone else's machine, and add a queue, a bill and a YAML file that drifts. Want CI in your repo? Add it. We won't ship one you didn't ask for.

How do I get updates? Is there a sync?

No, and there won't be one in V1. Merging upstream changes into a repo you have edited for six months is a merge conflict with extra steps.

Instead, every generated repo has agentic.config.json at the root. It records the exact selection, the plugin list, the counts and a sha256 of the output. Generation is deterministic (no timestamps, no random ids, no absolute paths). So months later you regenerate from that file against a newer registry, diff it against your repo, and take what you want.

That is a weaker promise than "we sync it for you". It is a much better one than a broken merge. It also means a bug report can carry a full reproduction: send the agentic.config.json.

Why only Next.js and Vercel?

Every pick has to work, and we can only promise that for what we actually run. The picker only combines batteries whose pairs are in registry/tested.yaml (a preset's exact set runs whole). Only the matrix writes that file. It adds a pair only after the repo installs, typechecks, lints, passes its unit tests, builds and boots.

A second framework multiplies that matrix. Until the first one is solid, a second would mean a longer feature list and a weaker promise. Other frameworks and a mobile stack are on the roadmap.

What happens to my email address?

The web app asks for an email because that is how this free project pays for itself. Agentic Studio built it. The zip downloads right away. The same link goes to your inbox and works for 7 days.

Here is everything the site keeps and sends:

• The zip isn't saved to a database or a bucket. The link carries your signed picks, and the server rebuilds the zip from them. A built zip can sit in server memory or Vercel's CDN cache until the link expires, 7 days later.
• We store one row per download. It holds your email, your picks, your optional "what are you building?" note and the page you came from. It also holds the link's token, whether you asked for follow-ups, whether you confirmed, when the row was made and when the link was first used.
• We send one email through Resend: the link, the install steps, a pointer to docs/onboard.md and one line of credit. No marketing.
• Follow-ups are double opt-in. The box is unticked by default. Ticking it adds a confirm link to that email, and you are only signed up once you press it. Otherwise you hear from us once, with your link.
• Rate limits store a keyed hash of your IP and your address, never the raw values.
• Your browser remembers your address so the next download is one click. It lives in this browser's local storage, not on our server.
• Site analytics run only when a PostHog key is set. They record page views, clicks (PostHog's autocapture), uncaught errors, and each step of the download flow with what was picked. They never carry your email or your note.

Who owns the code it generates?

You do. The generator and the registry are MIT. The generated repo is yours: no license header in your source, no attribution required, no clause about what you build with it. Ship it commercially, close the source, sell it.

Studio links live in docs, never in your app code:

• README.md and CLAUDE.md: a credit line, plus links to the studio's three paid services (AI Mechanic, Claude Engineering System, AI Product Sprint).
• docs/onboard.md: the credit line.
• The /help skill: the same three services, in each agent target you picked.

They are links in docs, not license terms. Delete them if you want. They stay by default because this is free and those links are how the work pays for itself.

Do I have to use Claude Code?

No. But know what you get with each tool.

• Rules and skills compile for Claude Code, Codex and Cursor.
• Agents and MCP config are written for Claude Code.
• Hooks are wired for Claude Code in .claude/settings.json. The repo writes no Codex or Cursor hook config.

So out of the box, Codex runs none of the guard hooks (the ones that refuse rm -rf, keep secrets out of the agent's output and gate edits behind a plan). Its rules still tell the agent what to do. Nothing stops it mechanically.

Cursor is different. It can load Claude Code hooks from .claude/settings.json (its third-party hooks setting, on by default), so the guards may run there too. We only test them under Claude Code. Details in the agentic layer.

The combination I want is greyed out. Why?

Either the pair is not in the tested set yet, or it really conflicts: Supabase Auth with Neon, say, or two batteries in the same category. The reason shows next to the option. We never let an untested pair through. Better to say "not verified yet" than hand you a repo that doesn't boot.

Want it certified? Open a pull request that runs the matrix for that battery and commits the new tested.yaml. See contributing.

Does the app work before I add any keys?

It builds and boots with no env set. The landing page, /pricing, /terms, /privacy and /llms.txt render from code. Sign-in needs its service: a database for Better Auth, a project for Clerk or Supabase Auth. Each Google, GitHub or Microsoft button shows only once that provider is set up. Checkout without keys says billing is not set up yet, instead of crashing. docs/onboard.md lists every key and where to get it.

Is this just a starter kit with extra files?

The batteries are the ordinary part, even with sign-in, billing, an app shell and an admin panel already built. Plenty of kits ship those. If that is all you need, use one.

The difference is the layer on top: path-scoped rules, skills, subagents, guard hooks with a self-test, seeded solution docs and the plan workflow. Any agent can edit your billing code. This one already knows the repo verifies webhook signatures, keeps plans in src/lib/pricing.ts and price ids in env, and never builds a Stripe object in the browser.

Does the generated repo phone home?

Not to us. The generator adds no telemetry and no call back to this site.

The tools inside it are another matter. Next.js collects anonymous CLI telemetry by default (turn it off with next telemetry disable), and some vendor SDKs, Clerk's among them, do the same. If you picked an analytics battery, that is your own PostHog or DataFast project, keyed by your own env vars, sending data to you.

Where does the proof come from?

The numbers on the home page come from a live client engagement, not a benchmark. 797 commits and 131 pull requests merged in about three weeks. Zero secrets leaked, zero destructive commands run. This generator is that system, productized.

Something doesn't work. What do you need?

Open an issue and attach your agentic.config.json. It is a full reproduction: the same file regenerates the same repo, byte for byte. If it is about one plugin, name it.