DAT
Due Diligence Data Room Analyst Docs
Home
HomeAdd Api EndpointBetter Auth Best PracticesCli DevelopmentCreate Auth SkillDb HealthEnvironment BootstrapFork Build DeployNeon Branch ManagementNext Best PracticesNext Cache ComponentsNext UpgradeOrganization Best PracticesPromote DeploymentRelease CliRelease SdkResend Domain SetupRun Quality GatesSandboxed TasksSetting Up Domains With Porkbun And VercelSetup ProductStripe SetupTesting InfraUnionstreet DesignVercel DeploymentWebhooks And Events

Setup Product

High-level orientation for turning Seed into a new product. This is the first-stop skill when the user is starting a fork — it sets direction and points at the lower-level skills that do the actual work.

Default stance

Edit lib/brand.ts and the product contract: schema strategy, OpenAPI/REST, MCP, CLI, skills, docs, and smoke. Don't reinvent the deployment, auth, or release machinery — it's already in the box. A new fork that touches Vercel config, the auth setup, or the release pipeline before it has a working schema strategy is almost always doing too much. Get the product identity in, decide what is strict versus flexible, generate the schema migration, push, validate the preview, then expand.

Stay agentic in product shaping. The repo enforces the few hard rails (no db:push, env parity, etc.) and lets you make every other decision in conversation with the user.

Use this skill when

Forking Seed for a new product, setting product identity, deciding what the minimal first slice is, or explaining the fork → ship path to a new collaborator.

Minimal path

Read WORKFLOW.md first for the root fork/build/deploy sequence. Use this skill for product setup decisions inside that workflow.

  1. Update lib/brand.ts — product name, CLI name, public URLs. This is the seam between "Seed template" and "your product."
  2. Define the schema strategy — classify data as platform-owned, product-owned, or user/agent-owned before editing lib/schema.ts.
  3. Prefer the product rails — put product metadata, schema, OpenAPI, and skills in product/<slug>/, then run bun run product:generate and bun run product:check.
  4. Define the product schema — edit lib/schema.ts with org-scoped tables (every table that holds product data should have organizationId). Use strict columns for stable facts and flexible definitions/JSONB records for customizable fields, objects, and relationships.
  5. Add API surface — see add-api-endpoint for the OpenAPI-first flow. If the product supports customization, include schema discovery and mutation routes.
  6. Add MCP tools and CLI verbs for the product's core headless actions. The CLI binary must match the product slug in lib/brand.ts; flexible schema controls need MCP and CLI coverage too.
  7. Publish product skills under UnionStreetAI/skills/<product>/skills/*; use those public skills as the source for /skills, /docs, and llms.txt.
  8. Build only required UI — headless products should not get a GUI unless the user explicitly asks for one. Public pages such as /skills, /docs, auth, and billing must follow Union Street design.
  9. Generate migrations — bun run db:generate. Never db:push.
  10. Run gates and headless smoke — ./scripts/gates.sh, Svix smoke, Stripe smoke when billing applies.
  11. Provision live rails — bun run product:provision creates/verifies GitHub, Vercel, Neon, env, domain, Svix, and Stripe.
  12. Deploy and smoke — bun run product:deploy, bun run product:smoke, then bun run product:ship-report.
  13. Push and validate the preview URL.
  14. Promote through staging → main — see promote-deployment.

Hard rules

  • bun run db:push is banned. Hosted migrations apply during the Vercel build.
  • Push the branch and wait for the preview deployment before debugging branch env or DB wiring.
  • Validate the live preview URL first. Local DB poking is a fallback, not a default.
  • If you need branch wiring details, use vercel env pull. If you still need direct DB access after that, use neonctl.
  • Product docs must be product docs. Do not include Seed factory docs, factory runbooks, or internal launch instructions in /docs or llms.txt.
  • Missing product skills, missing MCP tools, stale CLI binary naming, missing headless smoke, or Union Street design violations are release blockers.
  • Missing schema strategy is a release blocker. Do not hide custom fields or relationships in anonymous JSON blobs; define them, scope them, and expose them through API/MCP/CLI/skills/docs.

Skill web

Use this skill for orientation. Drop into:

  • fork-build-deploy — the full sequence at the coordinator level
  • db-health — migration and Neon rules; read this before touching lib/schema.ts
  • add-api-endpoint — adding API routes (OpenAPI-first)
  • promote-deployment — preview → staging → main flow
  • organization-best-practices / better-auth-best-practices — multi-tenant + auth tuning
  • webhooks-and-events / sandboxed-tasks — reactive and agent surfaces if the product needs them

Where things live

FilePurpose
lib/brand.tsProduct identity (name, CLI name, base URLs)
product/<slug>/Agent-authored product rail input
scripts/product-rails.mjsGenerates/checks mechanical product plumbing
scripts/product-live.mjsProvisions/deploys/smokes live product infrastructure
lib/schema.tsDrizzle tables — strict platform/product tables plus flexible schema definitions where customization is allowed
lib/auth.tsBetter Auth config — usually unchanged per fork
lib/org-access.tsRole/resource permissions — adjust per product RBAC
app/Next.js App Router
openapi/v1.yamlAPI spec — single source of truth
cli/Go CLI scaffold — binary name must match product slug
sdks/typescript/TS SDK scaffold — only if the product needs an SDK
UnionStreetAI/skills/<product>/skills/*Public product skills that drive install/docs surfaces
/skillsProduct skill installation page
/docsProduct documentation generated from public product skills
llms.txtLLM-facing product surface index
CLAUDE.mdRepo conventions, env matrix, Neon quirks

Auxiliary content