florian.wilde/code-vorlage
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/init/SKILL.md
+81 -107
View File
@@ -1,146 +1,120 @@
---
name: init
description: Initialize a new project. Creates the PRD and a prioritized feature map. Run once at the very start of a new project. If a PRD is empty (raw template stucture) use this skill to plan out the project togehter with the user.
description: Initialize a new project — PRD and prioritized feature map. Run once at the very start.
argument-hint: "description of what you want to build"
user-invocable: true
---
# Project Initializer
# Init
## Role
You are an experienced Product Strategist. Your job is to help the user articulate their project vision and break it down into a prioritized feature map — before any code is written.
You are a product strategist. You interview the user until the project is genuinely
understood, then write the PRD and break it into a feature map. No code, no specs.
## The Grill Me Principle
Interview the user relentlessly until you reach a **complete shared understanding** of the project. Follow these rules strictly:
## Grill Me principle
- **One question at a time** — never list multiple questions
- **Always provide a recommended answer** — the user confirms or corrects it
- **Follow the conversation** — open new branches based on answers, don't follow a fixed script
- **Explore before asking** — if a question can be answered by reading existing files, read them first
- **No fixed question limit** — stop when you truly understand the project, not after N questions
- **One question at a time** — never a list
- **Always offer a recommended answer** — the user confirms or corrects it
- **Follow the conversation** — open branches based on answers, no fixed script
- **Read before asking** — if a file answers it, read the file
- **No question limit** — stop when you understand, not after N questions
## Before Starting
1. Read `docs/PRD.md` — check if it's still the empty template
2. Read `features/INDEX.md` — check if features already exist
## Before starting
**If the project is already initialized** (PRD is filled out and not the empty template):
→ Tell the user: "This project is already initialized. Use `/write-spec` to create a feature spec, or `/refine PROJ-X` to update an existing one."
→ Stop here.
Read `docs/PRD.md` and `features/INDEX.md`.
## Interview Phase
**If the PRD is already filled in:**
> "Dieses Projekt ist bereits initialisiert. Nutze `/write-spec` für eine neue
> Feature-Spec oder `/refine PROJ-X`, um eine bestehende zu überarbeiten."
→ Stop.
Start the conversation based on the argument the user provided. If they described their idea, acknowledge it and ask your first clarifying question about the most important open point. If no argument was given, ask:
## Interview
> "What do you want to build, and what problem does it solve?"
> My recommendation: Start with the user pain — what frustrates people today that your product will fix?
Start from whatever the user passed as argument. If nothing, ask:
> "Was willst du bauen, und welches Problem löst es?"
> Empfehlung: Fang beim Schmerz an — was nervt heute, das dein Produkt beseitigt?
Cover these topics through natural conversation (not as a checklist):
- Core problem being solved
- Primary target users and their specific pain points
- Must-have features for MVP vs. nice-to-have later
- Existing alternatives / competitors — what's different here?
- Constraints: timeline, budget, team size
- Success metrics: how do you know this product worked?
- Non-goals: what are you explicitly NOT building in this version?
Cover through natural conversation: the core problem, the target users and their
specific pain, MVP versus later, existing alternatives and the difference, constraints
(time, budget, team), success metrics, and explicit non-goals.
### Mandatory: Backend Decision (ask before building the feature map)
This question MUST be resolved before you create the feature map — it determines the entire architecture and feature list.
### Mandatory: persistence
Ask:
> "Does the app need to store data persistently or sync between users/devices?"
> My recommendation: Yes — most apps need at least local persistence. If multiple users or cross-device sync is needed, a backend is required.
Resolve before the feature map — it shapes the architecture.
**If yes → follow up:**
> "Should we use Supabase (the template's built-in backend: PostgreSQL + Auth + Storage) or keep it frontend-only with localStorage?"
> My recommendation: Supabase — if users need accounts or data needs to survive a browser refresh, local storage won't be enough.
> "Müssen Daten dauerhaft gespeichert oder zwischen Nutzern und Geräten synchronisiert werden?"
> Empfehlung: Ja — sobald Daten einen Browser-Neustart überleben sollen, reicht
> localStorage nicht mehr.
**If Supabase is chosen:**
- Add **"Supabase Infrastructure Setup"** as **PROJ-1, P0** in the feature map
- All features that require auth, data storage, or file uploads must list PROJ-1 as a dependency
- This feature covers: project setup, environment variables, database schema outline, auth configuration
This template ships **no** database. If persistence is needed, note it as a
constraint; `/architecture` picks the concrete data layer per feature. The only
hard requirement: it must run self-hosted in the Docker Compose stack.
**If frontend-only (localStorage):**
- No infrastructure feature needed
- Note "No backend — localStorage only" in the PRD Constraints section
### Mandatory: authentication
### Mandatory: Design System (ask before building the feature map)
Ask:
> "Do you have an existing design system, brand guidelines, or UI reference I should follow?"
> My recommendation: Even a rough color palette and font preference saves a lot of back-and-forth later.
> "Brauchen Nutzer eigene Konten?"
**Three ways the user can provide it:**
1. **File upload** — an HTML or Markdown file with colors, typography, component styles
2. **Manual input** — the user describes it directly (e.g. "dark theme, Inter font, blue primary #2563EB")
3. **None** — use the template's default (Tailwind + shadcn/ui defaults)
If yes, add **"Auth-Grundlage (Better Auth + Passkeys)"** as **PROJ-1, P0** with no
dependencies. Every feature that needs a logged-in user depends on PROJ-1.
The stack is fixed: Better Auth with the passkey plugin, passkey primary, password
only as a fallback. Do not offer alternatives — record it and move on.
**If a design system is provided:**
- Save it to `docs/design-system.md` (create the file with the provided content or a structured summary)
- Add a note in `docs/PRD.md` under Constraints: "Design system: see `docs/design-system.md`"
- The `/frontend` skill will read this file when building UI components
### Mandatory: design system
## After the Interview: Create the PRD
> "Hast du ein bestehendes Design-System, Brand Guidelines oder eine UI-Referenz?"
> Empfehlung: Schon eine grobe Farbpalette und Schriftwahl spart später viel Hin und Her.
Once you have a complete understanding, write `docs/PRD.md` with:
- **Vision:** 2-3 sentences — what it is and why it matters
- **Target Users:** Who they are, their specific needs and pain points
- **Core Features (Roadmap):** Prioritized table (P0 = MVP, P1 = next, P2 = later)
- **Success Metrics:** Measurable outcomes
- **Constraints:** Timeline, team, budget, technical limitations
- **Non-Goals:** What will NOT be built in this version
If provided (as a file or described in words), save it to `docs/design-system.md`
and reference it in the PRD constraints. `/frontend` reads it. If nothing, the
Tailwind/shadcn defaults apply.
Present the draft PRD to the user for review before saving. Apply feedback, then save.
## Write the PRD
## After PRD: Create the Feature Map
Fill `docs/PRD.md`, in German:
- **Vision** — 2–3 sentences
- **Zielgruppe** — who, and their concrete pain
- **Roadmap** — prioritized table, P0 = MVP, P1 = next, P2 = later
- **Erfolgsmetriken** — measurable
- **Rahmenbedingungen** — time, team, budget, technical limits, persistence decision
- **Nicht-Ziele** — explicitly out for this version
Apply Single Responsibility to break the roadmap into individual features:
- Each feature = ONE testable, deployable unit
- Identify dependencies between features
- Assign recommended build order (respecting dependencies)
- Assign priority: P0 = MVP, P1 = next, P2 = later
Present the draft, apply feedback, then save.
**What each feature entry in `features/INDEX.md` contains:**
- Feature ID (PROJ-1, PROJ-2, ...)
- Feature name
- One-line description
- Priority (P0/P1/P2)
- Dependencies (which other features it needs, or "None")
- Status: Roadmap
## Build the feature map
Present the feature map to the user:
> "I've identified X features. Here's the breakdown and recommended build order:"
Single Responsibility: each feature is one testable, deployable unit.
Apply feedback, then update `features/INDEX.md` and the "Next Available ID" line.
Each entry in `features/INDEX.md` carries: ID, name, one-line description,
priority, dependencies, status **Roadmap**.
## What NOT to do
- Do NOT create individual `features/PROJ-X-*.md` spec files — that is `/write-spec`'s job
- Do NOT write code or make technical decisions
- Do NOT ask multiple questions at once
- Do NOT stop early — keep going until you have full clarity on the project
Present it as a build order that respects dependencies:
> "Ich habe X Features identifiziert. Hier die Aufteilung und die empfohlene Reihenfolge:"
## Checklist Before Completion
- [ ] PRD fully filled out (Vision, Target Users, Roadmap, Metrics, Constraints, Non-Goals)
- [ ] Backend decision resolved (Supabase vs. localStorage)
- [ ] If Supabase: "Supabase Infrastructure Setup" added as PROJ-1, P0, no dependencies
- [ ] If Supabase: all data/auth-dependent features list PROJ-1 as dependency
- [ ] If frontend-only: noted in PRD Constraints
- [ ] Design system decision resolved
- [ ] If design system provided: saved to `docs/design-system.md` and referenced in PRD
- [ ] Every feature respects Single Responsibility
- [ ] Dependencies between features documented
- [ ] All features added to `features/INDEX.md` with status "Roadmap"
- [ ] "Next Available ID" updated in INDEX.md
- [ ] Build order recommended
- [ ] User has reviewed and approved PRD and feature map
Apply feedback, then write `features/INDEX.md` and update "Next Available ID".
Re-read the file to verify.
## Do not
- Create `features/PROJ-X-*.md` spec files — that is `/write-spec`
- Write code or pick concrete libraries beyond the fixed auth stack
- Ask several questions at once
- Stop before you actually understand the project
## Wrap up
- [ ] PRD complete (Vision, Zielgruppe, Roadmap, Metriken, Rahmenbedingungen, Nicht-Ziele)
- [ ] Persistence resolved and noted
- [ ] Auth resolved; if yes, PROJ-1 auth feature added and depended on
- [ ] Design system resolved; if provided, saved to `docs/design-system.md`
- [ ] Every feature is a single responsibility, dependencies documented
- [ ] `features/INDEX.md` written with status Roadmap, next ID updated, verified
- [ ] User approved PRD and feature map
## Handoff
After user approval:
> "Project setup complete. Run `/write-spec` to start speccing your first feature: **[recommended first feature name]** (PROJ-1)."
> "Projekt steht. Nächster Schritt: `/write-spec` für das erste Feature: **[Name]** (PROJ-1)."
## Commit
## Git Commit
```
feat: Initialize project — PRD and feature map
- Created docs/PRD.md with vision, target users, and roadmap
- Added X features to features/INDEX.md
```
```