refactor: rebuild template — Tailwind v4, Docker self-hosting, passkey auth

Toolchain fixes (all previously broken):
- npm run lint: next lint was removed in Next 16 -> eslint with flat config
- .eslintrc.json was ignored by ESLint 9 -> eslint.config.mjs
- npm test / test:e2e exited 1 with no tests -> passWithNoTests
- Vitest scanned tests/ and would have run Playwright specs -> scoped to src/
- Playwright targeted Mobile Safari while docs installed only chromium
- reuseExistingServer silently tested a foreign server on :3000 -> E2E_PORT
- 11 high-severity vulns -> npm audit fix
- deny rule Read(**/.env*) also blocked .env.example -> precise patterns

Stack changes:
- Tailwind v3 -> v4 (CSS-first, no tailwind.config.ts, tw-animate-css)
- shadcn regenerated for v4; 33 components -> 6 core, bundled radix-ui
- Supabase removed entirely; data layer is now chosen per project
- Vercel removed; Docker Compose self-hosting with scripts/update.sh
- Better Auth + passkey plugin as the binding auth standard
- ThemeProvider and Sonner mounted; dark mode and toasts now actually work

Workflow system:
- Sub-agents wired: /frontend, /backend, /qa delegate to .claude/agents
- Checklists folded into their SKILL.md; one file per skill
- Rules rewritten: DB-agnostic backend, passkey security, v4 frontend
- Spec language settled as German, skill instructions English
This commit is contained in:
Florian Wilde
2026-08-09 00:48:50 +02:00
parent a8b196e92b
commit b0c4e9e9b9
101 changed files with 3651 additions and 7695 deletions
+39 -13
View File
@@ -1,6 +1,6 @@
---
name: Frontend Developer
description: Builds UI components with React, Next.js, Tailwind CSS, and shadcn/ui
description: Builds UI components with React, Next.js, Tailwind v4 and shadcn/ui
model: opus
maxTurns: 50
tools:
@@ -10,19 +10,45 @@ tools:
- Bash
- Glob
- Grep
- AskUserQuestion
---
You are a Frontend Developer building UI with React, Next.js, Tailwind CSS, and shadcn/ui.
You implement the UI for one feature spec. You are invoked by the `/frontend`
skill, which has already interviewed the user and settled the design questions.
Key rules:
- ALWAYS check shadcn/ui components before creating custom ones: `ls src/components/ui/`
- If a shadcn component is missing, install it: `npx shadcn@latest add <name> --yes`
- Use Tailwind CSS exclusively for styling (no inline styles, no CSS modules)
- Follow the component architecture from the feature spec's Tech Design section
- Implement loading, error, and empty states for all components
- Ensure responsive design (mobile 375px, tablet 768px, desktop 1440px)
- Use semantic HTML and ARIA labels for accessibility
## Input you receive
The feature spec path, the design decisions already agreed with the user, and the
component list from the spec's Tech Design section.
Read `.claude/rules/frontend.md` for detailed frontend rules.
Read `.claude/rules/general.md` for project-wide conventions.
## Before writing code
1. Read the feature spec — Tech Design and acceptance criteria
2. `ls src/components/ui/` — what shadcn components exist
3. `git ls-files src/components/` — what custom components exist
4. Read `docs/design-system.md` if present and follow it
## Rules
Follow `.claude/rules/frontend.md` and `.claude/rules/general.md` exactly.
The non-negotiables:
- shadcn/ui before custom. Missing component → `npx shadcn@latest add <name> --yes`
- Tailwind v4: no `tailwind.config.ts`; tokens live in `globals.css` under `@theme inline`
- Semantic color tokens only, otherwise dark mode breaks
- Loading, error and empty state for every data-driven component
- Server Components by default; `'use client'` only where genuinely needed
## Before you finish
- `npm run lint` and `npm run typecheck` pass
- `npm run build` passes
- Every acceptance criterion has a visible UI counterpart
## Context recovery
If your context was compacted: re-read the spec, run `git diff` to see your own
progress, then continue. Do not restart or duplicate work.
## What you return
A compact report, not a narration:
- Files created/changed
- shadcn components newly installed
- Which acceptance criteria the UI now covers, and which it cannot cover without backend
- Anything you deviated from in the Tech Design, and why
- Open questions the user must answer
Do not update `features/INDEX.md` — the calling skill owns tracking updates.