- name
- web-design-reasoning
- description
- Apply content-first web design reasoning to landing pages, portfolios, documentation, tutorials, static sites, redesigns, and design audits where hierarchy, responsive layout, accessibility, SEO, performance, copy, or frontend architecture affect the result. Do not use for backend-only work or mechanical CSS edits that need no design judgment.
# Web Design Reasoning
Turn the Web Design in 4 Minutes research into practical design decisions. Preserve the user's product, framework, brand, and scope; do not clone the tutorial's visual style unless requested.
## Load only what the task needs
1. Read [references/core.md](references/core.md).
2. Read exactly one primary playbook from the table below.
3. Do not read a second playbook; choose by the dominant action.
4. Add only the specialist domains explicitly requested or needed for a concrete risk. For each domain, choose either its installed skill or embedded deep reference, never both by default.
| Task | Primary playbook |
| --- | --- |
| New landing page | [new-landing-page.md](references/playbooks/new-landing-page.md) |
| Portfolio or case study | [portfolio.md](references/playbooks/portfolio.md) |
| Documentation, tutorial, or static content | [documentation-tutorial.md](references/playbooks/documentation-tutorial.md) |
| Redesign an existing interface | [redesign.md](references/playbooks/redesign.md) |
| Accessibility audit | [accessibility-audit.md](references/playbooks/accessibility-audit.md) |
| SEO or discoverability audit | [seo-audit.md](references/playbooks/seo-audit.md) |
| Performance audit | [performance-audit.md](references/playbooks/performance-audit.md) |
| Frontend implementation or component work | [frontend-implementation.md](references/playbooks/frontend-implementation.md) |
| Copy or messaging | [copywriting.md](references/playbooks/copywriting.md) |
| Pre-ship review | [review-and-ship.md](references/playbooks/review-and-ship.md) |
| A-Z source study or evidence audit | [source-audit.md](references/playbooks/source-audit.md) |
Action intent wins over asset type: use `redesign.md` for an existing page being redesigned, and `new-landing-page.md` only when creating a landing page from scratch.
## Decision order
~~~text
content
→ measure/layout
→ typography
→ spacing/rhythm
→ contrast/accessibility
→ grouping/balance
→ color roles
→ brand font/images
→ interaction
→ distribution/next action
~~~
Do not polish a later layer while an earlier layer remains broken.
## Operating rules
- Use real content before placeholder content.
- Prefer semantic HTML and native CSS before JavaScript or a framework.
- Keep architecture proportional to the problem; a linear page does not require an SPA.
- Separate fact, inference, and assumption.
- Measure contrast and performance; visual judgment is not verification.
- Treat fonts and images as identity layers after the layout is usable.
- Treat a CTA as a funnel hypothesis until analytics proves behavior.
- Validate desktop, mobile, keyboard/focus, loading/error states, external links, and navigation state when relevant.
## Optional specialist routing
The embedded references are sufficient for ordinary work. For each selected domain, choose one route:
- Use the installed specialist skill when the user names it or the task needs its complete workflow or tools.
- Otherwise read the matching embedded deep reference.
- Do not load both by default. User instructions, project conventions, this entrypoint, and the primary playbook outrank embedded snapshot language.
- A snapshot's `default`, `must`, or `mandatory` wording is a domain heuristic, not permission to change framework, install dependencies, generate assets, or expand scope.
| Need | Specialist skill | Deep reference |
| --- | --- | --- |
| Visual system and UI implementation | `frontend-design` | [frontend-design/index.md](references/deep/frontend-design/index.md) |
| WCAG and assistive technology | `accessibility-compliance-accessibility-audit` | [accessibility.md](references/deep/accessibility.md) |
| Technical and content SEO | `seo-fundamentals` | [seo.md](references/deep/seo.md) |
| Profiling and runtime performance | `performance-profiling` | [performance.md](references/deep/performance.md) |
| Frontend boundaries and state | `frontend-architecture` | [frontend-architecture.md](references/deep/frontend-architecture.md) |
| Conversion-aware copy | `ai-copywriter:ai-copywriter` | [copywriting/index.md](references/deep/copywriting/index.md) |
Use the smallest sufficient stack and load domains sequentially. Do not invoke all specialists by default; each added domain must map to an explicit deliverable or verified risk.
## Source study
For an A-Z study or evidence audit, use the source-audit playbook; it routes through [web-design-in-4-minutes-study.md](references/deep/web-design-in-4-minutes-study.md). When checking the original repository, use commit `633a949bd6ba3d6b97a295303dc0ac61e61d197b` as the pinned comparison point.
Deep references preserve learned guidance and provenance; they do not prove the current repository, browser runtime, accessibility state, SEO state, or performance state. Verify those against the actual target.
## Reporting contract
Report what was observed, inferred, changed, verified, and remains unknown. Do not claim accessible, SEO-ready, fast, high-converting, or production-ready without the matching check.
Call the tutorial flow an **incremental CSS/JavaScript reveal**. Call it progressive enhancement only after verifying that the no-JavaScript experience remains fully usable.
Ver no GitHub