Factory Skills: how we ship websites and UI with AI, without Dominik in the loop

01Why this, why now

Two things happened in the same day.

In our morning calls we agreed that the Superapp UI is unstructured: every tool sits at the same level, nothing tells the user where to look first. You two now own the UI. That is the right call. Tayfun uses the tool most, and Enes had the better ideas for it.

In the afternoon Anton showed how he builds websites with Claude today. He built a "Website Factory" skill for an agency in two to three hours. With that skill he relaunched the Digital X Results website in 45 minutes, from start to live, without touching the content. Everyone who saw it said the site feels much more valuable now. Same model as before. What changed: every decision had already been made before the AI started building.

Omni1 sells webdesign as part of Profit Marketing. We want to serve hundreds of clients at some point. That only works if a team member, or an agent, can ship a good website without Dominik reviewing every step. A factory skill is how we get there.

02What a factory skill is, and what it is not

Anton sorts skills into three kinds.

Every important decision is made before the page is built, at the point where changing it costs one sentence instead of a rebuild.

The name comes from the division of labour. The human makes the relevant decisions, the AI executes. AI is excellent at execution. It has no way of knowing what you want. A normal chat session ("build me a landing page, I'll give feedback") makes hundreds of micro-decisions silently, and you spend your time correcting the wrong ones after the fact. The factory pulls those decisions forward and makes them explicit. It takes real thinking to design the factory once. After that, the work is systematic and can be handed to anyone on the team.

03The six gates

This is the website factory as Dominik wants it for Omni1. Anton's version has five gates. We name animation explicitly in Gate 3, because that was the open question in the call.

At every gate the question is the same: "Approve Gate N, or what should be different?" A clear yes is approval. Anything else means rework and ask again.

04The approval protocol

The same six steps at every gate. This is what makes the factory safe to hand to someone else.

1. Write the gate document to disk, or update the page. Nothing important lives only in the chat.
2. Summarise in the chat for a marketing person without dev knowledge. Marketing terms (hero, CTA, conversion) are fine, code jargon is not. Two to four small headings, about a dozen sentences, plus the path to the file.
3. Ask, in these words: "Approve Gate N, or what should be different?"
4. A clear yes is approval. Anything else means rework, then ask again.
5. On approval, set the gate to APPROVED in the status file and move on.
6. Backwards is allowed. If a later insight overturns an earlier decision: stop, change the earlier document, set that gate back to "in progress", get it approved again.

The status file

It lives in the client folder and is the first thing a new session reads.

# Status: <client>

Mode: Website | Landing Page
Booking tool: <name and URL>

- Gate 0 — Context drop: open | complete <date>
- Gate 1 — Design: open | in progress | APPROVED <date>
- Gate 2 — Structure and copy: open | in progress | APPROVED <date>
- Gate 3 — Graphics, features, animation, images: open | in progress | APPROVED <date>
- Gate 4 — Mobile: open | in progress | APPROVED <date>
- Gate 5 — Build plan: open | in progress | APPROVED <date>

## Slices
- [ ] Slice 1 — <one line>

## Open photo gaps (shot list)
<or "none">

## Notes for a new session
<everything decided in chat that a new session must know>

Resume rule: if a status file exists for this client, read every document in the folder first, then continue at the first open gate or slice. Never reopen an approved gate unless the user asks or a later gate has overturned it. At the end of every gate and every slice, tell the user this is a safe point to start a fresh session.

05The build plan, explained

This was the confusing part in the call, so here it is slowly.

By the time you reach Gate 5, the first page is already finished end to end.

It has the approved design, the approved copy, the graphics and features, and it has passed the mobile check. For a landing page that means the product is basically done.

The build plan is the list of everything that is still missing around that page. Typical slices for a website:

• one sub-page per slice, built from the approved blocks and the copy approved in Gate 2
• legal pages (Impressum, Datenschutz) from our templates, merged with the client's existing statements
• tracking, cookie banner
• meta and SEO pass: title, description, Open Graph, JSON-LD, favicon
• closing the shot list gaps (mandatory before launch)
• QA against the launch checklist
• staging deploy, real phone test, then live

You write the plan first, one line per slice, and get the plan approved like a gate. Then you build slice by slice. After every slice: show it in the browser, tick it off in the status file, ask "next slice, or change course?" For a landing page the plan is usually empty. For a funnel with several pages, this is where those pages get planned.

Two rules around it. Staging deploys are free. Going live needs an explicit, separate go in that moment. A gate approval is no launch approval.

06Anatomy of the skill folder, and what we build ourselves

Anton's folder looks like this (the screenshot is in the repo folder):

website-factory/
  SKILL.md                    the workflow: gates, approval protocol, standing rules
  references/
    design-prinzipien.md      what premium looks like for this agency, and what is forbidden
    copy-system.md            tone, vocabulary, CTA rules, banned phrases
    master-kanon.md           the proven page structure and standard page tree
    phasen-baukasten.md       the agency's service phases as reusable content blocks
    launch-checkliste.md      everything checked before go-live
    tech-stack.md             the fixed stack and the deploy path
  assets/
    starter.html              the template every new site starts from
    bausteine.html            the library of proven building blocks, FIX and VARIABLE
    impressum-vorlage.md
    datenschutz-vorlage.md
    deploy-inline.py          bundles CSS and JS into one file when the host needs it

We only have the SKILL.md. The references and assets are the agency's own work, and that is the part that makes a factory good. So we build ours, from material we already have.

The skill itself goes into omni1-projects/.claude/skills/website-factory/. Claude Code only loads skills from the repo it is running in, so it has to live in the shared repo. A private workspace would make it invisible to your sessions.

07Where Flow A, Flow B and block designs fit

Nothing you built is wasted. It slots into the gates.

Enes said it himself on 18 August: "the initial design was bad because our project description was bad." Gate 0 exists for that problem. The factory makes the lesson permanent.

08Part two: a light UI factory for the Superapp

Dominik asked Anton the same question you would ask: does this work for app UI, not just websites? Anton's answer for software has three parts.

1. One design system. Reusable components, so the AI does not reinvent a date picker or a button state every time. For his own product this took a designer a month and a half. We do not need that. We need to write down the components the Superapp already has and treat them as the system.
2. A mockup step. Before any feature is built, all relevant screens with all relevant states are mocked up inside the design system, and you fine-tune the mockups, not the code.
3. A UX flow challenge. You tell the AI what you want to build, and it first thinks the user flow through and challenges it with you, before anything is built.

Anton added one caveat: for a website you do not need this depth. For the Superapp we keep it light too.

What we already decided this morning

• Enes' rollout order stays: Radar redesign first, then the sidebar and the Today's page, then the same pattern on Scout, Writer and the rest.
• Treat these as approved gates: mockup D1 without the status boxes; table rows with action buttons instead of cards; five sidebar categories (Clients, Content, Discover, Sales, Insights); Today's page is a summary at one glance, the six tiles Enes posted are enough; Writer stays, Writing gets a new name (production or pipeline).
• Design principle from Dominik: simplify, reduce cognitive load, a new hire must understand the tool without a walkthrough.

Suggested light gate sequence per UI iteration

Tuesday 8 September is the first review. Dominik's words: "iterate the tool until it's at a functional and nice working level and then I'm fine."

09Standing rules, in every gate

10What we ask of you

Together

• Pick the first pilot for the factory. Candidates: dominikkayser.com V4 (already in progress), ai-kayser.com, or the next client site.
• Bring the skill draft and the Radar redesign to the Tuesday review on 8 September.

Open questions for Dominik

• Which pilot first?
• Formal or informal address as the default for client sites?
• Who approves gates on client projects when Dominik is not available?

Let's jump on a call as soon as you have read this.