Help a person with little website experience create a useful, attractive site for their business. Follow the user's requested scope and continue through the work the available tools allow.
Recognize the request
Treat a clear desire for you to produce the user's website as the trigger. The exact verb or phrase does not matter. A substantial redesign also qualifies; inspect the existing site and preserve functions the user has not asked to change.
If a request for an online presence could mean a social profile or directory listing, ask one question to establish whether a website is wanted. Do not require confirmation of an already clear request.
A request for a plan or mockup authorizes that deliverable. A small existing-site edit should not restart the intake.
Interview one decision at a time
Read existing messages, project files and supplied business information first. Reuse known answers.
Ask the highest-impact unresolved question. Offer a recommended choice and a short reason when there is enough context; use two or three simple options when helpful. Wait for the answer before asking its dependent follow-up. Avoid a long questionnaire.
Ask about the business and its customers. Recommend technical implementation on the owner's behalf when delegated, explaining meaningful cost and maintenance tradeoffs in plain language.
If nothing is known, begin with: "What does your business offer?" If the business type is already supplied, ask the next useful question, such as the main action visitors should take.
Use business-intake.md as a question bank. Stop when the offer, audience, visitor action, first-version scope and important constraints are clear enough for a useful draft. When the owner is unsure, suggest a reversible default and label it as an assumption. If they delegate decisions or ask to skip questions, proceed within the scope they supplied.
Record confirmed facts, assumptions and unresolved setup using brief-template.md. Save website-brief.md in the user's project if file access is available; otherwise keep it in the conversation and provide copyable text. Do not put business details into this reusable bundle.
Check tools during intake
Once enough context is known to identify the next stage's needs, follow tool-setup.md. Reuse existing tools and the owner's chosen platform.
Install or enable necessary tools automatically when the task authorizes setup and the environment permits it. Handle required permission prompts, choices and sign-ins through the supported mechanisms. Guide the owner one concrete step at a time when their action is needed.
Avoid redundant permission questions for actions already authorized. New charges, publication and live transactions still require their relevant authorization. Verify that installed or connected tools can perform the needed operation.
Continue independent intake, writing or design while optional setup is blocked. Do not silently replace the owner's platform.
Load supporting skills after intake
When the brief is sufficiently complete, read after-intake.md and apply its continuation prompt. If you can continue yourself, do so; do not ask the owner to paste it back to you.
Use skill-map.md to locate the supporting instructions. Reading the files is enough to use them. If the host supports persistent skills, you may register the relevant folders using its documented mechanism and existing task authorization. Preserve different existing versions and report whether skills were registered or only loaded into this conversation.
Load website-copy and one main design approach first. Add other skills for specific needs. Do not make each helper repeat the interview or load the entire bundle at once.
Build and verify
Respect the agreed content, brand, platform, budget and maintenance needs. Use verified business facts and appropriate imagery; do not manufacture reviews, credentials or customer outcomes.
If the visual direction is unclear, suggest a small choice and recommend one. If the user has already chosen or delegated that choice, continue without another gate.
Build the agreed pages and customer journey with available tools. Prefer a simple maintainable solution. Missing final imagery or a domain need not prevent a draft. A simple information site does not automatically need accounts or a custom database.
Inspect phone and desktop layouts and exercise the relevant paths: understanding the offer, navigating, finding a service or product, contacting, booking or purchasing. Apply the review and testing skills when those stages exist.
Report what you actually checked. A form success screen does not prove delivery. A generated website file is not a tested preview, and a preview is not a public launch. Use launch-checks.md for the handoff.
When the environment cannot execute a step, provide usable content, files or a precise handoff, and state the limitation. Do not pretend to browse, install, authenticate, test or publish.