Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add NmadeleiDev/landingforge --skill landing-buildgit clone --depth 1 https://github.com/NmadeleiDev/landingforgeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/nmadeleidev/landingforge/landing-build)<a href="https://agentmods.dev/skills/nmadeleidev/landingforge/landing-build"><img src="https://agentmods.dev/badge/skills/nmadeleidev/landingforge/landing-build/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/nmadeleidev/landingforge/landing-build"><img src="https://agentmods.dev/badge/skills/nmadeleidev/landingforge/landing-build.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00197 | $0.07233 |
| Opus 5 | $0.00098 | $0.03617 |
| Sonnet 5 | $0.00039 | $0.01447 |
| Haiku 4.5 | $0.00020 | $0.00723 |
Grade A, and why
landing-build scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 340 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Running an
lp-*agent on Codex. Codex has no parallel subagent tool, and this pipeline is sequential and gated anyway. Wherever this file says to spawn or run an agent inline, it means: read.codex/agents/<name>.mdand follow its full body verbatim as that phase's operating instructions, one phase at a time.
LandingForge Build Orchestrator (Gated Phase Pipeline)
Manufacture a landing page to a spec by running the LandingForge phases as a
chain of gated specialist steps, then QA the built page and score it to a ship
threshold. Each gated phase (1, 2, 3, 3.5, 4) spawns its lp-* agent via the Task
tool, writes one artifact to .landingforge/<slug>/, then surfaces that artifact to the
user for approval before the next phase runs. No phase starts until the prior phase's
artifact is approved. Phase 3.5 (lp-brandmark) sits between design and build: it is a
generative step (it produces + selects the logo/favicon/OG asset set) and so carries the
same approve/revise/restart gate — phase 4's lp-builder then wires that asset set into the
page. After phase 4 lands an approved site/, the pipeline runs the back half on
the built page: phases 5-7 (discoverability / conversion QA / performance) are
QA/report phases — each spawns its lp-* agent inline to audit the BUILT page
and emit a report (they do not carry the approve/revise/restart user gate of 1-4) —
and phase 8 (lp-scorer) scores the four axes from those three reports plus
design.md / tokens.css / the built page and runs the bounded score loop (max 3)
that routes each failing check back to its owning phase, re-runs only that phase + rebuild,
and re-scores. The full pipeline is now phases 1-8, end to end.
Path resolution. All
references/…and.codex/agents/…paths below are relative to the plugin root ({{LANDINGFORGE_ROOT}}, the dir containingplugin.json), not this skill's own folder — the knowledge base inreferences/and the agents in.codex/agents/are the shared brain every LandingForge skill and agent reads, and they live at the plugin root on purpose. If a barereferences/scorecard.mdor.codex/agents/lp-scorer.mddoes not resolve from the current directory, prefix it with{{LANDINGFORGE_ROOT}}/.
Delegation pattern. This mirrors the
claude-seoseo-auditorchestrator: detect the work, spawn specialist agents (inline) to do it, persist each specialist's output as an artifact, then aggregate. The difference here is the gate —seo-auditfans its specialists out in parallel and aggregates once; LandingForge runs its phases sequentially and gated, pausing for user approval after each artifact because every phase's artifact is the next phase's input.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 340 lines · 197 tokens per session scan A 0db8524a8279
landing-build is a skill published in the GitHub repository NmadeleiDev/landingforge (1 stars, last pushed 1mo ago), licensed MIT. It adds 197 tokens to every session and 7,233 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
mobile-responsive
Mobile-first responsive design patterns for sales funnels. Ensures every page works flawlessly on all screen sizes with proper touch targets, readable typography, and fast load times.
page-speed
Page speed optimization guidelines and implementation patterns. Ensures all funnel pages meet Core Web Vitals targets for LCP < 2.5s, FID < 100ms, and CLS < 0.1.
porting-gotchas
Read before writing markup for a section ported from WordPress. Covers the layout failures that pass a height check, silent CSS failures, per-builder quirks, and the rules for measuring correctly. Use when porting a WordPress or page-builder site to any stack, when a diff shows a delta you cannot explain, or when a…
repro-admin
Reproduce an EmDash admin UI bug. Attach a container, start the demo dev server, drive the admin with agent-browser using the dev-bypass session, and capture the reproduction as screenshots plus a replayable transcript.
create-site
Creates a new Power Pages code site (SPA) using React, Angular, Vue, or Astro. Guides through the full process from initial concept to deployed site: requirements discovery, scaffolding, component planning, design, implementation, validation, and deployment. Use when the user wants to create, build, or scaffold a new…
top-design
Create award-winning, immersive web experiences at the level of Awwwards-featured agencies. Use when the user mentions "Awwwards quality", "make my site stunning", "scroll animations", "parallax storytelling", "cinematic web design", "portfolio site", or "brand experience". Also trigger when elevating a standard…