Landing page pipeline

Landing Page Pipeline

Produce a complete page from the strongest available evidence. Keep the process adaptive, the design specific, the implementation appropriate to its delivery mode, and every factual claim traceable.

Optional skill coordination

• Treat design-taste-frontend and impeccable as optional collaborators, not bundled dependencies.
• Use an available design-taste-frontend skill during art direction and implementation to strengthen concept specificity, composition, typography, and originality.
• Use an available impeccable skill after functional implementation for focused interface critique, refinement, responsive review, and browser QA.
• Follow each selected skill's own instructions when it triggers. Keep this pipeline authoritative for intake, delivery mode, factual integrity, project creation, validation, and completion reporting.
• When either skill is unavailable, continue with the built-in design and accessibility references without reducing the expected quality bar.

Project preflight

1. Inspect the current working directory, repository guidance, working tree, and existing application before any write.
2. Work in place when the user explicitly asks to modify an existing web project suitable for the request.
3. Create a new project when the request is for a new landing page and the current directory is a protected template, is unrelated, or is not a suitable web project. Infer a safe slug and run node "<skill-directory>/scripts/create-project.mjs" --slug <project-slug>. Resolve <skill-directory> as the directory containing this SKILL.md; do not assume a fixed installation path.
4. Use --destination <absolute-path> only when the user requested a location or the environment requires one. The default is ~/Documents/GitHub/<project-slug>.
5. Continue every later phase exclusively in the reported destination. Do not ask the user to clone a repository or repeat setup already handled by the script.
6. Never overwrite an existing destination. Request a different project name or explicit destination when the inferred destination already exists.
7. When the request explicitly targets a reusable template or this skill itself, modify that source only instead of creating a landing-page project.

Reference routing

• Read references/intake-system.md when the brief is incomplete, a questionnaire must be parsed, or any interview is needed.
• Read references/delivery-modes.md before selecting public content behavior, drafting copy, or deciding how demonstrations and unknown facts should appear.
• Read references/content-safety.md before normalizing the brief or drafting public copy, and again when reviewing factual placeholders.
• Read references/design-directions.md before proposing art direction. Use it as the independent baseline even when an optional design skill is available.
• Read references/accessibility-and-qa.md before implementation and again before browser QA.
• Read references/starter-prompt.md only when the user asks for a reusable kickoff prompt. Repository isolation remains automatic and must not be added to their ordinary project prompt.
• Run node "<skill-directory>/scripts/validate-site.mjs" --root "<project-root>" during validation. Prefer the generated project's repository-local skill path when present. Do not treat heuristic warnings as proof of visual quality or accessibility.

Source priority

Resolve conflicts in this order:

1. Follow explicit current user instructions.
2. Preserve supplied approved copy, brand materials, assets, and factual evidence.
3. Follow an approved briefs/current.md.
4. Use clearly recorded assumptions.

Never hide a conflict by silently rewriting supplied material.

Phase A: Inspect

1. Complete the project preflight, then read the current request and repository guidance from the active project.
2. Inspect the working tree, current page, briefs/current.md, questionnaire, copy, assets, references, design tokens, and relevant components.
3. Preserve unrelated user work.
4. Classify the request as a new page, redesign, or refinement.
5. Extract answers already present before asking anything.

Phase B: Select behavior

1. Infer intake, collaboration, and delivery modes when the request makes them clear.
2. Use guided-interview plus guided for an incomplete ordinary client project.
3. Use quick-start plus autonomous for an explicitly rapid, experimental, internal, or autonomous project.
4. Use complete-brief when a questionnaire or equivalent brief exists, including partial versions.
5. Present mode choices only when choosing would materially help.

Treat all three settings separately. Accept I don't know, Not applicable, Recommend something, and Use your judgment as valid answers.

Select delivery mode as follows:

• Use prospecting-demo for quick demos, speculative redesigns, independent concepts, portfolio pieces, fictional brands, and work intended to demonstrate an opportunity to a potential client.
• Use client-staging for a real business or client page that is still awaiting approved facts, assets, integrations, or stakeholder review.
• Use production only when the user wants a launch-ready result and the required factual, legal, operational, and integration evidence is available.

Infer prospecting-demo without asking when the request clearly mentions a concept, alternative, pitch, prospect, potential client, fictional brand, or quick demo.

Phase C: Clarify selectively

1. Identify only missing information that affects content, conversion strategy, architecture, factual accuracy, or visual direction.
2. Ask no more than three concise questions at once and adapt the language to the user's apparent website familiarity.
3. Prefer focused questions over broad prompts.
4. Continue without pausing when a strong result can be produced from available information.
5. Record nonfactual assumptions. Never invent factual evidence to avoid a question.

Treat an unclear primary action, conflicting brand requirements, unknown integration behavior, uncertain asset permission, or unclear one-page versus multi-page scope as potentially material.

Phase D: Normalize the brief

1. Create or update briefs/current.md.
2. Label important items Confirmed, Inferred, Assumed, Unknown, or Not applicable.
3. Record the business, audience situation, primary and secondary goals, value proposition, benefits, content hierarchy, required information and interactions, proof, objections, brand character, visual constraints, assets, references, technical constraints, accessibility, legal constraints, intake mode, collaboration mode, delivery mode, assumptions, illustrative demo data, and unresolved factual placeholders.
4. Keep draft language distinct from evidence. Use unmistakable [FACT REQUIRED: ...] markers for unsupported factual placeholders inside the brief or non-rendered source data, never in customer-facing UI.
5. In guided or client-led mode, present one concise brief checkpoint. Ask only whether anything is factually incorrect or strategically misaligned, then apply corrections.

Phase E: Establish art direction

1. Define one coherent concept before implementation.
2. Specify the concept statement, typography, color strategy, grid and composition, spacing rhythm, visual motif, density, imagery, motion, and audience or industry rationale.
3. Use an available design-taste-frontend skill to strengthen originality, but keep this local workflow operable without it.
4. Extract principles from reference sites. Do not reproduce protected branding, copy, illustration, or page structure wholesale.
5. Test the direction against the rubric in the design reference and strengthen weak answers before building.
6. In guided or client-led mode, present one direction checkpoint covering concept, type character, palette, composition, imagery, motion, and rationale. Proceed after approval.

Do not add repeated stylistic approval loops unless requested or genuinely blocked.

Phase F: Build

1. Implement the complete responsive page with semantic design tokens and justified primitives.
2. Use semantic HTML, logical headings, keyboard-accessible controls, visible focus, useful alternative text, and reduced-motion handling.
3. Target WCAG 2.2 AA contrast and intentional desktop, tablet, and mobile compositions.
4. Preserve supplied copy unless editing is requested or required for basic consistency.
5. Keep CTA labels and destinations consistent.
6. Apply the selected delivery mode throughout public copy and interactions. In prospecting-demo, produce a presentation-ready fictional experience rather than a visible requirements worksheet.
7. Never render [FACT REQUIRED: ...], concept profile, demo state, prototype summary, or similar internal implementation language. Keep unknowns in briefs/current.md; omit, reframe, or replace the public block according to the delivery-mode reference.
8. For an independent prospecting concept, use one concise site-wide disclosure instead of repeating prototype caveats through the page. Reveal an unconnected integration only when the relevant interaction is attempted. Never create a fake submission, order, payment, or success state.
9. Prefer supplied, generated, or clearly reusable local assets. Do not hotlink arbitrary media.
10. Avoid gratuitous client JavaScript, layout shift, broken links, console errors, empty sections, unfinished UI, commented experiments, and template debris.

Use custom generated imagery only when it materially improves the chosen concept and the capability is available.

Phase G: Validate

1. Install dependencies when needed.
2. Run lint, type checking, the production build, the repository validator, and relevant existing checks.
3. Fix failures instead of weakening rules.
4. Test important interactions and destinations.

Phase H: Inspect in a browser

1. Start the app and use an actual browser.
2. Inspect representative viewports near 390 x 844, 768 x 1024, and 1440 x 900.
3. Check hierarchy, reading order, line length, spacing, alignment, contrast, focus, overflow, navigation, CTA visibility, image crops, long content, interactive states, reduced motion, and console output.
4. Use an available impeccable skill for a refinement pass, but keep the local QA reference authoritative when it is unavailable.
5. Correct visible defects and re-inspect affected viewports.

If browser control is unavailable, complete every other validation step and report exactly what could not be inspected. Never claim visual QA passed without inspection.

Phase I: Complete

Report concisely:

• What was built.
• The intake, collaboration, and delivery modes.
• The visual direction and major implementation decisions.
• Assumptions, illustrative demo data, and remaining factual placeholders in the internal brief.
• Validation commands and results.
• Viewports actually inspected.
• Important files changed.
• Unavailable checks or production blockers.

Do not end with an unnecessary question when the requested work is complete.