@oaklandzoo/ostup 0.2.0 → 0.4.0

package/templates/.claude/commands/generate-image.md

@@ -0,0 +1,168 @@
+---
+description: Compose an image-generation prompt AND call Vercel AI Gateway to actually generate the image. Saves to inputs/images/ and appends to MANIFEST.md. Requires VERCEL_AI_GATEWAY_KEY. Per CLAUDE.md Part 19, use /update-image to promote into the project.
+---
+
+# Generate image (composer plus API call)
+
+Same flow as `/generate-image-prompt`, but calls Vercel AI Gateway and saves the result. Operator skips the paste-into-another-tool step.
+
+## Step 1: preflight
+
+Check the key exists:
+
+```bash
+if [ -n "$VERCEL_AI_GATEWAY_KEY" ]; then
+  echo "VERCEL_AI_GATEWAY_KEY: present"
+else
+  echo "VERCEL_AI_GATEWAY_KEY: MISSING"
+  echo "Get a key: https://vercel.com/dashboard/ai-gateway"
+  echo "Set it in .env.local (export VERCEL_AI_GATEWAY_KEY=...) and rerun."
+  echo "Aborting."
+fi
+```
+
+If the key is missing, stop and ask the operator to set it. Do not call the API without a key.
+
+## Step 2: identify the asset type, read context, ask clarifying questions
+
+Run Steps 1-3 of `/generate-image-prompt`. Compose the prompt in memory (or print it first for operator review if scope is significant).
+
+## Step 3: surface cost estimate before calling
+
+Print exactly:
+
+```
+About to call Vercel AI Gateway:
+  Model:           openai/dall-e-3
+  Size:            1024x1024
+  Quality:         standard
+  Estimated cost:  ~$0.04 (DALL-E 3 standard 1024x1024)
+
+Proceed? (y/n)
+```
+
+Wait for operator confirmation. If they answer no, stop. If they answer yes (or the agent was invoked with `--yes` semantics from /update-image), proceed.
+
+Cost reference (verify against current Vercel AI Gateway pricing before claiming numbers):
+
+| Model | Size | Cost per image |
+|---|---|---:|
+| openai/dall-e-3 | 1024x1024 standard | ~$0.04 |
+| openai/dall-e-3 | 1024x1024 hd | ~$0.08 |
+| openai/dall-e-3 | 1792x1024 standard | ~$0.08 |
+| openai/dall-e-3 | 1792x1024 hd | ~$0.12 |
+| stability-ai/stable-diffusion-xl | 1024x1024 | ~$0.003 |
+
+If size or model differs from defaults, recompute and surface.
+
+## Step 4: call the API
+
+Use bash and curl. OpenAI-compatible endpoint via Vercel AI Gateway.
+
+```bash
+TIMESTAMP=$(date +%s)
+TYPE="<asset-type>"
+OUT="inputs/images/${TYPE}-${TIMESTAMP}.png"
+mkdir -p inputs/images
+
+# Use a heredoc to safely encode the prompt
+PROMPT_JSON=$(cat <<'JSON_EOF'
+{
+  "model": "openai/dall-e-3",
+  "prompt": "<COMPOSED_PROMPT_GOES_HERE>",
+  "size": "1024x1024",
+  "quality": "standard",
+  "n": 1,
+  "response_format": "b64_json"
+}
+JSON_EOF
+)
+
+curl -s https://ai-gateway.vercel.sh/v1/images/generations \
+  -H "Authorization: Bearer $VERCEL_AI_GATEWAY_KEY" \
+  -H "Content-Type: application/json" \
+  -d "$PROMPT_JSON" > /tmp/ostup-img-response.json
+
+# Verify success
+if ! grep -q "b64_json" /tmp/ostup-img-response.json 2>/dev/null; then
+  echo "API call failed. Response:"
+  cat /tmp/ostup-img-response.json
+  exit 1
+fi
+
+# Extract base64 and write the PNG
+python3 -c "
+import json, base64, sys
+with open('/tmp/ostup-img-response.json') as f:
+    d = json.load(f)
+b64 = d['data'][0]['b64_json']
+with open('$OUT', 'wb') as f:
+    f.write(base64.b64decode(b64))
+print('Saved:', '$OUT')
+"
+
+rm -f /tmp/ostup-img-response.json
+```
+
+If the model returns a URL instead of base64 (some configurations), fall back to:
+
+```bash
+URL=$(python3 -c "import json; print(json.load(open('/tmp/ostup-img-response.json'))['data'][0]['url'])")
+curl -sL -o "$OUT" "$URL"
+```
+
+## Step 5: append to manifest
+
+```bash
+MANIFEST="inputs/images/MANIFEST.md"
+
+# Initialize if missing
+if [ ! -f "$MANIFEST" ]; then
+  echo "# Image manifest" > "$MANIFEST"
+  echo "" >> "$MANIFEST"
+  echo "Generated images, prompts used, models, and timestamps." >> "$MANIFEST"
+  echo "" >> "$MANIFEST"
+fi
+
+cat >> "$MANIFEST" <<EOF
+
+## ${TIMESTAMP} — <asset-type>
+
+- **File:** \`${OUT}\`
+- **Model:** openai/dall-e-3
+- **Size:** 1024x1024
+- **Quality:** standard
+- **Cost:** ~\$0.04
+- **Prompt:**
+  > <COMPOSED_PROMPT_SUMMARY_ONE_LINE>
+
+EOF
+```
+
+## Step 6: report and offer to promote
+
+```
+Generated <asset type>: inputs/images/<asset-type>-<timestamp>.png
+Manifest updated: inputs/images/MANIFEST.md
+
+Want to promote it into the project now? Running /update-image <slot> will:
+  1. Copy this image into public/<slot>/
+  2. Update any code references
+  3. Commit + push
+  4. Wait for Vercel deploy
+  5. Run scripts/screenshot.sh and read the PNG to verify visually
+
+Proceed with /update-image? (y/n)
+```
+
+If operator agrees, run the full `/update-image` routine. Otherwise stop.
+
+## Hard rules
+
+- Generated images land in `inputs/images/` ONLY. Never directly in `public/`. The operator (or `/update-image`) promotes.
+- Every generation appends a manifest line with prompt + model + size + timestamp + cost.
+- Cost is always surfaced before the API call. No surprise charges.
+- Missing `VERCEL_AI_GATEWAY_KEY` fails fast with a clear pointer to the dashboard URL.
+- Brand palette from the brief must be in the prompt. No "free interpretation."
+- This command does not promote the image. `/update-image` handles promotion + Part 19 visual verification.
+- If the API call fails (rate limit, content policy, network), report the full error and do NOT retry silently.

package/templates/.claude/commands/preflight.md

@@ -34,6 +34,14 @@ echo "=== Local tools ==="
 node --version
 [ -d "/Applications/Google Chrome.app" ] && echo "Chrome: present" || echo "Chrome: MISSING (operator must install for visual verification per CLAUDE.md Part 19)"
 [ -x "scripts/screenshot.sh" ] && echo "scripts/screenshot.sh: ready" || echo "scripts/screenshot.sh: MISSING or not executable"
+
+echo ""
+echo "=== AI Gateway (for /generate-image) ==="
+if [ -n "$VERCEL_AI_GATEWAY_KEY" ]; then
+  echo "VERCEL_AI_GATEWAY_KEY: present (image generation enabled)"
+else
+  echo "VERCEL_AI_GATEWAY_KEY: not set (/generate-image will fail until set; get one at https://vercel.com/dashboard/ai-gateway; /generate-image-prompt still works as composer-only)"
+fi
 ```
 
 ## Step 2: print the SESSION READY summary

package/templates/AGENTS.md

@@ -29,10 +29,20 @@ Operator materials live in `{{INPUTS_PATH}}`. Read `{{INPUTS_PATH}}README.md` fo
 
 Session lifecycle: `/bootstrap`, `/prompt-start`, `/prompt-mid`, `/prompt-end`, `/preflight`
 
-Building: `/create-prd`, `/generate-tasks`, `/update-image`, `/update-gui`, `/update-backend`, `/add-storage`
+Building: `/create-prd`, `/generate-tasks`, `/update-image`, `/update-gui`, `/update-backend`, `/add-storage`, `/generate-image-prompt`, `/generate-image`
 
 See each file under `.claude/commands/` for the full routine.
 
+## ostup CLI subcommands (run outside Claude Code)
+
+- `ostup brief` — 10-question operator intake; writes `docs/brief.md`, `docs/brief.json`, `tasks/prd-initial-build.md`.
+- `ostup init --brief <path>` — scaffold using an existing brief.json; applies the matching profile overlay.
+- `ostup init` — interactive scaffold without brief.
+
 ## Helpers
 
 - `scripts/screenshot.sh <url> [out] [WxH]` — headless Chrome screenshot. Required for visual verification per `CLAUDE.md` Part 19.
+
+## If `docs/brief.md` is present in this project
+
+Treat it as authoritative for scope, profile, brand, business model, and constraints. Downstream commands (`/create-prd`, `/generate-tasks`, etc.) should read `docs/brief.json` first to avoid re-asking the operator the same questions. Profile-specific guidance lives at `templates/profiles/<profile>/` (copied into your project root as `README.md` and `section-prompts.md` when the overlay is applied).

package/templates/CLAUDE.md

@@ -227,6 +227,9 @@ Detailed file map: `docs/ARCHITECTURE.md`.
 > Things unique to THIS repo. Filled by `/bootstrap` or as discovered.
 
 - Operator materials live in `{{INPUTS_PATH}}`. Read `{{INPUTS_PATH}}README.md` for the layout. If `{{INPUTS_PATH}}INGEST_MANIFEST.md` exists, read it before starting work.
+- If `docs/brief.md` exists, it is the **authoritative source** for scope, profile, brand, business model, and constraints. Read `docs/brief.json` for the machine-readable version. Do not re-ask the operator the questions already answered there.
+- If `tasks/prd-initial-build.md` exists, it is the **first PRD seed** generated from the brief. Start there before writing code.
+- If a `README.md` and `section-prompts.md` exist at the project root from a profile overlay (e.g. `lead-gen`, `booking`, `saas-dashboard`, `blog`), follow that profile's hard rules and section guidance.
 - {{CONVENTION_1}}
 - {{CONVENTION_2}}
 - {{CONVENTION_3}}

package/templates/START_HERE.md

@@ -17,9 +17,9 @@ Or use `codex`, `gemini`, or whichever CLI agent you prefer.
 ### 2. Paste this as your first message
 
 ```
-Read CLAUDE.md, AGENTS.md, and everything in {{INPUTS_PATH}}. If {{INPUTS_PATH}} has source materials (research, reference repos, brand assets, notes), use them as context. If it is empty or only has a README, that is fine. Either way, ask me up to 3 clarifying questions about what I want to build. Then propose a 30 to 60 minute MVP scope as a numbered list. Do not write code until I approve the scope.
+Read CLAUDE.md, AGENTS.md, docs/brief.md (if it exists), tasks/prd-initial-build.md (if it exists), and everything in {{INPUTS_PATH}}. If {{INPUTS_PATH}} has source materials (research, reference repos, brand assets, notes), use them as context. If it is empty or only has a README, that is fine. Either way, ask me up to 3 clarifying questions about what I want to build. Then propose a 30 to 60 minute MVP scope as a numbered list. Do not write code until I approve the scope.
 
-After I approve, run /bootstrap to fill in this project's metadata, then start building.
+After I approve, run /bootstrap to fill in this project's metadata, then start building. If docs/brief.md exists, treat it as authoritative for scope, brand, and constraints.
 ```
 
 That is the whole jump-in. The agent reads, asks, proposes, you approve, it builds.
@@ -38,6 +38,10 @@ That is the whole jump-in. The agent reads, asks, proposes, you approve, it buil
 | `docs/ARCHITECTURE.md` | Stack, file map, env vars, deploy details. | Agent |
 | `{{INPUTS_PATH}}` | Your source materials. May be empty. You can add files anytime. | Both |
 | `tasks/` | PRDs and task lists for features. | Both |
+| `docs/brief.md` | Operator brief (only if you scaffolded with `ostup brief`). Source of truth for scope, brand, constraints. | Both |
+| `docs/brief.json` | Machine-readable brief (same trigger). Used by downstream commands. | Agent |
+| `tasks/prd-initial-build.md` | Auto-seeded first PRD from the brief (same trigger). | Both |
+| `templates/profiles/<profile>/` | (if applicable) Profile-specific guidance the agent reads on day one. | Agent |
 | `.claude/commands/` | Slash command definitions. | Agent |
 
 ## Slash commands
@@ -57,6 +61,8 @@ Type these in your CLI agent. Each runs a structured routine.
 | `/update-gui` | Make a UI change, deploy, screenshot, confirm the visual change matches intent. Enforces visual verification. | Any UI tweak. |
 | `/update-backend` | Make a backend/API change, deploy, probe the live endpoint, confirm behavior. | Any server/API change. |
 | `/add-storage` | Provision a Vercel Blob, KV, Postgres, or Edge Config store + scaffold a typed `src/lib/<type>.ts` helper + pull env vars. | When you need persistent storage. |
+| `/generate-image-prompt` | Compose an image-generation prompt from the project brief + 2-3 questions. No API call. Paste the prompt into your preferred image tool. | When you need a visual asset and want to use Midjourney, DALL-E, Imagen, etc. directly. |
+| `/generate-image` | Compose the prompt AND call Vercel AI Gateway, saving the image to `inputs/images/`. Requires `VERCEL_AI_GATEWAY_KEY`. | When you want the image generated in-line without leaving your agent. |
 
 ## Three workflows
 
@@ -64,13 +70,13 @@ Type these in your CLI agent. Each runs a structured routine.
 
 1. `claude` in this folder.
 2. Paste the prompt from step 2 above.
-3. The agent reads everything, asks 2 or 3 questions, proposes an MVP.
+3. The agent reads everything (including `docs/brief.md` if present), asks 2 or 3 questions, proposes an MVP.
 4. You approve (or refine).
 5. The agent runs `/bootstrap` to fill in project metadata.
 6. The agent builds the first cut and pushes commits.
 7. `/prompt-end` when you stop.
 
-Works the same whether `{{INPUTS_PATH}}` is empty or full. With materials, the agent uses them. Without, it asks you what to build outright.
+Works the same whether `{{INPUTS_PATH}}` is empty or full. With materials, the agent uses them. Without, it asks you what to build outright. If you scaffolded with `ostup brief` or `ostup init --brief`, the agent has a richer starting point: scope, profile, business model, and add-ons already chosen.
 
 ### B. Return session (pick up where you left off)
 

package/templates/profiles/blog/.env.example.additions

@@ -0,0 +1,7 @@
+# --- blog profile additions ---
+# Public app URL (used for absolute URLs in RSS + sitemap)
+NEXT_PUBLIC_APP_URL=http://localhost:3000
+
+# Optional: site author / RSS metadata
+NEXT_PUBLIC_AUTHOR_NAME=
+NEXT_PUBLIC_AUTHOR_URL=

package/templates/profiles/blog/README.md

@@ -0,0 +1,70 @@
+# Profile: blog
+
+> Content engine. MDX posts, RSS, sitemap, tag/author pages. SEO-first. No CMS v1.
+
+## Day-one scope
+
+| Section | Purpose | Required |
+|---|---|---|
+| Homepage | Latest 6-10 posts, intro paragraph | yes |
+| Post page | Single post by slug, MDX-rendered | yes |
+| Tag index | List of all tags with post counts | yes |
+| Tag page | All posts under a tag | yes |
+| Author page (if multi-author) | Author bio + their posts | conditional |
+| RSS feed | `/rss.xml` valid RSS 2.0 | yes |
+| Sitemap | `/sitemap.xml` valid sitemap | yes |
+| About | Static about page | yes |
+| Footer | Links, RSS, year | yes |
+
+## Wired infrastructure
+
+- **MDX** for post bodies. Posts live as `.mdx` files in `content/posts/`.
+- Frontmatter schema: `title`, `slug`, `date`, `tags[]`, `author?`, `description?`, `draft?`.
+- `next-mdx-remote` or `@next/mdx` (agent picks; both work).
+- Open Graph + Twitter card metadata per post.
+- Article + Organization JSON-LD schema.
+
+## Env additions
+
+See `.env.example.additions` (mostly empty for blog v1).
+
+## File contracts
+
+```
+content/posts/<slug>.mdx
+  ---
+  title: "Post title"
+  slug: "post-slug"
+  date: "2026-05-21"
+  tags: ["agents", "tooling"]
+  author: "GG"
+  description: "One-sentence summary for SEO."
+  ---
+  
+  Body in MDX.
+
+content/authors/<author>.mdx (optional)
+  ---
+  name: "GG"
+  bio: "One-paragraph bio."
+  social: { x: "@goodshin", github: "DubsFan" }
+  ---
+```
+
+## Hard rules
+
+- Posts ship as committed MDX files. No DB v1.
+- `draft: true` excludes from production builds AND from RSS/sitemap.
+- RSS / sitemap regenerate on build.
+- Code blocks use one syntax highlighter (Shiki recommended). Pick at build time, not client-side.
+- Reading width capped at 720px or so for body comfort.
+- Light + dark mode via `prefers-color-scheme`.
+
+## Acceptance
+
+- Homepage shows latest 6 posts sorted by date desc.
+- Individual post page renders MDX with syntax-highlighted code.
+- RSS feed validates at https://validator.w3.org/feed/.
+- Sitemap includes every published post (no drafts).
+- Tag pages reachable from each post's tag list.
+- Lighthouse Performance >= 95 (static content, should be fast).

package/templates/profiles/blog/section-prompts.md

@@ -0,0 +1,63 @@
+# Blog profile section prompts
+
+Agent: build each section using the brief. Default MDX library: `next-mdx-remote`. Use `gray-matter` for frontmatter parsing.
+
+## Homepage
+
+- Title + tagline from the brief.
+- Latest 6 posts: title (clickable), date, 1-2-sentence excerpt from `description` or first 160 chars of body.
+- "All posts" link to a chronological archive (optional v1).
+- Tag cloud or top 5 tags if there are 3+ tagged posts.
+
+## Post page (`/posts/[slug]`)
+
+- Title (h1), date, tags (clickable to tag pages), author (if multi-author).
+- MDX-rendered body.
+- Code blocks: syntax-highlighted with Shiki. Light + dark theme.
+- Body width capped (~65ch).
+- Reading time estimate (optional).
+- Open Graph: title, description, type=article, published_time, author.
+
+## Tag index (`/tags`)
+
+- All tags from all published posts, sorted by post count desc.
+- Each tag: name + post count + link.
+
+## Tag page (`/tags/[tag]`)
+
+- All posts under that tag, chronological desc.
+- Same card format as homepage list.
+
+## Author page (`/authors/[author]`) — only if multi-author
+
+- Author bio from `content/authors/<author>.mdx`.
+- All posts by that author.
+
+## RSS feed (`/rss.xml`)
+
+- RSS 2.0.
+- Include title, link, description, pubDate, category for each post.
+- Published posts only (`draft: false`).
+- Validate the output structure manually before claiming done.
+
+## Sitemap (`/sitemap.xml`)
+
+- All published posts + tag pages + author pages + homepage + about.
+- `<lastmod>` on each entry.
+- No drafts.
+
+## About
+
+- Pulled from the brief: who runs the site, what it covers, contact.
+- Single page. Plain text + maybe a portrait from `inputs/images/`.
+
+## Footer
+
+- RSS link with feed icon.
+- GitHub link (if applicable).
+- Year + copyright.
+
+## First post
+
+- If the brief mentions a launch announcement, write `content/posts/hello-world.mdx` as a placeholder with the project summary.
+- Otherwise leave `content/posts/` with a `.gitkeep` only and let the operator write the first post.

package/templates/profiles/booking/.env.example.additions

@@ -0,0 +1,16 @@
+# --- booking profile additions ---
+# Database for Booking entity (Neon recommended; any Postgres works)
+DATABASE_URL=
+
+# Email confirmation
+RESEND_API_KEY=
+BOOKING_TO_EMAIL=
+BOOKING_FROM_EMAIL=noreply@example.com
+
+# Optional: Stripe deposit checkout (enable only if `payments` addon is on)
+STRIPE_SECRET_KEY=
+STRIPE_PUBLISHABLE_KEY=
+STRIPE_WEBHOOK_SECRET=
+
+# Public app URL (Vercel sets this for production)
+NEXT_PUBLIC_APP_URL=http://localhost:3000

package/templates/profiles/booking/README.md

@@ -0,0 +1,61 @@
+# Profile: booking
+
+> Appointment / reservation site. Availability request, booking form, optional Stripe deposit, email confirmations.
+
+## Day-one scope
+
+| Section | Purpose | Required |
+|---|---|---|
+| Hero | Single value statement + "Check availability" or "Book now" CTA | yes |
+| Availability / Booking form | Date range or appointment slot picker + guest info | yes |
+| Rooms / Services | List of bookable units with descriptions and rates | yes |
+| Deposit checkout | Stripe Checkout for the deposit if `payments` addon is on | conditional |
+| Confirmation email | Auto-send on submission to both guest and admin | yes |
+| About / Amenities | Trust-building content from the brief | yes |
+| Footer | Contact, cancellation policy summary | yes |
+
+## Wired infrastructure
+
+- **Postgres** for the `Booking` entity (date_start, date_end, guest info, status, deposit_status).
+- **Resend** for guest + admin confirmation emails.
+- **Stripe Checkout** for deposit (only if `payments` addon is on per the brief).
+- Mobile-first calendar / date picker.
+
+## Env additions
+
+See `.env.example.additions`.
+
+## API contracts
+
+```
+POST /api/booking/request
+Body: { name, email, phone?, date_start, date_end, room_or_service?, notes? }
+Response: { ok, booking_id }
+Behavior: insert Booking with status='pending', email both parties.
+
+POST /api/booking/deposit
+Body: { booking_id }
+Response: { ok, checkout_url }
+Behavior: create Stripe Checkout session, return URL.
+
+POST /api/webhooks/stripe
+Behavior: on payment_intent.succeeded, mark booking deposit_status='paid'.
+```
+
+## Hard rules
+
+- Date pickers MUST be mobile-friendly (no tiny native date inputs without testing).
+- Server-side validate the date range (no past dates, no end-before-start).
+- Confirmation emails go out immediately on form submit, even before deposit.
+- Deposit is OPTIONAL: if `payments` addon is off, skip Stripe entirely. Booking still goes through.
+- Calendar availability check should be server-side; do not trust client.
+- If `Booking.status` is 'pending' for >48h with no deposit, mark as 'expired'.
+
+## Acceptance
+
+- Visitor can request dates and submit.
+- Both visitor and admin receive emails within 30 seconds.
+- Deposit Checkout opens if enabled, completes round-trip to the booking record.
+- Past dates rejected with clear error.
+- Hero CTA above the fold at 420x900.
+- Lighthouse mobile Performance >= 85 (acceptable lower than marketing because of date picker JS).

package/templates/profiles/booking/section-prompts.md

@@ -0,0 +1,47 @@
+# Booking profile section prompts
+
+Agent: build each section using the brief in `docs/brief.md`. Honor `must_avoid` strictly.
+
+## Hero
+
+- Headline (5-9 words) about the experience being booked.
+- Subhead: one sentence on what the visitor gets when they book.
+- Primary CTA: "Check availability" or "Book now" — opens the booking form modal or scrolls to it.
+
+## Availability / Booking form
+
+- Date range picker (or single-date for appointments). Mobile-friendly is mandatory.
+- Guest info: name, email, phone, party size (if relevant), notes.
+- Validate server-side: no past dates, end after start, party size within room limits.
+- Loading state on submit. Success state with booking ID. Error state with clear message.
+
+## Rooms / Services
+
+- Pull entity list from the brief's `data_model.entities`. If a Room entity exists, list its fields visually.
+- Each unit: name, description (short), rate per night/hour, photo placeholder if `inputs/images/` has anything matching.
+- "Book this" CTA scrolls back to the booking form with the room pre-selected.
+
+## Deposit checkout (conditional)
+
+- Only render if `payments` addon is in the brief.
+- After successful booking submission, present a "Pay deposit to confirm" CTA.
+- Clicking opens Stripe Checkout via `/api/booking/deposit`.
+- On Checkout success, return to a `/booking/[id]/confirmed` page.
+- Webhook `/api/webhooks/stripe` updates `deposit_status='paid'`.
+
+## Confirmation emails
+
+- Guest receives: "Your booking request is in. We'll confirm within X hours. Booking ID: ABC123."
+- Admin receives: full booking details + a link to the admin route (TBD v2).
+- Use Resend. Plain text + HTML versions.
+
+## About / Amenities
+
+- Pull from the brief's `must_have_sections`. Echo the brief's vibe.
+- Photos from `inputs/images/` if any. Otherwise text-only placeholders.
+
+## Footer
+
+- Cancellation policy summary (1-2 sentences from the brief or a placeholder asking the operator).
+- Contact email + phone.
+- Year + copyright.

package/templates/profiles/lead-gen/.env.example.additions

@@ -0,0 +1,8 @@
+# --- lead-gen profile additions ---
+# Email notifications for contact-form submissions
+RESEND_API_KEY=
+CONTACT_TO_EMAIL=
+CONTACT_FROM_EMAIL=noreply@example.com
+
+# Optional: forward lead payloads to a CRM as JSON
+CRM_WEBHOOK_URL=

package/templates/profiles/lead-gen/README.md

@@ -0,0 +1,58 @@
+# Profile: lead-gen
+
+> Service-company site that captures contact requests. Resend for email, optional CRM webhook, local SEO basics.
+
+## Day-one scope
+
+| Section | Purpose | Required |
+|---|---|---|
+| Hero | Single value statement + primary CTA "Request a quote" or "Contact us" | yes |
+| Services | 3-8 service cards or list. Tap-to-call on mobile. | yes |
+| Service area | Map placeholder OR text list of cities / zip codes covered | yes |
+| Testimonials | 2-4 quotes (placeholders OK if brief has none) | yes |
+| FAQ | 4-8 questions, accordion or stacked | yes |
+| Contact form | Name, phone, email, message. Posts to /api/contact. | yes |
+| Footer | Phone, email, license number if applicable, year | yes |
+
+## Wired infrastructure
+
+- **Resend** for email notifications when a lead submits the form.
+- Optional **CRM webhook** (env: `CRM_WEBHOOK_URL`). If set, also POST the lead payload as JSON.
+- **JSON-LD LocalBusiness schema** in the head of every page.
+- Open Graph + Twitter metadata using `{{DISPLAY_NAME}}` and the brand summary.
+
+## Env additions
+
+See `.env.example.additions` for the variables this profile expects.
+
+## API contract for /api/contact
+
+```
+POST /api/contact
+Content-Type: application/json
+Body: { name: string, email: string, phone?: string, message: string }
+Response: { ok: boolean, id?: string }
+```
+
+The route:
+1. Validates required fields (name, email, message).
+2. Sends an email via Resend to `CONTACT_TO_EMAIL` from `CONTACT_FROM_EMAIL`.
+3. If `CRM_WEBHOOK_URL` is set, POSTs the lead payload there.
+4. Returns 200 with `{ ok: true }` on success; 400 on validation; 500 on send failure.
+
+No persistent storage v1. Leads live in the operator's email inbox.
+
+## Hard rules
+
+- Phone number on every page (mobile sticky CTA acceptable).
+- Service area is explicit. Do not claim to cover areas the brief does not mention.
+- No JS-heavy carousels. Stacked content reads better on phones.
+- Honor `constraints.must_avoid` strictly.
+
+## Acceptance
+
+- Visitor can submit the contact form, sees an inline success state.
+- Owner receives the lead by email at the address in `CONTACT_TO_EMAIL`.
+- JSON-LD LocalBusiness schema validates at https://search.google.com/test/rich-results.
+- Hero CTA above the fold at 420x900.
+- Lighthouse mobile Performance >= 90, Accessibility >= 95.

package/templates/profiles/lead-gen/section-prompts.md

@@ -0,0 +1,47 @@
+# Lead-gen profile section prompts
+
+Agent: build each section using the brief in `docs/brief.md`. Do not invent service offerings, prices, or testimonials.
+
+## Hero
+
+- Headline: 5-9 words. Echo the project summary in the operator's voice.
+- Subhead: one sentence on who it serves and what they get.
+- Primary CTA: "Request a quote" or "Contact us today" (use the brief's wording if it specifies).
+- Secondary trust signal: years in business, license number, or service area at a glance (only if in brief).
+
+## Services
+
+- List 3-8 services from the brief's `scope.must_have_sections` (filter out non-service sections like hero/footer/contact).
+- Each service card: short title + one or two sentences + (if available from brief) a starting-price hint.
+- Tap-to-call phone link visible on mobile.
+
+## Service area
+
+- If the brief mentions specific cities, towns, or zip codes, list them.
+- If only a general area, use that phrasing exactly.
+- If no specific area info: ask the operator to fill in `docs/brief.md` before building this section. Do NOT default to "nationwide."
+
+## Testimonials
+
+- 2-4 short quotes. If the brief has actual quotes, use them.
+- If none: use clear placeholders like `[Testimonial pending — operator to add]` and DO NOT fabricate.
+
+## FAQ
+
+- 4-8 questions tied to the services from the brief.
+- Suggested defaults: "How fast can you get here?", "Do you provide free estimates?", "Are you licensed and insured?", "Do you offer financing?". Match to the brief's business model.
+- Use an accordion or stacked Q/A. No JS framework needed.
+
+## Contact form
+
+- Fields: name (required), email (required), phone (optional), message (required).
+- POSTs to `/api/contact`.
+- Inline success message on submit: "Got it. We will be in touch within one business day."
+- On error: inline message with retry, never alert dialogs.
+- Form labels visible, not just placeholders (accessibility).
+
+## Footer
+
+- Phone, email, address (if relevant), license number (if relevant).
+- Current year, copyright.
+- Privacy / Terms links if the operator has them (otherwise omit; do not invent legalese).