---
name: danailab-website-project
description: Run an end-to-end website project through research, visual direction, approval, build, SEO, and verification. Use for creating, redesigning, or revamping a whole site or multi-page web project. Do not use for a single component or isolated style adjustment.
---

# DanAI Lab website project

Produce one coherent website from research through final verification. Keep creative direction, design decisions, and integration in the main context. Use sub-agents for independent work, not to fragment the design.

## Direction and ownership

- The main agent owns research synthesis, visual direction, the design system, final integration, and acceptance.
- Inspect the actual references, files, screenshots, and rendered result whenever a decision depends on them. A report does not replace looking at the design.
- Sub-agents may gather references, inventory assets, audit SEO, check links, or handle isolated implementation. They do not make the final visual decision.
- Do not run parallel changes that touch the same layout, shared component, files, or design system.
- For a revamp, preserve the approved identity, content, behavior, URLs, and working SEO unless the user explicitly approves a change.

## 1. Discovery, assets, and references

- Identify the audience, their primary goal, and the essential pages or actions.
- Inventory the existing identity, typography, logos, images, videos, copy, components, data, and URLs. Record suitability, dimensions where relevant, duplicates, and missing assets.
- Inspect the current site and search setup before a revamp. Separate existing approved work from proposed changes.
- If the `refero-design` skill is available, use it for reference research and the reference lock. Otherwise use the available research tools and supplied references, and state what evidence is missing.
- Study references and relevant competitors for structure, hierarchy, visual choices, and useful content coverage. Do not copy their brand, wording, or unsupported claims.
- Extract concrete invariants: typography, palette, grid, spacing, shapes, density, imagery, motion, and responsive behavior.
- Separate observed facts from recommendations.

## 2. Visual direction and reference lock

- Choose one clear direction before materially changing the design.
- Define the system the project needs: typography, colors, grid, spacing, radii, borders, shadows, icons, imagery, motion, responsive rules, and component roles.
- Trace important choices to a reference, an asset or data fact, the brief, or a user decision. Record them in a short decision ledger.
- State which assets belong in which sections and what should be omitted.
- Make choices that fit the audience and content. Do not average references into a generic default aesthetic.
- Keep the identity consistent across pages without making them mechanically identical.

## 3. Approval gate

- Before the first build or a material redesign, present the research and proposed direction in a readable report or preview. Include the references, page hierarchy, asset plan, reference lock, SEO direction, and numbered decisions the user can answer by number.
- Obtain approval for the overall direction once. Continue across pages and sections without repeatedly stopping for approval while they remain inside the approved direction.
- Ask again only when a new requirement would materially change the visual direction, scope, factual content, URL structure, or production behavior.
- Exception: for a revamp of a live site, also get approval for each page and each batch of produced assets (see section 8). Feedback on real pages catches problems the direction report cannot.

## 4. Build

- Plan ownership of pages, components, and shared files before delegating.
- Implement the primary journey before secondary details.
- Use verified content and real assets. Do not invent testimonials, metrics, clients, results, prices, or business claims.
- If content is missing, use clearly marked placeholders only during development. List them for review and do not publish them.
- Make pages responsive, keyboard accessible, touch friendly, and usable with reduced motion.
- Respect performance with appropriately sized media, reasonable loading, and lightweight animation.

## 5. SEO

- Match every page to one clear search intent and user goal using real evidence when available.
- Check semantic structure, headings, useful titles and descriptions, canonical URLs, internal links, alternative text, and structured data that accurately describes the page.
- Verify `robots.txt`, `sitemap.xml`, and the indexability of public pages.
- Preserve useful existing URLs during a revamp or define reviewed redirects before changing them.
- Do not invent keywords, volumes, rankings, or claims. Flag data that needs a real source.

## 6. Live systems and secrets

- Never print, log, expose, or commit secrets.
- Treat changing production, CMS data, stores, DNS, hosting, or access settings as separate external actions requiring the user's authorization.
- Before an authorized live-data change, record the current value, make the smallest necessary change, verify it through the system's read interface, and record the rollback step.

## 7. Verification

- Compare the rendered result with the approved references at the same viewport size.
- Check at least one desktop and one mobile view, plus intermediate widths that change the layout.
- Test navigation, links, forms, keyboard paths, and important interactions.
- Verify the approved visual rules, responsive behavior, accessibility basics, performance-sensitive media, and SEO implementation.
- Run the project's relevant checks and fix errors caused by the work.
- Have a separate sub-agent critique the screenshots blind: give it only the screenshots and a measurable design bar (minimum type sizes, tap targets, contrast, allowed colors, fonts, radii, and shadows), not the intent or history. Fix what it finds and re-check. The builder's own review does not replace this.
- Finish with a complete visual review led by the main agent. Show screenshots and distinguish browser evidence from code-only checks.

## 8. Revamp of a live site

Apply this section in addition to the steps above when the site already exists and has visitors.

- **Baseline first, read-only.** Capture screenshots of every page at desktop and mobile, a text dump per page, every URL and redirect, titles, descriptions, structured data, integrations, and what loads before consent. When two sources of business data disagree (the site and the business profile, the CMS and the photos), ask the user which one is the truth.
- **One source of truth before rebuilding.** Move the shared header and footer into partials. Put repeated business data (catalogue, menu, prices, hours) in one data file that generates both the visible pages and the structured data, so they cannot disagree.
- **Approve page by page.** Show each rebuilt page before starting the next one. Approval of one page does not approve the next.
- **Prove nothing was lost.** After each page, compare its text with the baseline. Every removed or changed sentence is either deliberate and listed for the user, or a defect. Keep every baseline URL working or redirected.
- **Keep produced images honest.** The real product or photo is the truth for appearance: sides, portions, cooking, natural imperfections. The business data is the truth for counts and contents. Nothing should look better than what the customer receives. Work one category at a time, check every count against the data, show each original next to its new version, and wait for approval before the next batch. Record the model, prompt, and sources. When images are illustrative, offer a short disclosure line such as "Photos for illustration only".
- **Use cache-safe asset names.** Give changed files new names when the host caches assets long-term.
- **Publish only on an explicit go-ahead for that release.** "Looks good" approves the design, not a deployment. After publishing, verify the live site: every baseline URL, the 404 page, new assets, console errors, consent behavior, and the new content. Report the live version and how to roll back.

## Model routing

Follow the project's `CLAUDE.md` when it defines model routing. Otherwise:

- `fable`: research synthesis, information architecture, visual direction, design systems, difficult UX decisions, hard bugs, and final review
- `opus`: complex implementation, multi-page builds, responsive systems, animations, and refactors
- `sonnet`: routine edits, technical SEO, accessibility, tests, documentation, and commits
- `haiku`: quick research, file or asset inventories, link checks, and summaries
- Pass `model` on every Agent call. If a named model is unavailable, use the closest supported model and report the substitution

## Delegation

- Delegate independent research, SEO audits, inventories, link checks, and isolated implementation tasks.
- Work directly when the task is simple, sequential, or depends on the same creative context.
- Give each sub-agent one well-scoped task, the relevant context, clear ownership, and a concrete output.
- Give every shared file or component one owner. Run only tasks that do not depend on each other in parallel.
- Ask sub-agents to report findings, evidence, files changed, checks run, and unresolved risks.
- Read reports first, then inspect the essential source material and changes before deciding or integrating.