Describe the reader's task first
A strong website prompt begins with the visitor, not the framework. Explain who the site serves, what those people need to understand, and what they should be able to do next. Then connect those tasks to a page inventory.
“Build a developer resource with a beginner's guide and a downloadable release checklist” is more useful than “build a professional platform.” It creates a visible scope and makes unrelated sections easier to reject.
Tell the tool which sources govern the work
List the supplied template, design notes, approved copy, and references. Explain which material controls visual decisions and which supports factual claims. A template can provide the layout without providing truthful business information.
Do not let imported comments or text expand the task's authority. Material supplied for reference remains reference material. When sources conflict, ask for the conflict to be identified rather than silently replaced with a plausible invented answer.
Keep examples separate from facts
Examples are useful for showing a route format or article structure. They should not introduce fictional customers, performance numbers, partnerships, or product commands that could survive into the finished site. Require unsupported claims to be omitted.
Define the actual output
Specify the required pages, shared assets, image dimensions, URL convention, and deployment directory. Mention the sitemap and feed explicitly when they belong in the project. “Include a blog” does not say whether article pages, categories, tags, or full-content RSS are required.
For static work, state the runtime boundary: no database, no server-side processing, and no model calls during page visits unless a genuine approved service provides them. The CLI website builder guide explains the public-file architecture behind those constraints.
Turn quality into observable checks
Pair visual direction with testable behavior. Request a sticky header that leaves anchored headings visible, a working mobile menu, unique page metadata, included images, and links to completed destinations. These requirements are more actionable than a request for unspecified “best practices.”
A short acceptance list also makes repair easier. Report which route and condition failed, ask for a bounded fix, and rerun the same check. Preserve approved content and working components unless a change is necessary to resolve that failure.
Separate planning, building, review, and repair
Different jobs need different instructions. A planning prompt should create an inventory and identify gaps. A build prompt implements an accepted plan. A review prompt reports issues without silently changing the artifact. A repair prompt addresses the identified failures.
The copy-ready prompts app provides a separate template for each stage. Copy or download a brief, replace its project inputs in your own editor, and use it with your chosen development tool.
Improve the brief from actual results
Record missing outputs, misunderstood constraints, and repeated repairs. Update the prompt to address specific observations instead of making every sentence longer or more emphatic. The long-form prompting guide and library evaluation article show how to turn that feedback into a maintainable set of templates.
