sandbox-safemode/365-castle-logos

Website Building

Build distinctive, production-grade websites that avoid generic "AI slop" aesthetics. Every choice — type, color, motion, layout — must be intentional. Deploy as static HTML/CSS/JS bundles to S3.

This skill covers everything for web projects. When loaded via load_skill("website-building"), all files are copied to workspace/. Read sub-files as needed based on your project type. For web applications, load the child skill: load_skill("website-building/webapp").

Universal design principles (color philosophy, default palette, font selection) are shared with other skills via design-foundations. This skill's shared files extend those foundations with web-specific implementation (CSS variables, responsive tokens, base stylesheets). You don't need to load design-foundations separately — the web-specific versions in shared/ are comprehensive.

Use read with the full path, e.g. shared/01-design-tokens.md

---

Project Type Routing

Step 1: Identify project type and load domain-specific guidance:

Project Type	Action	Examples
Informational sites	read informational/informational.md	Personal sites, portfolios, editorial/blogs, small business, landing pages
Web applications	load_skill("website-building/webapp")	SaaS products, dashboards, admin panels, e-commerce, brand experiences
Browser games	read game/game.md + game/game-testing.md	2D Canvas games, Three.js/WebGL, HTML5 games, interactive 3D experiences

Step 2: Read shared files — read shared/01-design-tokens.md and shared/02-typography.md first (mandatory for ALL project types, including webapp). These establish the Nexus design system defaults and typography rules that apply universally. For web applications and dashboards, skip files marked with † below — those contain implementation details pre-configured in the fullstack template.

If the user says just "website" or "site" with no detail, ask what type or default to informational.

---

Sub-File Reference

Shared (shared/) — Every project

File	Covers	Load
shared/01-design-tokens.md	Type scale, spacing, Nexus palette, base.css	Always
shared/02-typography.md	Font selection, pairing, loading, blacklist	Always
shared/04-layout.md	Spatial composition, responsive, mobile-first	Always †
shared/05-taste.md	Skeleton loaders, empty/error states, polish	Always
shared/08-standards.md	Accessibility, performance, anti-patterns	Always
shared/09-technical.md	Project structure, sandbox, deploy, checklist	Always †
shared/03-motion.md	Scroll animations, Motion library, GSAP SVG plugins, hover/cursor	When animated
shared/06-css-and-tailwind.md	Tailwind CSS v3, shadcn/ui, modern CSS	When using Tailwind
shared/07-toolkit.md	CDN libraries, React, Three.js, icons, maps, SVG patterns/filters, esm.sh	When choosing libs
shared/10-charts-and-dataviz.md	Chart.js, Recharts, D3, KPIs, sparklines	When data viz needed
shared/11-web-technologies.md	Framework versions, browser compatibility	When checking compat
shared/12-playwright-interactive.md	Persistent Playwright browser QA, screenshots, visual testing	When testing
shared/19-backend.md	FastAPI/Express/Flask servers, WebSocket, SSE, port forwarding	When backend needed
shared/20-llm-api.md	LLM chat, image/video/audio generation, transcription — models, credentials, SDK helpers	When site uses AI/LLM APIs

All paths are relative to ``.

† Skip for webapp and dashboards — implementation details pre-configured in the fullstack template. Design-tokens and typography are NOT skipped — they provide the authoritative design system defaults and font selection guidance for all project types.

Domain-Specific — Load one

File	When to load
load_skill("website-building/webapp")	SaaS, dashboard, admin, e-commerce, brand experience (child skill with fullstack template)
skills/website-building/webapp/dashboards.md	Dashboard or data-dense interface (companion to webapp)
informational/informational.md	Personal site, portfolio, editorial, small business, landing
game/game.md	Browser game, Three.js, WebGL, interactive 3D
game/2d-canvas.md	2D Canvas game (companion to game.md)
game/game-testing.md	Any browser game — load alongside game.md

Interactive QA: Read shared/12-playwright-interactive.md for persistent browser automation with Playwright (screenshots, functional testing, visual QA). Required for game testing, useful for any complex site.

---

Workflow

1. Design Direction: Clarify purpose, pick aesthetic direction
2. Version Control: Run git init in the project directory after scaffolding. Commit after each major milestone with a short message.
3. Build: Build the site page by page, taking screenshots via Playwright for visual QA
4. Publish: Commit all changes, then deploy_website() returns public URL

---

Use Every Tool

• Research first. Search the web for reference sites, trends, and competitor examples before designing. Browse award-winning examples of the specific site type. Fetch any URLs the user provides.
• Generate real assets — generously. Generate images for heroes, section illustrations, editorial feature visuals, atmospheric backgrounds — not just one hero image. Every long page should have visual rhythm with generated images that match the site's art direction. No placeholders. Generate a custom SVG logo for every project (see below) — SVG is for logos only unless the user specifically requests SVG output. Save web reference images that inform direction.
• Screenshot via Playwright (complex sites only). For multi-page sites, web apps, dashboards, and games, read skills/website-building/shared/12-playwright-interactive.md to screenshot at desktop (1280px+) and mobile (375px). Skip Playwright for simple single-page static sites — see Visual QA below.
• Write production code directly. HTML, CSS, JS, SVG. Use bash for build tools and file processing.

---

SVG Logo Generation

Every project gets a custom inline SVG logo. Never substitute a styled text heading.

1. Understand the brand — purpose, tone, one defining word
2. Write SVG directly — geometric shapes, letterforms, or abstract marks. One memorable shape.
3. Principles: Geometric/minimal (Paul Rand, Vignelli). Works at 24px and 200px. Monochrome first — add color as enhancement. Use currentColor for dark/light mode.
4. Implement inline with aria-label, viewBox, fill="none", currentColor strokes
5. Generate a favicon — simplified 32x32 version if needed

For SVG animation (DrawSVG, MorphSVG), see shared/03-motion.md. For SVG patterns/filters, see shared/07-toolkit.md.

---

Visual QA Testing Process

When to use Playwright QA

Skip Playwright for simple sites. Single-page static sites do NOT need Playwright screenshots. Review the code directly, then deploy. Playwright QA adds significant time and is not worth it for simple static content.

Use Playwright for complex sites. Multi-page sites, web applications, dashboards, games, and any site with interactive features (forms, carts, filters, charts, drag-and-drop) MUST use Playwright QA. Read skills/website-building/shared/12-playwright-interactive.md for persistent browser automation.

Playwright QA Process (complex sites only)

Cycle: Build → Playwright QA → Evaluate → Fix → Repeat → Deploy when ready

Stage 1: Page-by-Page QA

After building each page:

1. Screenshot at desktop (1280px+) and mobile (375px) via Playwright
2. Evaluate critically: Does it look professionally designed (not AI-generated)? Is typography distinctive? Is whitespace generous? Is there one clear visual hierarchy?
3. Fix every issue before moving on. No visual debt.

Stage 2: Final QA (before publishing)

1. Screenshot every page at desktop and mobile
2. Check cross-page consistency (spacing, color, type treatment)
3. Verify dark mode (screenshot both themes for homepage minimum)
4. Check interactive states: hover, focus, active, loading, empty, error
5. Cold-open first impression test: does it feel polished and intentional?

QA failures: text overflow, inconsistent spacing, off-token colors, missing dark mode, squished mobile, generic AI look, placeholder content, missing logo.

---

Step 1: Art Direction — Infer Before You Ask, Ask Before You Default

Every site should have a visual identity derived from its content. Do not skip to the Nexus fallback palette. The Nexus palette is a last resort for when both inference and asking have failed — not a convenient default.

1. Infer from the subject. A coffee roaster site → earthy browns, warm cream, hand-drawn feel. A fintech dashboard → cool slate, sharp sans-serif, data-dense. A children's learning app → bright primaries, rounded type, playful motion. The content itself tells you the palette, typography, and spacing before the user says a word.
2. Check the Art Direction tables. Each domain file (informational.md, webapp/SKILL.md, game/game.md) has an Art Direction table mapping site/product types to concept-driven directions and token starting points. Use these as a springboard.
3. Derive the five pillars: Color (warm/cool, accent from subject), Typography (serif/sans, display personality), Spacing (dense/generous), Motion (minimal/expressive), Imagery (photo/illustration/type-only).
4. If the subject is genuinely ambiguous, ask — "What mood are you going for?" and "Any reference sites?" One question is enough.
5. Nexus fallback — only when inference AND asking yield nothing. If the user has been asked and gave no direction, AND the subject matter gives no clear signal, then fall back to Nexus/Swiss defaults.

The Fallback: Clean & Swiss (Last Resort)

When inference yielded no clear direction AND the user was asked but gave no style guidance, use defaults from shared/01-design-tokens.md with:

• Typography: Satoshi or General Sans body (Fontshare — preferred), or Inter/DM Sans. Weight contrast over font contrast. 3-4 sizes max. Keep text compact — --text-3xl/--text-hero are for informational site heroes only.
• Color: Nexus palette. Neutral surfaces + one teal accent for CTAs only.
• Layout: Grid-aligned. Generous margins. Asymmetric where interesting.
• Motion: Minimal, functional. Smooth state transitions only.
• Imagery: Generate clean, relevant visuals. No stock photos.

Art Direction — Avoid the AI Aesthetic

See shared/08-standards.md for the full anti-patterns list.

---

Step 2: Publish

Call deploy_website() with the project path and site name. Returns a public S3 URL. To update, edit the local files and re-deploy with the same path. See shared/09-technical.md for the exact call and examples.