Landing Page Bootstrap

How it works

Landing Page Bootstrap is a playbook — an 8-step sequence the CEO follows deterministically when an owner triggers it. The full text lives at apps/engine/resources/playbooks/landing-page-bootstrap.md. The CEO recognizes the trigger from phrases like "build my landing page," "make me a site," "website," "put my business online."

Before step 1 runs, the CEO checks three gates: GitHub is connected, Railway is connected, and onboarding answers (businessKind, peopleCount, wishAutomated, northStar, handsOnLevel) are on file. If any gate fails, an owner card is surfaced and the playbook pauses until resolved.

Steps 2 through 5 are delegated to the Coding Specialist: draft copy → render the HTML+Tailwind site → push to a fresh GitHub repo → deploy to Railway via its API. Step 6 is the evaluator gate — the CEO calls review_deliverable_with_evaluator with specific criteria (HTTP 200, keyword present, no TODO placeholders, mobile-viewport usability, semantic markup). Only on PASS does the owner see a report_ready card with the live URL.

The deliverable ID (landing-page-bootstrap-<timestamp>) flows through metadata from the evaluator call to the emit_owner_card call. That link is enforced in code, not just prompt — see the gate.

What you see in the UI

One report_ready card in your Inbox when it\'s done, with two actions: "Visit your page" (opens the live URL) and "What\'s next?" (asks the CEO for follow-up ideas). Before that, depending on gate state, you may see a manual_task card asking you to connect a service, or a decision_required card asking for a missing onboarding answer.

While the playbook runs, the Boardroom shows the CEO\'s typing indicator and (if you have it enabled) a PlanIndicator strip counting down the steps. You don\'t see the tool calls, the git pushes, or the Railway API chatter. You see the result.

A concrete example

You complete onboarding with businessKind: "pilates studio", northStar: "book 20 intro sessions per month". You say "build my site." The CEO computes the slug pilates-studio-site, drafts copy about intro sessions with a clear CTA, renders a minimalist single-page site in a soft green accent, pushes it as a public GitHub repo, deploys it to Railway, waits for the health check, and sends you one card:

Your landing page is live!
Modern, minimalist, mobile-ready — built on what
you told me in onboarding.

→ Visit your page       (opens https://pilates-studio-site.up.railway.app)
→ What's next?          (asks the CEO for follow-ups)

Technical details

The playbook is a Markdown file; the engine loads it via buildPlaybookToolServer() in apps/engine/src/ceo/playbook-tool.ts. The CEO\'s system prompt is instructed to consult the playbook when the trigger matches. The step-by-step structure keeps the CEO from improvising on the hero path — improvisation is fine for novel asks, but "build me a site" is too common and too high-stakes to freestyle.

Specific failure modes are called out in the playbook: repo-name-taken → append a numeric suffix and retry; first Railway deploy fails → Coding Specialist reads logs, fixes, retries once inside its own turn; evaluator returns FAIL → re-delegate step 3 (render) with the feedback embedded; budget cap hit → pause and ask the owner to continue.

Hard rules baked into the brief: do NOT invent customer testimonials, metrics, or quotes. Do NOT emit a deploy approval card — the owner said "build me a landing page," that\'s unambiguous consent.

Related features

• The CEO agent — the runner that executes the playbook.
• Evaluator gate — why the report_ready card can\'t ship without PASS.
• Approvals Inbox — where the final card lands.

Related concepts

• CEO agent
• Agent evaluator

FAQ