Why the marketing site is a different repo than the kit
You are reading nextbento.dev. That origin sells the kit, explains the stack, and ranks for comparison queries. It is not the Next.js app you run after you pay.
The product you clone is a different repository. Auth, Stripe, teams, dashboard, and the eight skills live there. This site has a footer, a compare hub, and JSON for "NextBento vs …" pages. Mixing those jobs in one git history is how agents copy the wrong tree into your product.
What each repo is for
This origin is marketing. Homepage, pricing, docs about the kit, compare, audience pages, glossary, and this blog. Checkout starts here (GET /api/checkout) and sends a human to Stripe. There is no public hosted demo of the dashboard. Do not treat these URLs as your SaaS.
The kit is the app. After purchase, GitHub access is granted to the username collected in Checkout. That repo is where AGENTS.md, migrations, /dashboard, webhooks, and RLS belong. Skills tell the agent how to extend that codebase.
Docs on this site describe the kit. They are not the running product. If a page talks about /admin/team or subscriptions.user_id, it is telling you what you get when you clone, not what this domain executes for logged-in customers.
What goes wrong in one repo
Put live marketing JSON in the same tree as auth and an agent will "help." It will import content/pseo/comparisons.json into the kit's demo pages. It will add a second checkout route on a landing-page edit. It will treat ShipFast copy as seed data for your customers.
The AGENTS.md post already says the handshake lives in the product repo. The split is the other half of that rule: the agent should not see this site's compare matrix as application content.
The pSEO JSON factory is how this site builds /compare and /for. The kit documents extra templates (including location pages) for buyers who have those query patterns. This origin does not generate city pages. That distinction only stays clean if the factories are not the same folder.
What this is not
It is not a monorepo flex. It is not "the marketing site is the product." It is not a claim that you must split every side project into two GitHub repos.
Split when the audiences differ: strangers evaluating a purchase versus you shipping features. Keep them together when the site is the product.
If you want the kit, start at pricing. If you want the argument for a wired foundation instead of a blank repo, that is prompting auth and Stripe from scratch.
