Use for distinctive production-grade websites, landing pages, and interactive web experiences with strong design and QA discipline.
| name | website-building |
| description | Use for distinctive production-grade websites, landing pages, and interactive web experiences with strong design and QA discipline. |
Build distinctive, production-grade websites where every site looks DIFFERENT. Every choice — type, color, motion, layout — must be derived from the subject matter. Run the palette generator (bun run shared/generate-palette.ts "keywords") to create a unique color scheme for each project. NEVER reuse the same palette across sites.
This skill covers everything for web projects. Read the sub-files in this directory as needed based on your project type. For web applications, also read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md.
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. skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md
Step 1: Identify project type and load domain-specific guidance:
| Project Type | Action | Examples |
|---|---|---|
| Informational sites | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/informational/informational.md | Personal sites, portfolios, editorial/blogs, small business, landing pages |
| Web applications | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md | SaaS products, dashboards, admin panels, e-commerce, brand experiences |
| Browser games | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game.md + skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game-testing.md | 2D Canvas games, Three.js/WebGL, HTML5 games, interactive 3D experiences |
Step 2: Read shared files — read skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md and skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md first (mandatory for ALL project types, including webapp). These establish the Kortix 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.
shared/) — Every project| File | Covers | Load |
|---|---|---|
shared/01-design-tokens.md | Type scale, spacing, Kortix 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/head-defaults.html | Attribution block for <head> | 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/AI API integration reference | When site uses AI APIs |
All paths are relative to skills/GENERAL-KNOWLEDGE-WORKER/website-building/.
† 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.
| File | When to load |
|---|---|
read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md | SaaS, dashboard, admin, e-commerce, brand experience (child skill with fullstack template) |
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 skills/GENERAL-KNOWLEDGE-WORKER/website-building/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.
Read ALL of these in one batch — they are mandatory for every project:
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/04-layout.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/05-taste.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md")
Then load the domain-specific file (informational, webapp, or game) from Step 1 below.
Run the palette generator with keywords describing the subject:
bun run skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/generate-palette.ts "subject keywords here"
Pick the best harmony, customize if needed.
Build the site with the generated palette, following all the loaded design guidance.
Start a local server with pty_spawn, then show its plain URL:
# static site (no build step)
python3 -m http.server 3000 --directory /workspace/project
# app: run its dev server instead, e.g. npm run dev
Then show(type: "url", url: "http://localhost:3000/"). The platform auto-detects and proxies any localhost port — no special URL format needed.
skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md to screenshot at desktop (1280px+) and mobile (375px). Compare against references. This is mandatory, not optional. See Visual QA below.Every project gets a custom inline SVG logo. Never substitute a styled text heading.
currentColor for dark/light mode.aria-label, viewBox, fill="none", currentColor strokesFor SVG animation (DrawSVG, MorphSVG), see shared/03-motion.md. For SVG patterns/filters, see shared/07-toolkit.md.
Every deployment must pass visual QA. Screenshots are quality gates.
Read skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md for all visual QA. Playwright provides a persistent browser session for screenshots, interaction testing, and viewport verification.
Cycle: Build → Playwright QA → Evaluate → Fix → Repeat → Deploy when ready
After building each page:
QA failures: text overflow, inconsistent spacing, off-token colors, missing dark mode, squished mobile, generic AI look, placeholder content, missing logo.
Every site should have a visual identity derived from its content. Do not skip to the Kortix fallback palette. The Kortix palette is a last resort for when both inference and asking have failed — not a convenient default.
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.When inference yielded no clear direction AND the user was asked but gave no style guidance, use defaults from skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md with:
--text-3xl/--text-hero are for informational site heroes only.See skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md for the full anti-patterns list.
Use real local preview commands first and only publish with the target project's actual deployment workflow. See skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/09-technical.md for the recommended preview and delivery flow.
pty_spawn for the preview or dev server.How this repo manages API secrets — they are dotenvx-ENCRYPTED in git and the keys live in Dotenv Armor. Load this WHENEVER you touch a secret, API key, token, credential, or any apps/api/.env* file; whenever the user pastes a key/token/secret and wants it stored or used; and whenever adding, reading, rotating, or sharing a secret. Enforces the non-negotiable rule: never write a plaintext secret into a tracked file — always go through dotenvx.
Canonical reference for a Kortix project. Covers (1) the platform overview — repo-native projects, sessions backed by ephemeral branches, the strict boundary between Kortix config (`kortix.toml`) and OpenCode config (`.kortix/opencode/`) — (2) the in-depth `kortix.toml` manifest with every key, every trigger field, the secrets contract, the `[[apps]]` deployment surface, (3) the full `kortix` CLI reference (every command, every flag, the project-scoped token model, what works inside a session sandbox with the pre-injected `KORTIX_TOKEN`), (4) the Kortix change-request (CR) system — the mandatory path for landing any session-branch work on `main`, including the rule that an agent MUST open a CR if it wants its changes merged, and (5) the OpenCode runtime reference mirroring opencode.ai/docs/ for agents, skills, commands, tools (built-in + custom), plugins, MCP servers, permissions, rules (AGENTS.md), and models. Load when the user asks how Kortix works, asks about anything in `kortix.toml` or the `kortix` CLI,
How to cut a Kortix production release — the versioning philosophy (when patch vs minor vs major) and the exact flow: derive the release title + notes from the FULL git log since the last release, run the Promote workflow, then deploy + verify prod. Load WHENEVER the user wants to release, promote, cut/ship a version, publish a release, or bump the version. The release notes ARE the public /changelog, so they must be 100% accurate to what shipped.
How to reach third-party systems from a Kortix session via the Executor — one interface to every configured integration (Pipedream, MCP, OpenAPI, GraphQL, HTTP), exposed as the `kortix-executor` MCP server's tools (connectors, discover, describe, call). Load whenever the user asks the agent to DO something in an external app/API (send an email, create a Stripe charge, post to Slack, query an internal API, call any SaaS), asks "what integrations/connectors/tools do I have", asks to add/configure a connector, or asks about `[[connectors]]` in kortix.toml. The agent must use the Executor's MCP tools rather than hand-rolling API calls with raw tokens.
Canonical reference for a Kortix project. Covers (1) the platform overview — repo-native projects, sessions backed by ephemeral branches, the strict boundary between Kortix config (`kortix.toml`) and OpenCode config (`.kortix/opencode/`) — (2) the in-depth `kortix.toml` manifest with every key, every trigger field, the secrets contract, the `[[apps]]` deployment surface, (3) the full `kortix` CLI reference (every command, every flag, the project-scoped token model, what works inside a session sandbox with the pre-injected `KORTIX_TOKEN`), (4) the Kortix change-request (CR) system — the mandatory path for landing any session-branch work on `main`, including the rule that an agent MUST open a CR if it wants its changes merged, and (5) the OpenCode runtime reference mirroring opencode.ai/docs/ for agents, skills, commands, tools (built-in + custom), plugins, MCP servers, permissions, rules (AGENTS.md), and models. Load when the user asks how Kortix works, asks about anything in `kortix.toml` or the `kortix` CLI,
Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review. The pr-bot agent loads this on every PR.