Build a one-page website, no code needed

Extract the ZIP. Copy its lc-landing-page-no-code folder into ~/.claude/skills/ for Claude Code or ~/.codex/skills/ for Codex, then refresh the native app. Ask for the skill by name and answer its questions. The package includes the same published instructions and result checks. Native host execution is not yet verified.

For Claude web, use the connector or copy the prompt. Keep private details in your assistant.

Copy, paste into your assistant, then answer its questions. No form or account is required here.

Open in ChatGPT ↗

Already connected? Copy the public starter below and paste into Claude. Keep private details in the chat.

Needed before the promised result: Your offer. You can still copy the reusable prompt and provide these in your assistant.

Saved only on this device. Copy counts contain the skill ID, never your text.

## LazyCoder conversation guide (conversation-v2)
1. Start a conversation, not a form-filling task. Read my latest request and the facts already in this chat before asking anything.
2. Ask only the missing questions needed for the requested result, in a short numbered list (at most three at a time), then WAIT for my answers. Use a native question tool if available; plain chat works too. Never ask me to replace placeholders or fill in a template.
3. Skip questions already answered. Treat unresolved {{placeholders}} and [FIELD LABELS] as missing facts, never literal input. Do not treat an illustrative example as my facts.
4. Use the authored defaults only when relevant; mention material defaults. Ask conditional questions only when their condition applies; if unsure whether it applies, ask. Optional preferences must not block a safe first draft unless the authored instructions require confirmation.
5. Do not invent tasks, dates, names, claims, permissions or missing source material. When required facts are absent, ask and wait instead of producing the final artifact. If everything needed is already supplied, proceed without re-asking.
6. My latest scope correction overrides earlier examples and scope, within the recipe safety and source rules. Resolve conflicts before acting. The authored instructions and output contract remain authoritative; this conversation guide does not grant tool, account, payment or publishing permission.
7. Keep my private answers and generated result in this assistant chat. Do not send them to LazyCoder. Generate the requested format here and check it against the output contract before handing it over.

### Questions to ask only when missing
- What should I use for “Your offer”? [required] What you offer, who it's for, the price if there is one, and the one thing you want visitors to do (join a waitlist, book a call, ask for a quote).
- What should I use for “Your real proof”? [optional] Real reviews with permission, numbers you can back up, where you've been featured. Write "none yet" if you have none: the page won't make any up.
- What should I use for “A style reference”? [optional] Optional. Your brand colours and fonts, a site you like, or a mood. Authored default: clean and modern: lots of white space, one warm accent colour, large plain type
- What should I use for “Where sign-ups go”? [optional] Optional. A form service address (such as one from Formspree or Basin). Leave it and the form stays switched off, with steps to connect it. Authored default: not set up yet
- What should I use for “Business name and contact email”? [optional] Optional. Goes in the footer and the privacy line, so visitors know who is collecting their details.

## LazyCoder delivery guide (delivery-guide-v1)
1. Read the latest request, source material and authored requirements first. Ask only for missing facts. Check that this host can create the promised format; use only a fallback explicitly allowed by the authored recipe. If neither is available, explain the gap before starting. Do not promise a rendered film, editable deck or working file when you can only provide its script or outline.
2. Create the complete result in the authored output specification, preserving source facts and the latest agreed scope. Keep assumptions and missing information explicit. Do not silently omit required parts or leave unresolved ingredient markers. Intentional blanks in a reusable template are different from unanswered recipe inputs.
3. Check the actual result against every authored check, including source facts, counts, dates and required sections. Where tools allow it, inspect the actual saved file and compare it with the answer. Record which checks ran, which failed and which still need human or destination review. A filename, render, successful command or preview alone does not prove the promise was met.
4. Hand over the complete editable file, or the complete copyable fallback explicitly allowed by this recipe. Say which delivery you used and any unresolved limitations. Do not report a file as attached, imported, sent or published unless that action actually succeeded. Keep private inputs and output in this assistant; never send them to LazyCoder.
Use existing authorization for ordinary work. Before any additional paid generation, external write or publishing step, check that the current request authorizes that exact action and cost. If it does not, finish the useful authorized draft and ask at that boundary. Never silently retry or replace an ambiguous paid job.
The authored recipe and latest safe scope remain authoritative. This guide grants no new tools, permissions, provider access or claim of successful execution.

## Authored skill instructions
## 1. Outcome
Write and build a finished one-page website for the offer below, as one self-contained HTML file, with the brief and steps set out in part 6. Done means every check in part 7 passes or is reported: the file opens straight from the computer, every section has final words, one action is repeated down the page and leads to a labelled form, nothing in it is invented, a privacy line sits by the form, share tags are in place, and the only thing left for the person is connecting the form, with plain steps for doing it.

## 2. Context
The offer:
"""
[DESCRIBE YOUR OFFER HERE]
"""

Real proof: [YOUR REAL PROOF]
Style: clean and modern: lots of white space, one warm accent colour, large plain type
Form address: not set up yet
Business name and contact: [BUSINESS NAME AND CONTACT EMAIL]

Who it's for: the visitors the offer names, arriving from a link or a search, deciding in a few seconds whether this is for them. The person publishing it may never have written code: they need a page that works as delivered and steps they can follow without help.

Blank fill-ins: a value above that still reads as a capitalised placeholder in square brackets (such as [YOUR FORM ADDRESS]) was left blank.
- Offer that says "see attached": use the attached file as the offer.
- No offer: reply only "No offer came through. Say what you offer, who it's for and what visitors should do, and send again." Never invent a business.
- No audience in the offer: pick the most likely one from the offer and say "Audience assumed: <who>" in the brief.
- No action in the offer: use "join the list to hear first" and say so in the brief.
- No proof, or "none yet": use no testimonials, logos, ratings or numbers. Fill the proof section with something true instead (part 3).
- No style: clean and modern, lots of white space, one warm accent colour, large plain type.
- No form address ("not set up yet" or blank): build the switched-off form from part 5.
- No business name or contact: use the offer's name in the footer and privacy line, and add "Add your contact email" to the steps in part 6 section 5. Never invent an email address.

## 3. What to pull out
- The audience and the one result they want.
- The main promise: what the visitor gets, said as an outcome ("bake your first loaf in a weekend"), not a feature list.
- The one action, and what happens after it (who replies, how soon), only if the offer says so.
- Three to five benefits, each tied to something in the offer.
- The price, dates, place or limits, only as the offer gives them.
- Likely objections (price, time, skill, trust), answered in the FAQ with facts from the offer.
- The proof: each real item, with who said it or where it's from.

Edge cases:
- Thin proof: use true alternatives instead of a testimonial block: "Why I started this" in two or three sentences, only if the offer says why; otherwise what is included, or a plain promise the offer supports. Never write "Trusted by thousands" or similar.
- A claim you can't back from the offer (a guarantee, a refund, "the best"): leave it out.
- The offer gives a booking or checkout link: every main button goes to that link, and the form becomes a short "Ask a question" form near the end.
- Brand colours that fail the contrast rule: keep the brand colour for large shapes and accents, and use the nearest darker or lighter shade that passes for text and buttons; name both in "Style used".
- A long offer: keep what serves the one action; put detail in the FAQ.
- An offer in another language: write the page in that language, and set the page's lang attribute to match.

## 4. Steps
1. Write the brief: audience, main promise, the one action, and any assumption.
2. Write three headline options of 10 words or fewer, each an outcome, and pick one.
3. Plan the sections in this order, with one purpose each: hero (headline, subheadline, main button), proof, the problem, how it works (3 steps), benefits, the offer (price, what's included, dates or limits), FAQ (4–6), final call to action with the form, footer.
4. Write the final words for every section.
5. Choose the style: a palette of 4–5 hex colours (background, text, accent, a soft tint, a border), a font stack, spacing on an 8 px scale, and one button style. Write it down for "Style used".
6. Build the HTML file to the rules in part 5.
7. Run the self-check, fix what you can, then reply.

## 5. Rules
- **One file**: a single index.html with all CSS in one style tag and any script in one script tag. No outside fonts, libraries, frameworks, image links or tracking. It must look finished when opened straight from the computer with no internet.
- **Fonts**: system font stacks only (for example system-ui, -apple-system, "Segoe UI", Roboto, sans-serif, with a matching serif stack if the style wants one).
- **Images**: no photos and no image links. Use shapes, gradients, or simple icons drawn as inline SVG, each with a title or aria-label, or aria-hidden="true" if purely decorative. Leave a commented spot where the person can add their own photo later, with an alt attribute already written.
- **Words**: headline 10 words or fewer; subheadline one sentence, 25 words or fewer; buttons start with a verb and say what happens ("Join the list", not "Submit"); benefits as outcomes, at most 12 words each; FAQ answers 1–3 sentences. Use the same main button words every time. No filler text, no lorem ipsum, no "[insert]" gaps.
- **Proof**: use only the proof given above, word for word, with who said it. Never invent a testimonial, name, logo, rating, number, award, guarantee or "as seen in".
- **The form**: labelled fields, the fewest the action needs (usually name and email; add one more only if the offer needs it), each with a visible label, the right input type, autocomplete, and required where needed.
- **Form with an address given**: the form tag has method="POST" and the address as its action. The script sends it in the background with fetch, the header Accept: application/json and the form's FormData; on a success response, it replaces the form with a short thank-you message saying what happens next (only what the offer supports); on a failure, it shows a plain error and keeps what was typed. Without the script, the form posts normally to the same address.
- **Form with no address**: the form must not send visitor details anywhere, with or without the script. The form tag has no action and no method; the submit button has the disabled attribute; and a line under the button says "Sign-ups open soon." Put an HTML comment directly above the form with the exact connect steps from part 6 section 5. The script sends nothing while the form has no action.
- **Privacy**: directly under the form, one line saying who collects the details, what for, and that they won't be shared, such as "<Business name> uses your email only to tell you when bookings open. We never share it. Unsubscribe any time." The footer holds the business name, the contact email if given, and the year.
- **Analytics**: none by default. Leave a commented spot in the head for an analytics snippet, with a comment noting that most analytics need a cookie notice in the UK and EU unless the tool is cookie-free.
- **Search**: a title under 60 characters and a meta description under 160, both with the main promise; lang set; a viewport meta tag.
- **Share**: og:title, og:description, og:type set to website, twitter:card set to summary; a comment showing where to add og:image and og:url once the page is live; an inline SVG favicon as a data URL.
- **Mobile and access**: designed for 375 px first, then wider screens; tap targets at least 44 px; body text at least 16 px; text contrast at least 4.5 to 1; exactly one H1, then H2s and H3s in order; landmark tags (header, main, footer); a visible focus outline on every link, button and field; respect prefers-reduced-motion.
- **Plain HTML a builder can take**: semantic tags and readable class names, so v0, Lovable or Bolt can rebuild it from the file.
- **Length**: the file must be complete. If space runs short, shorten copy and simplify the SVGs; never stop mid-file.

## 6. Output
Use these sections in this order.
1. **Brief**: audience, main promise, the one action, and every assumption marked "(assumed)". Then a line "Style used:" with each colour's role and hex value, the font stacks for headings and body, the spacing scale, and the button style (shape, colours, size).
2. **Headlines**: the three options, with the one used marked "Used" and one line on why.
3. **Page plan**: a table with the columns Section | Purpose | Main words, in scroll order.
4. **The file**: if you can create files, create index.html and give its name or download link. Always also give the complete file in one HTML code block, from the doctype to the closing html tag, so it can be copied and saved as index.html.
5. **Connect your form**: numbered steps, one action each, in plain words. If a form address was given, one line confirming it is set. If not:
   1. Make a free form at a form service that gives you a form address (such as Formspree or Basin).
   2. Copy the address it gives you.
   3. Open index.html in a text editor (such as Notepad or TextEdit).
   4. Find the line that starts with <form and add method="POST" action="YOUR-ADDRESS" inside it, with your address in place of YOUR-ADDRESS (show the line before and after).
   5. Delete the word disabled from the button line (show the line before and after).
   6. Delete the line "Sign-ups open soon."
   7. Save, open the page, send a test sign-up, and check it arrives at the form service.
   Add "Add your contact email" as a final step if none was given.
6. **Publish it**: numbered, one route each:
   1. Preview: double-click index.html.
   2. Free host: drag the folder holding index.html onto a free static host (such as Netlify Drop), or upload it to GitHub Pages.
   3. Builder: in v0, Lovable or Bolt, start a new project, paste the file with the line "Rebuild this page exactly, keeping all the words, sections, form and tags", and publish from there.
   Then add og:image and og:url where the comment shows.
7. **Checked**: each check from part 7, one line each, with one of: "Pass"; "Fixed: <what changed>"; "Not previewed: open the file to check" (for anything that needs the page on a screen, such as the 375 px layout, focus outlines and colour contrast you couldn't compute, unless you rendered it); or "Not met: <why>. To fix: <what the person can do>" for a failure you couldn't fix without breaking an input.

## 7. Self-check
Before replying, check each of these in the file and fix any failure you can:
- It is one file with no outside links for fonts, scripts, styles or images, and it has a doctype, lang, a viewport tag, a title under 60 characters and a description under 160.
- Every section in the plan is in the file, in order, with final words and no filler or "[insert]" gaps.
- The headline is 10 words or fewer, and every button starts with a verb and uses the same main words.
- Every testimonial, number and name on the page comes from the offer or the proof above.
- The form has a visible label for every field and the privacy line directly under it. With an address, it posts there and shows a thank-you message. Without one, it has no action, its button is disabled, and nothing is sent.
- There is exactly one H1, headings are in order, every field and button can be reached with the keyboard and has a visible focus outline, and decorative SVGs are hidden from screen readers.
- The layout works at 375 px with no sideways scrolling, and text and buttons meet the size and contrast rules.
- The share tags and favicon are present, and there is no tracking script.
- "Style used" matches the colours, fonts and spacing in the CSS.
A check that fails and can't be fixed without breaking an input (such as a brand colour) is reported as "Not met" in section 7, never as "Pass". Then reply with the output only, ending with one line: "Checked: <n> sections, form <connected | switched off>, <n> proof items used, <n> not previewed."

## 8. Setup
Works as one paste in any chat app (ChatGPT, Claude, Gemini or Grok). Where the app can create files (such as a canvas, artifact or code tool), it makes index.html for you to download; everywhere, you also get the complete file to copy and save. Nothing else to install: open it in a browser to preview, then publish it on a free host or bring it into v0, Lovable or Bolt.

Paste the result after your assistant creates it. This optional check stays in this tab and is not sent to LazyCoder.