landingforge

LandingForge

A Claude Code plugin that manufactures SaaS, dev-tool, and B2C consumer-app landing pages to a spec — and refuses to ship below a quality bar.

AI ships the statistically-average landing page because it generates in one shot: no committed strategy, no committed visual point of view, no scoring. Average is forgettable. LandingForge splits the work into gated specialist phases, each writing an artifact the next reads, all calibrated against a distilled knowledge base and an anti-slop blocklist — then it scores the result and loops until it clears a threshold.

Runs on Claude Code (plugin), Codex (skills-capable builds), and Kimi Code (plugin).

It built its own landing page

★ 9.1 / 10 · conversion 9.5 · visual 9.7 · discoverability 8.7 · craft 8.3 · CWV measured: LCP 1.389s, CLS 0.001, TBT 0ms

See the live page · read the full scorecard — including the seven checks it lost · read the whole artifact chain (brief → copy → tokens → design → site → score)

The scoring loop caught three real defects in its own page and one in the engine itself: an og:image that didn't exist, an accent sprayed across 13 above-fold surfaces, a page that overflowed horizontally on mobile, and — routed back to phase 3 — a token generator emitting a caption color at 3.89:1, below WCAG AA, on every page it would ever build. All fixed, all itemized in the scorecard.

A caveat the scorecard states in its own words: none of these axes measure conversion. No A/B data enters the loop. The score enforces a floor of craft; it does not predict revenue.

The four axes

Every page is optimized and scored across:

1. Conversion to a single target action
2. Organic SEO (on-page + structured data)
3. AI-search / GEO (citation by ChatGPT / Perplexity / AI Overviews / Claude)
4. Visual clarity and craft

The pipeline (/landing-build)

Gated phases — each surfaces its artifact for approve / revise / restart:

The phase-8 loop routes sub-threshold fixes back to the owning phase (bounded at 3 iterations). Ship bar: >= 8.0 / 10 overall, no axis below 6.0.

Run any phase standalone: /landing-strategy, /landing-copy, /landing-design, /landing-discoverability, /landing-optimize, or audit any existing page with /landing-critique <url>.

Install

Claude Code

/plugin marketplace add NmadeleiDev/landingforge
/plugin install landingforge@landingforge

Start a fresh session. Skills appear as /landing-build, /landing-critique, and so on.

Codex

For a skills-capable Codex build (one that auto-discovers ~/.codex/skills/) — see CODEX.md:

git clone https://github.com/NmadeleiDev/landingforge.git
cd landingforge
codex/install.sh          # idempotent; re-run after git pull

Kimi Code

/plugins install https://github.com/NmadeleiDev/landingforge

Then /new. See KIMI.md.

Upgrading later: UPGRADE.md, or just tell your agent "upgrade LandingForge".

Prerequisites

LandingForge degrades gracefully — nothing below is a hard blocker, but each absence costs you a measured signal, and the scorecard records the degraded mode explicitly rather than pretending.

The browser is bundled. Every rendered-page check drives scripts/browse, a small Playwright CLI that ships in this repo — no globally-installed browser tool is required, and its command surface is versioned with the prompts that call it.

The generated site itself needs nothing beyond Node/Bun — it is a self-contained Astro project.

Conventions (load-bearing — keep these stable)

• Skills are user-facing and named landing-* (/landing-build, /landing-critique).
• Agents are internal specialists named lp-* (lp-strategist, lp-scorer).
• Artifacts for a page are written to .landingforge/<page-slug>/ in the target repo (gitignored); generated site code lands in .landingforge/<page-slug>/site/.
• SEO + GEO is owned by claude-seo — LandingForge delegates to it and does not maintain a parallel SEO/GEO knowledge base.
• Stack the engine builds on: Astro (standalone) / Next.js (in-app) + Tailwind v4 + shadcn/ui (+ Base UI) + Tailark + Motion.
• The engine never provisions or deploys. It emits page code and commented integration stubs; it holds no secrets and touches no accounts.

Layout

.claude-plugin/   plugin.json + marketplace.json (Claude Code)
agents/           lp-* specialist subagents          <- SOURCE
skills/           landing-* user-facing skills       <- SOURCE
references/       the distilled knowledge base (the engine's brain)
scripts/          the runtime: browse (bundled browser), score, gen-tokens,
                  capture-og, gen-logo + sync-adaptations and check
codex/            install.sh for skills-capable Codex builds
.codex/ .kimi/    GENERATED per-CLI adaptations — do not edit (references/ is shared)
.github/          CI: integrity, adaptation drift, typecheck, browser smoke test

references/ is the substance of this project — the conversion, copy, visual, schema, and CWV rule sets every agent reads before it acts. If you fork LandingForge to fit your own taste, that directory is what you edit.

Contributing

Issues and PRs welcome. Three things to know:

1. references/ is the product. A change there changes every page the engine ships — state which rule you are adding or overturning, and why.
2. .codex/ and .kimi/ are generated. Never edit them. skills/ and agents/ are the single source; the per-CLI adaptations are derived by scripts/sync-adaptations.ts, which carries all the per-CLI knowledge in one reviewable rule table. Edit the source, then:

   cd scripts && npm install
   npm run sync        # regenerate .codex/ and .kimi/
   npm run ci          # integrity checks + drift check + typecheck
   

   CI fails on any drift, so a hand-edited copy cannot reach main. (It used to: the router advertised six shipped skills as "planned" for months, and the session-notes feature existed in all 32 Codex/Kimi files and none of the 17 Claude ones.)
3. Bump "version" in .claude-plugin/plugin.json and both Kimi manifests with any meaningful change — the upgrade flow keys on it, and CI checks that all three agree.

License

MIT.