Florian Wilde
b0c4e9e9b9
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
2.7 KiB
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
/initund 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.mdis 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.mdbefore 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 diffshows 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.