# BusinessStub Stub Authoring Prompt

Use this when asking Codex to build a new custom stub site for BusinessStub.

## Goal

Prepare an existing or newly built stub site for BusinessStub import with the smallest safe set of changes.

Assume the site already exists unless the prompt explicitly says to build one from scratch.
The default job is not to redesign, restructure, or restyle the site. The default job is to make the repo BusinessStub-compatible.

## Required outputs

Codex should produce all of the following:

1. The site repo itself, including any custom layout/components needed for the stub.
2. A schema-driven editor configuration in the repo:
   - `site-editor/schema.json`
   - `site-editor/content.json`
3. A BusinessStub onboarding bundle:
   - `businessstub-import.json`

If the site already exists, Codex should modify as little as possible outside the BusinessStub integration files.

## Requirements for the site repo

- Keep the site static and lightweight.
- Preserve the current site implementation and visual design unless a change is strictly required for BusinessStub integration.
- Do not make the site depend on BusinessStub runtime code.
- The owner should only be able to edit approved fields through the schema/content files.
- The repo should be ready for Cloudflare to publish from GitHub.
- The site must be wired so changes to `site-editor/content.json` actually change the rendered site.

## Integration-first rule

Codex should treat the existing site as the source of truth for:

- layout
- styling
- structure
- copy tone
- component organization

Codex should not:

- redesign the site
- change layout composition
- restyle sections
- rename files or reorganize the repo without necessity
- replace an existing rendering approach just to match a preferred pattern

Codex should only make changes that are necessary to:

- add `site-editor/schema.json`
- add `site-editor/content.json`
- wire the site to read approved editable content
- wire the contact form to BusinessStub
- produce `businessstub-import.json`

If an existing site already has a working build process, Codex must preserve it.

## Build/runtime requirement

Codex must not just create `site-editor/schema.json` and `site-editor/content.json`. It must also implement the site so those files are used by the site itself.

Accepted patterns:

1. Build-time loader
   - the repo has a real build step
   - the build reads `site-editor/content.json`
   - the generated HTML uses that content
   - the important SEO content is present in the built HTML at response time

2. Static runtime loader
   - the site fetches `site-editor/content.json` in the browser
   - the page applies content into predefined DOM targets
   - no rebuild is required for content-only changes

When the repo already has a build process, Codex should integrate `site-editor/content.json` into that existing build process instead of introducing a new architecture.

The preferred default is:

- preserve the existing build
- add the smallest possible content-loading integration

Use the static runtime loader only when:

- the repo is already built that way
- or there is no safe build-time path without significantly rewriting the site

Do not produce:

- a site where `content.json` exists but nothing reads it
- a hardcoded `index.html` that ignores the editor content
- a repo that requires manual editing of HTML after import
- a runtime-only content injection pattern for the main marketing copy unless explicitly justified
- a redesign disguised as “integration”
- broad refactors unrelated to BusinessStub onboarding

Codex should explicitly state in its final summary which pattern it implemented:

- `runtime content loader`
- or `build-time content loader`

## Requirements for `site-editor/schema.json`

- Use a constrained schema with only approved editable fields.
- The schema should be specific to this stub site.
- It must describe only the editable content, not arbitrary layout editing.
- It must use BusinessStub's exact editor format.

Use this exact top-level shape:

```json
{
  "version": 1,
  "title": "Stub Website Editor",
  "description": "Editable content for this site.",
  "fields": []
}
```

Rules for the schema:

- `fields` is required and must be a non-empty array
- every field object must have:
  - `name`
  - `type`
  - `label`
- supported field types are:
  - `text`
  - `textarea`
  - `url`
  - `email`
  - `tel`
  - `color`
  - `image`
  - `select`
  - `boolean`
  - `object`
  - `list`
- `object` fields must contain a nested `fields` array
- `list` fields must use either:
  - `itemFields` for object-style repeated items
  - `item` for simple repeated scalar values

Do not use:

- `collections`
- `blocks`
- `sections`
- arbitrary CMS config formats
- Decap or Tina style schema formats
- any schema without a top-level `fields` array

Use this repo file as the reference model:

- `/site-editor-examples/professional-organizer-boise/schema.json`

## Requirements for `site-editor/content.json`

- Fill it with realistic initial content matching the site.
- Use production-ready copy, not placeholders.
- The content JSON keys must align exactly with the schema field names.
- Use this repo file as the reference model:
  - `/site-editor-examples/professional-organizer-boise/content.json`

## Site implementation expectations

The rendered site must map to the content model in a deliberate, reviewable way.

Examples:

- hero headline in the page should come from `content.hero.headline`
- primary CTA text should come from `content.hero.primary_cta_text`
- FAQ items should come from `content.faq.items`

Codex should keep the mapping readable and predictable. Avoid overly abstract content plumbing for these small static sites.
If the site already has a content/config layer, extend that layer instead of replacing it.

For SEO-critical content, the mapping should happen at build time so the final HTML already contains:

- title tags
- meta description
- hero copy
- service copy
- FAQ content
- primary headings and page sections

If Codex chooses a runtime loader instead, it must explain why that tradeoff is acceptable for the specific stub and why preserving the existing site outweighed a build-time refactor.

## Contact form requirement

The site must send contact form inquiries back to the central BusinessStub app.

Use:

- `POST https://businessstub.com/api/stub-site-inquiries`

Required request shape:

- `stub_slug`
- `name`
- `email`
- `message`

Optional fields:

- `phone`
- `company`
- `interest_type`
- `source_page`

Required header:

- `X-Stub-Intake-Key`

The stub site should be implemented so the intake key and stub slug are easy to configure in one place, without requiring manual edits to rendered HTML files.

Expected behavior:

- the form submits directly to BusinessStub
- successful submissions land in BusinessStub admin inquiries
- the site should show a clear success and error state
- the form should not require any separate backend owned by the stub repo

Do not build:

- a local-only fake contact form
- a form that sends to Formspree or another third-party inbox
- a form that emails directly from the stub repo

The preferred pattern is:

- store the stub slug in site content or a small config object
- store the intake key in a site config file or environment-backed injected constant
- post directly to `https://businessstub.com/api/stub-site-inquiries`

If the site already has a contact form implementation, Codex should modify that implementation in place instead of replacing the form structure.

## Requirements for `businessstub-import.json`

Use this exact shape:

```json
{
  "version": 1,
  "listing": {},
  "repo": {},
  "site_editor": {},
  "operations": {}
}
```

Populate it with:

- listing metadata for the marketplace
- repo metadata for GitHub-backed editing
- site editor enabled flag
- operations metadata for analytics and owner routing

The JSON should match the BusinessStub template at:

- `/templates/stub-import.template.json`

## Listing copy expectations

The listing section should include:

- domain
- slug
- title
- niche
- city
- region
- summary
- description
- value proposition
- pricing
- preview URL
- SEO title and description
- included assets
- transfer checklist

The copy should read like a professional marketplace listing for a business asset, not a dev artifact.

## Repo metadata expectations

The repo section should include:

- GitHub owner
- repo name
- branch
- `site-editor/schema.json`
- `site-editor/content.json`

If the site uses build-time content loading, Codex should also include the build/deploy expectations in its summary so the stub can be paired with a Cloudflare Pages deploy hook after import.

## Operations metadata expectations

The operations section should include:

- analytics hostname
- owner email
- owner name
- optional owner notification email

If a Cloudflare zone ID is not known yet, leave it blank.
Do not include an owner password in the import bundle. BusinessStub will generate a temporary credential for a brand new owner account, and the owner can use the forgot-password flow to set a real password.

## Final deliverable summary

At the end, Codex should list:

- files created in the repo
- files modified in the repo
- the final `businessstub-import.json` path
- any manual steps still required after import

Codex should also explicitly state:

- whether the site already existed before the integration work
- what was intentionally left unchanged
- what was changed only for BusinessStub compatibility

Before finalizing, Codex should verify that `site-editor/schema.json` still has a top-level `fields` array and follows the same structural pattern as `/site-editor-examples/professional-organizer-boise/schema.json`.
Before finalizing, Codex should also verify that the site implementation actually reads from `site-editor/content.json` and is not using hardcoded placeholder content instead.
Before finalizing, Codex should also verify that the contact form is wired to post to `https://businessstub.com/api/stub-site-inquiries` with the correct payload and `X-Stub-Intake-Key` header.
Before finalizing, Codex should verify that the primary SEO content is present in the built HTML if it used the preferred build-time loader pattern.