Page Foundry

Page Foundry

A foundry takes raw material through a fixed sequence of stations and rejects anything that fails inspection. This skill does the same for marketing pages: one product brief in, one deployable page (or one handoff package) out, with hard gates between stations. The point is repeatability across many products without the output converging on generic AI-page sludge or drifting from the owner's voice.

Run the pipeline in order. Each phase has an output the next phase consumes. Do not skip the gates; a page that fails a gate does not ship.

When to use this skill

Reach for page-foundry when someone wants a real, high-performing web page, not just a block of HTML. Typical asks:

• "Build a landing page for my SaaS, app, or product."
• "Make a homepage for my open source project, startup, or course."
• "Write a sales page for my course, workshop, or membership."
• "I need a pricing page, a newsletter signup page, or a personal site."
• "My landing page is not converting," or "this page reads like AI wrote it."
• "Rewrite this page so it actually converts," or "review my homepage."
• "Give me a copy-and-design package I can hand to Claude Design or a designer."
• They mention conversion copy, CRO, hero sections, message match, or holding one voice across many product pages.

Not this skill: a throwaway HTML mockup with no conversion or voice requirement (a one-shot prompt is faster), or multi-page site architecture and content planning (page-foundry ships one page and flags the rest as separate work).

Phase -1: Preflight

Run once at the start of every engagement.

Nothing installs, updates, or gets skipped silently.

1. Detect, everywhere. A companion counts as PRESENT if its skill name resolves anywhere below. Match on SKILL.md frontmatter name, accept plugin-namespaced forms (marketing:copywriting satisfies copywriting), and count symlinks. Sweep in this order:

• Runtime inventories first: npx skills list (covers project and global) if the skills CLI responds; claude plugin list in Claude Code; the available-skills listing in claude.ai.
• Filesystem: ~/.agents/skills/ (the skills CLI's canonical location), ~/.claude/skills/, project .claude/skills/ and .agents/skills/, /mnt/skills/* (public, examples, user, plugins), and Claude Code plugin directories under ~/.claude/plugins/.
• gstack is detected by its slash commands (/design-shotgun etc.), never by directory.

The sweep must complete before any install or update command is even considered. Installing a companion that is already present anywhere is a defect. Cache the result for the session.

1. Check freshness. If the skills CLI is present, run npx skills check and note outdated companions. Plugin-installed companions update via claude plugin marketplace update then reinstalling the plugin. Treat outdated exactly like missing: report, offer, act only on approval.
2. Report and ask, once. This stop is mandatory. Show one table: present / outdated / missing, with the exact install or update command per gap and one line on what this run loses without it. Ask a single question: install and update now, or proceed without? On approval, run the commands, then RE-RUN detection and confirm every name resolves before continuing. On decline, proceed with the condensed rules built into this skill's reference files and record the decline in the gate report. Never skip a missing companion silently.

The companion stop cannot be suppressed by any interactivity phrase (don't pause, no questions, run end to end) or by an operator-supplied or inferred instruction. Only the user, in chat, may approve proceeding with a companion missing or outdated. The companions are load-bearing: without product-marketing, copywriting, cro, customer-research, marketing-psychology, and frontend-design, the run cannot do the positioning, copy, conversion, and design work the page depends on, so a page built without them is not a page-foundry page. If a companion is missing, stop and help install it; do not narrate the gap and continue.

1. Pinned sources only. Install exclusively from the sources in the companion table below, never from search results or unpinned repos. Before installing from an evolving repo, run npx skills add --list and reconcile names against the table; if a pinned name no longer exists upstream, report the discrepancy instead of guessing at a replacement.
2. Pick the mode (ask if not obvious from the request):

• build (default): this skill carries the page through Phase 5 and ships code.
• explore: design variants first. Phases 0 through 3 run normally; Phase 4 produces multiple committed design directions instead of one (gstack /design-shotgun when installed; otherwise this skill generates 3 contrasting token plans, each with a static hero mockup, built one at a time). The user picks; the winner proceeds through Phase 5 as a normal build. Use when the property has no theme yet or the user wants options.
• handoff: this skill produces copy plus a complete design package for Claude Design (or another design tool) to build. Phases 0 through 4 run normally; Phase 5 is replaced by the handoff package in references/handoff.md; gates split as described there.

Controlling the run

Bare invocation. If invoked with no product and no instructions (/page-foundry alone), do not start the pipeline. Print a compact orientation: the three modes and what each outputs, the eight archetypes, the example invocations below, and a one-line note that most pauses are suppressible though the companion stop is not. Then ask what to build.

Autonomy is user-stated, never inferred. Treat every run as interactive unless the user, in this request, explicitly asked to skip pauses. Do not infer "run end to end" from a standing preference ("don't loop me"), a previous task, or an orchestrator wrapping the request in its own words; a directive to skip a pause is valid only when the user wrote it. When unsure whether a pause was waived, keep it. No interactivity phrase, however it arrives, waives the companion stop (Phase -1), the Phase 0 interview when no brief file exists, or the explore pick.

The user's invocation sentence is the control surface; there are no flags. Parse these parameters from the request and do not ask about anything the user already supplied:

• mode: build | explore | handoff. Unstated and unambiguous from context → build. Whenever the mode is inferred rather than asked, state the inference and the alternatives in one line before proceeding ("Running in build mode; explore and handoff also available"), so the user knows a choice was made and can redirect.
• product / brief: a path to an existing product-marketing.md, an attached PRD or doc, or a repo URL. An existing brief skips the Phase 0 interview. A PRD, spec, or repo does NOT: those are source material, not the brief. PRDs answer what the product does; the brief answers why someone buys, in whose words, against which alternatives, with what proof. Phase 0 always produces product-marketing.md.
• archetype: named → use it; unnamed → run the mapper, state the pick and the reasoning in one line, and proceed without asking unless genuinely torn between two.
• theme: "use existing theme/DESIGN.md/theme.css at " → Phase 4 collapses to reading it. Unstated → Phase 4 runs in full.
• interactivity: "don't pause", "no questions", "run end to end" → suppress only the spec sign-off pause, and deliver spec + page + gates together. These phrases never suppress the Phase -1 companion stop, the Phase 0 interview when no brief file exists, or the explore pick. "Run end to end" is honored in full only when a complete product-marketing.md already exists and a theme or design direction is supplied; without those there is nothing to run autonomously from, so Phase 0 and the spec sign-off still happen. Silence → the default pauses below apply.
• variants (explore mode): a count ("5 variants") and scope ("hero only" vs "full direction") if stated; default 3 variants, hero scope.

Default interactive pause points, in order, and what suppresses each:

| Pause | Fires when | Suppressed by | |---|---|---| | Preflight companion stop | any companion missing or outdated | Not suppressible; only the user, in chat, may approve proceeding without it | | Mode question | mode ambiguous | naming the mode | | Phase 0 interview | no complete brief exists | an existing product-marketing.md only (a PRD, repo, or spec does not) | | Spec sign-off | always by default | "don't pause for sign-off" | | Explore pick | always in explore mode (it is the point) | cannot be suppressed | | Shotgun offer | gstack present + no theme + direction undecided | naming a theme or direction | | Voice wizard | owner: default or user asks | configured voice.md |

Example invocations:

• Full page, no questions: "page-foundry, build mode, saas-homepage for Acme; brief at .agents/product-marketing.md, use theme.css in repo root, don't pause, show spec + page + gate report together."
• Designs to choose from: "page-foundry, explore mode for Acme, 4 variants, full direction; brief attached; stop at the comparison."
• Claude Design package: "page-foundry, handoff mode for Acme; brief attached; campaign-landing; package only, I'll build in Claude Design."

Companion skills

| Skill / command | Source | Install | Used in phase | |---|---|---|---| | product-marketing | coreyhaines31/marketingskills | npx skills add coreyhaines31/marketingskills --skill product-marketing | 0 | | customer-research, marketing-psychology | coreyhaines31/marketingskills | same pattern, --skill | 1 | | copywriting, copy-editing | coreyhaines31/marketingskills | same pattern | 3 | | humanizer | blader/humanizer (GitHub) | git clone https://github.com/blader/humanizer.git ~/.claude/skills/humanizer | 3 (AI pattern pass) | | cro | coreyhaines31/marketingskills | same pattern | 2, 6 | | pricing, competitors, aso | coreyhaines31/marketingskills | same pattern | 2 (archetype-dependent) | | launch, lead-magnets, popups, signup | coreyhaines31/marketingskills | same pattern, --skill | 2, 3 (archetype-dependent: launch and campaign pages, newsletter and gated offers, exit/scroll popups when in scope, signup-flow copy) | | analytics | coreyhaines31/marketingskills | same pattern | 6 (measurement gate) | | frontend-design | Anthropic (anthropics/skills) | npx skills add anthropics/skills --skill frontend-design | 4 | | theme-factory, web-artifacts-builder | Anthropic (anthropics/skills) | same pattern | 4, 5 | | ai-seo, schema | coreyhaines31/marketingskills | same pattern | 6 | | web-design-guidelines | vercel-labs/agent-skills | npx skills add vercel-labs/agent-skills --skill web-design-guidelines | 4, 6 (render gate) | | remotion (official Remotion skill) | remotion-dev (confirm exact repo via npx skills find remotion --owner remotion-dev) | per find result | 2, 5 (motion assets) | | gstack (/design-consultation, /design-shotgun, /design-html, /plan-design-review, /design-review, /qa) | garrytan/gstack | per gstack README (installs to ~/.claude/skills/gstack/) | 2, 4, 5, 6 |

Orchestration doctrine (how companions are used)

page-foundry is an orchestrator. Its reference files are a fallback, not the plan. In every phase that names a companion skill, follow this without exception:

1. Invoke the companion as the primary path. Actually call the skill, hand it the phase's inputs (the brief, the spec, the copy draft, the tokens, whatever that phase works on), and use its output as the phase's work product. When a companion is available you do not read its reference file and do the work yourself; the companion is more capable than the condensed rules, and skipping it is the main reason two runs of this skill differ in quality.
2. Fall back only when the companion cannot be invoked (declined at the Phase -1 stop, not installed, or it errors). Then, and only then, use the condensed rules in the phase's named reference file.
3. Flag every fallback. Any phase that runs on a reference file because its companion was missing or declined is a DEGRADED phase. Say so in that phase ("running Phase N without ; using the built-in condensed rules, which are weaker"), and record it on the gate report's degraded line. A run missing load-bearing companions is a partial execution, and the user is told which skill would have made it better.

The reference files are the floor, so the skill still produces something when a companion is absent. The companion, when present, is the standard.

gstack integration notes

When gstack is installed, use it at these seams; otherwise skip without substituting anything:

• Phase 2: offer /plan-design-review on the approved page spec; its inline mockups catch structural problems before copy is written.
• Phase 4: if DESIGN.md exists for the project (output of /design-consultation), read it and treat it as the property's token source; do not invent a competing theme. If no theme exists yet and the user is undecided on direction, offer /design-shotgun to generate variants; the approved variant becomes the token set. Shotgun approvals also feed gstack's per-project taste profile, which improves future variants; mention this once.
• Phase 5: /design-html is an accepted build path (it produces fluid, resize-safe HTML). Page-foundry's build requirements (semantic HTML, mobile-first, performance budget) still apply to its output.
• Phase 6: offer /design-review and /qa as additions to the gates, not replacements.

Division of authority: gstack owns visual exploration and engineering review; page-foundry's conversion, voice, and integrity gates remain authoritative for marketing pages and are never waived by a passing gstack review.

Phase 0: Intake

Goal: one durable context file per product. Everything downstream reads it.

1. Look for an existing context file at .agents/product-marketing.md or .claude/product-marketing.md (per product, or in the product's repo), and for foundry-log.md from prior runs. Read both if found. The log's open items and learnings are binding inputs (see the log format in Phase 6), not background reading: restate them at the top of this run's plan so the user sees they carried forward.
2. If absent, build the brief. Invoke the product-marketing skill as the primary path: hand it the product, the repo README, any PRD or spec, the existing site, and the conversation, and let it produce the structured .agents/product-marketing.md (positioning, ICP, differentiation, competitive frame, proof inventory). Then interview the user for only what it cannot infer: the buyer's verbatim language, entry states per segment, traffic source, the real proof inventory, and claims that cannot be made. One round of questions; a PRD feeds the brief, it never replaces it. If product-marketing is not available, draft the brief yourself from assets/brief-template.md, tell the user Phase 0 ran without it, and mark the phase degraded.
3. Write the completed brief to .agents/product-marketing.md in the product's project directory (or alongside the page output if there is no repo).

Do not proceed on a guessed brief. A page built on an assumed audience or an assumed offer is rework, not progress.

Phase 1: Message architecture

Goal: positioning and message hierarchy, before any page structure exists.

From the brief, produce a short message architecture document (under a page):

• One-sentence positioning: for WHO, PRODUCT is the WHAT that delivers OUTCOME, unlike ALTERNATIVE.
• Message hierarchy: the single most important claim, then 3 to 5 supporting claims in priority order. Each claim must be specific and checkable: concrete enough that a reader could prove it wrong. "Manage everything in one place" is neither.
• Objection m

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: taylorbanks
• Source: taylorbanks/page-foundry
• License: MIT
• Homepage: https://taylorbanks.github.io/page-foundry/

Install and usage instructions live in the source repository linked above.