Template

Files

T

Florian Wilde b0c4e9e9b9 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

2026-08-09 00:48:50 +02:00

2.7 KiB

Raw Blame History

General Project Rules

Before any work: is the project initialized?

Read docs/PRD.md — placeholder text like "Describe what you are building" means not initialized
Read features/INDEX.md — an empty feature table means no features defined

Not initialized: do not write code or create components. Say:

"Dieses Projekt ist noch nicht aufgesetzt. Starte mit /init und beschreibe kurz deine Idee (z. B. /init Ich will eine Aufgabenverwaltung bauen)."

If the user already described their idea in that same message, run /init with it directly.

Initialized, but the requested feature is not in INDEX.md: guide the user to /write-spec first.

Feature Tracking

features/INDEX.md is the index — read it before starting anything
Specs live in features/PROJ-X-feature-name.md, IDs are sequential
One feature per spec file. Never combine independent functionality.

Status Flow

Roadmap → Planned → Architected → In Progress → In Review → Approved → Deployed

Status	Set by
Roadmap	`/init` — feature identified, no spec file yet
Planned	`/write-spec`
Architected	`/architecture`
In Progress	`/frontend` or `/backend`
In Review	`/qa` starts
Approved	`/qa` passes with no Critical/High bugs
Deployed	`/deploy`

Status Updates (write, then verify)

Read the spec and features/INDEX.md before editing
Write with the Edit tool — describing the change in chat is not doing it
Re-read the file afterwards to confirm the change landed
If it did not land, repeat step 2

Update in the spec: status header, implementation notes, deviations, bugs found. Update in INDEX.md: the status column must match the spec header.

Never claim a file was updated without having called Edit and verified the result.

File Handling

Read a file before modifying it — never work from memory
After context compaction, re-read before continuing
Verify import paths, component names and API routes by reading, never guess
git diff shows what this session already changed

Git

Commit format: type(PROJ-X): description (feat, fix, refactor, test, docs, deploy, chore)
Check what exists before building: git ls-files src/components/, git ls-files src/app/api/

Human-in-the-Loop

Ask for approval before finalizing a deliverable
Offer clear choices instead of open-ended questions
Never advance to the next phase without confirmation
End each skill with: "Nächster Schritt: /skillname — [Aktion]"

Language

Specs, PRD and acceptance criteria are written in German. Code, comments, commit messages and these instructions stay English.

2.7 KiB Raw Blame History