PageAI full logo
Updated on

The Agentic Workflow for Landing Pages: Design, Code, Deploy (With Full Prompts)

The Agentic Workflow for Landing Pages: Design, Code, Deploy (With Full Prompts)

The agentic AI conversation is stuck on two topics: one-shot coding and infinite loops.
Landing pages, where most teams actually need agents, keep getting orphaned.

It's a weird gap. Landing pages are the lowest-risk, highest-frequency surface on the internet. Every startup has one. Every launch needs one. Every re-brand starts with one. Yet the playbook for a real agentic landing-page workflow (design agent + coding agent + verification agent + deploy) is basically undocumented.

This post is that playbook. Full prompts for each stage, the rails I actually run them on, and an honest account of the seam where most agentic landing-page attempts fall apart.

Sibling post to Long Running AI Coding Agents with the Ralph Loop and Docker Sandboxes Quick Start. Ralph is for infrastructure. Sandboxes are for safety. This one is the creative-plus-code pipeline where AI has to do both.

What You'll Learn

  1. The three broken seams in most agentic landing-page workflows
  2. A five-stage pipeline (plan β†’ design β†’ code β†’ verify β†’ deploy) with full prompts
  3. Where human-in-the-loop is actually necessary, and where it isn't
  4. How to skip most of the plumbing so the loop only does the creative work

Let's dive in. πŸŠβ€β™‚οΈ


The Design-to-Deploy Gap

Agentic AI has gotten shockingly good at a single stage at a time.

  • Design agents (Claude Design, Midjourney + layout tools) produce beautiful visual direction.
  • Coding agents (Cursor, Claude Code, Codex) produce real production code.
  • Verification agents (Playwright MCP, headless browser tools) can screenshot and compare.
  • Deploy agents (Vercel CLI, GitHub Actions) can push to production.

Each of these works. But the handoff between them is where everything goes sideways.

The design agent produces a static visual artifact the coding agent can't compile.
The coding agent produces a working Next.js site that looks nothing like the design.
The verification agent has no source of truth to verify against.
The deploy agent ships something that was never verified in the first place.

Every serious agentic landing-page attempt I've seen has died on one of these seams. Not because the agents are bad. Because no one owns the handoff format.


The Three Broken Seams

Before the playbook, a diagnosis. These are the three specific seams where agentic landing-page workflows fail.

Seam 1: Brief β†’ Design

Most people send a one-liner to a design agent: "Design a landing page for my SaaS." The agent returns a visual direction that looks nice, but there's no shared contract with downstream agents. No design tokens. No breakpoint logic. No component inventory.

The coding agent can't convert "looks kinda like Linear but warmer" into TypeScript, so it makes its own choices. The final site diverges from the design from the first commit.

Seam 2: Design β†’ Code

Even if you have a great design, the output format of most design agents is a screenshot, an image, or a single-file React artifact with inline styles. The coding agent has to reverse-engineer the structure from a picture, which loses accessibility, responsive logic, and state.

This is why so many AI-generated landing pages look almost right. Because almost is what you get when you translate a JPG into JSX.

Seam 3: Code β†’ Verify β†’ Deploy

Coding agents produce code that compiles. That's a low bar. Does the rendered site actually match the design direction? Does it pass Core Web Vitals? Is the copy on the hero the copy that was briefed? Without a verification agent that can visually compare, you're shipping blind.

And the deploy step assumes someone already answered the SEO, meta, sitemap, robots, and OG-image questions. Spoiler: nobody did.


The Five-Stage Agentic Pipeline

Here's the pipeline I run. Each stage has a specific job, a specific output format, and a prompt you can copy.

   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”   β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”
   β”‚ 1. Plan │──▢│2. Design│──▢│ 3. Code │──▢│4. Verify│──▢│5. Deployβ”‚
   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                    β–²            β”‚
                                    β”‚            β”‚ (on fail)
                                    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

The loop-back from Verify to Code is what makes this agentic, not just sequential. The Verify stage runs visual and functional checks; if it fails, Code re-runs with a delta prompt.

Stage 1: The Plan Agent (Brief β†’ PRD)

Job: convert a rough human-language brief into a structured PRD that every downstream agent can consume.

Input: 2–5 sentences from you.
Output: a JSONC file with product name, positioning, target audience, tone, section list, primary keywords, and CTA target.

Prompt:

# Role
You are a Landing Page Planning agent. Your job is to convert a short product brief into a structured JSONC file that every downstream design / coding agent will consume.

# Input
A 2–5 sentence product description from the user.

# Output format
Respond ONLY with a JSONC file (JSON with comments). Structure:

```jsonc
{
  "product": {
    "name": "string",
    "one_line_pitch": "string, <70 chars",
    "audience": "string",
    "tone": "string, e.g. 'confident, dev-native, minimal hype'"
  },
  "seo": {
    "primary_keyword": "string",
    "secondary_keywords": ["string"],
    "meta_description": "string, 150-160 chars"
  },
  "sections": [
    // ordered list, one per section
    { "type": "hero", "headline": "string", "subheadline": "string", "cta": { "label": "string", "href": "string" } },
    { "type": "features", "count": 3 },
    { "type": "pricing", "tiers": ["free", "pro", "team"] },
    { "type": "testimonials", "count": 3 },
    { "type": "faq", "count": 6 },
    { "type": "final_cta" }
  ]
}
```

# Rules
- Push back on vague briefs. If the audience or tone is unclear, ask one clarifying question before producing the JSONC.
- Keep the `one_line_pitch` under 70 characters. This ends up as the hero subheadline AND the `<title>` tag.
- `primary_keyword` is the single most important keyword for SEO. Pick one, not three.
- Section order matters. Default to hero β†’ problem/solution β†’ features β†’ pricing β†’ testimonials β†’ FAQ β†’ final CTA unless the brief demands otherwise.

Why JSONC? Because every downstream agent gets a typed, grep-able, diff-able contract. Not a paragraph. Paragraphs are where intent goes to die.

Stage 2: The Design Agent (PRD β†’ Art Direction)

Job: produce the visual direction as a structured set of design tokens, not as a picture.

Input: the JSONC from Stage 1.
Output: a theme.json with color tokens, typography scale, spacing, and a reference URL to a public inspiration site (for the coding agent to visually calibrate against).

Prompt:

# Role
You are a Landing Page Design agent. You receive a PRD JSONC and output an art-direction manifest that a coding agent can implement deterministically.

# Input
A PRD JSONC file from the Planning agent.

# Output format
Respond ONLY with a JSONC file:

```jsonc
{
  "palette": {
    "background": "hex",
    "foreground": "hex",
    "primary": "hex",
    "secondary": "hex",
    "accent": "hex",
    "muted": "hex"
  },
  "typography": {
    "sans_font": "string, Google Font name",
    "display_font": "string, Google Font name",
    "scale": "1.25" // typographic scale ratio
  },
  "spacing": {
    "section_padding_y_desktop": "number in px",
    "section_padding_y_mobile": "number in px",
    "container_max_width": "number in px"
  },
  "dark_mode": {
    "enabled": true,
    "strategy": "class" // or "media"
  },
  "visual_references": [
    // 1–3 public landing pages whose look is directionally right
    { "url": "https://linear.app", "why": "dense but breathable spacing" }
  ]
}
```

# Rules
- Pick a palette that matches the tone from the PRD. Confident + minimal β†’ higher contrast. Warm + approachable β†’ softer hues.
- Dark mode is on by default for dev-native audiences. Off by default for consumer audiences.
- Always include at least one `visual_reference` URL. That's the coding agent's calibration anchor.
- Never embed images. Tokens + references only.

Notice what this agent is not doing: it's not producing a picture. It's producing tokens. The picture emerges downstream when the coding agent implements the tokens.

Stage 3: The Code Agent (Tokens β†’ Next.js Project)

Job: implement the PRD + theme into a production Next.js codebase.

Input: the two JSONC files from Stages 1 and 2, plus any existing repo.
Output: a working Next.js + TypeScript + Tailwind + Shadcn UI project that builds cleanly, with SEO, blog, and legal starters.

This is the stage where you'd normally use Claude Code, Codex, or Cursor. Prompt:

# Role
You are a Landing Page Coding agent working inside a Next.js project.

# Context
You are given two JSONC files in `.agent/`:
- `.agent/prd.jsonc`: product plan and section list
- `.agent/theme.jsonc`: art direction

# Stack (non-negotiable)
- Next.js (app router)
- TypeScript strict
- Tailwind CSS
- Shadcn UI
- next-themes for dark mode

# Required files
1. `app/layout.tsx`: root layout with `<Providers>` for next-themes and a font preload that matches `theme.typography.sans_font`.
2. `app/page.tsx`: one section per PRD entry, in order, using components from `components/landing/*`.
3. `app/sitemap.ts`: dynamic sitemap including `/` and any generated blog posts.
4. `app/robots.ts`: allow-all robots with the sitemap URL.
5. `app/og.tsx`: dynamic OG image using `@vercel/og`, reading the product name from `prd.jsonc`.
6. `app/not-found.tsx`: themed 404.
7. `app/terms/page.tsx` and `app/privacy/page.tsx`: starter legal pages.

# Design tokens
Write Tailwind `theme.extend.colors` tokens from `theme.palette`. Map them to Shadcn CSS variables so Shadcn primitives adopt the theme automatically.

# SEO
- `export const metadata` on every route with title, description, canonical, and openGraph.
- Reuse `prd.seo.primary_keyword` in the hero H1 naturally (no keyword stuffing).
- Generate `public/robots.txt` pointing at `sitemap.xml`.

# Verification hooks
After generating all files, run:
- `pnpm type-check` must pass
- `pnpm lint` must pass
- `pnpm build` must succeed
- `pnpm playwright test e2e/landing.spec.ts` runs if the spec exists

If any check fails, fix it. Do not output prose. Output code.

# Done criteria
A green `pnpm build`, a green `pnpm playwright`, and a running `pnpm dev` that renders all sections from the PRD in order. That's the bar.

Key detail: the agent has explicit verification hooks in the prompt. This is what the Ralph Loop calls the "self-verifying harness". If the agent can't verify its own output, you'll get slop. Non-negotiable.

Running this pipeline from scratch is a lot.
PageAI bakes all five stages plus the shipping layer (SEO, blog, legal, deploy) into one prompt-to-codebase flow.

Stage 4: The Verify Agent (Visual + Functional QA)

Job: confirm that what the Code Agent produced actually matches the design and the PRD.

Input: a running dev server + the two JSONC briefs.
Output: a pass/fail report with deltas.

Prompt (designed to run with Playwright MCP):

# Role
You are a Landing Page Verification agent. You browse the rendered site and check it against the PRD and theme contracts.

# Checks (in order)
1. **Section completeness**: open `/` and confirm every `sections[i].type` from `prd.jsonc` is rendered and in the correct order.
2. **Content accuracy**: for each section, confirm the headline/subheadline/CTA text matches `prd.sections[i]` verbatim.
3. **Responsive correctness**: screenshot at 375px, 768px, 1280px, 1536px. Confirm no horizontal overflow, no text clipping, no CTA below-fold at desktop.
4. **Dark mode parity**: toggle dark mode. Confirm all sections render with the dark palette. No white backgrounds leaking through.
5. **Meta check**: fetch `/` via `curl` and confirm `<title>`, `<meta name="description">`, canonical, OG, and Twitter tags match `prd.seo`.
6. **SEO plumbing**: GET `/sitemap.xml` and `/robots.txt`. Both must return 200 and be well-formed.

# Output
A report like:
```markdown
## Verify Report
- [x] Section completeness
- [x] Content accuracy
- [ ] Responsive correctness: 375px hero CTA clipped
- [x] Dark mode parity
- [x] Meta check
- [x] SEO plumbing

### Deltas
- Hero CTA at 375px is partially cut off. Fix: `flex-wrap` on the CTA row.
```

If any check fails, emit the delta as a follow-up prompt for the Code Agent.

This is the stage nobody runs and everyone needs. Running pnpm build is not verification. Verification is a second agent that actually looks at the site.

Stage 5: The Deploy Agent

Trivial if Stages 1–4 passed. Non-trivial if they didn't.

# Role
You are a Deploy agent for a Next.js landing page.

# Prerequisites
- Verify Report must be all green (all checks pass).
- `main` branch must be clean (`git status` returns nothing).

# Steps
1. Confirm `VERCEL_TOKEN` is present in the environment.
2. Run `vercel link --project $PROJECT_ID` if not already linked.
3. Run `vercel env pull` to sync env.
4. Run `vercel deploy --prod`.
5. Capture the deployment URL.
6. Run Lighthouse against the production URL. Target: Perf β‰₯ 90, SEO = 100, Accessibility β‰₯ 95.
7. If Lighthouse fails, open an issue with the delta report. Do not re-deploy automatically.

At this point you have a live, verified, Lighthouse-graded landing page.


The Seam You're About to Hit

If you set this up from a blank repo, you will hit the same wall the graveyard of agentic landing page attempts hit before you: plumbing.

The Code Agent prompt has ten required files. Each one has a reasonable amount of boilerplate. The Verify Agent assumes you've already wired up Playwright MCP. The Deploy Agent assumes you have a Vercel project and a clean main branch.

Each is solvable. But each one dilutes the creative work (the PRD, the theme, the hero copy) with mechanical plumbing the AI can trivially produce on a foundation that already exists.

This is the job PageAI solves: it ships the foundation so your prompt budget goes toward the creative direction, not the scaffolding.

In practice, the PageAI version of this five-stage pipeline looks like:

  1. Stage 1 (Plan): PageAI runs a planning agent internally. Your prompt is the brief.
  2. Stage 2 (Design): PageAI's design agent produces palette + typography + section layout. Drag-and-drop editor lets you override any token.
  3. Stage 3 (Code): PageAI's coding agent emits the full Next.js + TypeScript + Tailwind + Shadcn UI codebase with SEO, blog, and legal starters pre-wired.
  4. Stage 4 (Verify): the output is verified against the PRD before you see the preview.
  5. Stage 5 (Deploy): 1-click Vercel deploy from the preview.

You still write the creative brief. You still review the design tokens. You still make the "move this section up, change that accent" calls. What you don't do is write the sitemap.ts for the thirteenth time.


What to Add on Top

Once the five-stage pipeline produces a working landing page, the useful additions are almost all continuous. They run after every prompt, not as separate agents:

The combined stack (agentic pipeline + Ralph Loop + Sandboxes + Cursor rules + hooks) is what "agentic landing page" actually means in practice. Not a single agent. A choreography of agents, each with a narrow job and a typed output format.


A Minimal Example

Here's the minimum viable version of this whole thing for a weekend project. One script, five stages, hard-coded to the "ship a landing page" goal:

#!/usr/bin/env bash
# agent-landing.sh
# Usage: ./agent-landing.sh "a short product brief"

set -euo pipefail

BRIEF="$1"
AGENT_DIR=".agent"
mkdir -p "$AGENT_DIR"

echo "β†’ Stage 1: Plan"
claude -p "$(cat prompts/plan.md)" --input-text "$BRIEF" \
  > "$AGENT_DIR/prd.jsonc"

echo "β†’ Stage 2: Design"
claude -p "$(cat prompts/design.md)" --input-file "$AGENT_DIR/prd.jsonc" \
  > "$AGENT_DIR/theme.jsonc"

echo "β†’ Stage 3: Code"
claude -p "$(cat prompts/code.md)" --dangerously-skip-permissions
# Code agent reads both .agent/ files, writes the project, runs type/build/test

echo "β†’ Stage 4: Verify"
pnpm dev &
DEV_PID=$!
sleep 4
claude -p "$(cat prompts/verify.md)" \
  --mcp-server playwright \
  > "$AGENT_DIR/verify-report.md"
kill $DEV_PID

if grep -q "\[ \]" "$AGENT_DIR/verify-report.md"; then
  echo "βœ— Verify failed. Re-run Stage 3 with deltas from $AGENT_DIR/verify-report.md"
  exit 1
fi

echo "β†’ Stage 5: Deploy"
vercel deploy --prod

Drop that in a repo, put the four prompts from this post in prompts/, and you have the minimal agentic landing-page pipeline.

Will it work out of the box? Not quite. The Code Agent stalls without a starter project structure. You'll need to either (a) pre-seed the repo with a Next.js starter that has Shadcn and the Tailwind config, or (b) let the Code Agent scaffold from scratch (slower, more error-prone).

Or you can skip the seeding problem and use PageAI's output as the starter, and run the Ralph Loop on top of that. That's the pragmatic version.


The Shipping Layer, Again

Same mental model as the Claude Artifact to Production post: a landing page is a system, not a surface. Agentic pipelines fail when each agent produces a surface in a different format that can't be composed. They succeed when the contracts between stages are typed and the scaffolding is already there.

Whether you run the five-stage pipeline yourself or let PageAI run most of it for you, the principle is the same: own the creative brief, automate the shipping layer.

Skip Stages 3, 4, and 5 πŸš€PageAI already runs the plan β†’ design β†’ code β†’ verify β†’ deploy loop. Your prompt goes in, a production Next.js landing page comes out. The shipping layer is already there.See how PageAI ships

Next Steps

The Agentic Workflow for Landing Pages: Design, Code, Deploy (With Full Prompts) | PageAI - the best AI website builder for professionals