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
name, description, argument-hint, user-invocable
| name | description | argument-hint | user-invocable |
|---|---|---|---|
| backend | Build route handlers, data access and Better Auth passkey flows. Use after frontend is built. | PROJ-X or feature-spec-path | true |
Backend
You own the server-side phase for one feature. You do the interview and the review with the user; the Backend Developer sub-agent does the implementation.
1. Load context
- Read
features/INDEX.md - Read the feature spec — Tech Design and the Technical Decisions table
git ls-files src/app/api/andls src/lib/
If the Tech Design does not name a data layer:
"Im Tech Design steht noch nicht, wo die Daten liegen sollen. Diese Vorlage bringt bewusst keine Datenbank mit — das entscheidet
/architecturepro Projekt. Lass uns das dort klären, bevor ich Schema-Code schreibe." → Stop.
2. Clarify the open technical questions
One at a time, each with a recommendation:
- Who may read and write these records? (owner only, shared, role-based)
- What happens on concurrent edits — last write wins, or conflict detection?
- Which validation rules beyond the obvious types?
- Does this feature need rate limiting?
- Does it need authentication? If yes: Better Auth with the passkey plugin is the
standard — see
.claude/rules/security.md. Passkey primary, password only as a fallback.
3. Set status
Update features/INDEX.md and the spec header to In Progress. Verify by
re-reading.
4. Delegate implementation
Invoke the Backend Developer sub-agent with:
- the spec path
- the data-layer decision from the Tech Design
- the answers from step 2
- which frontend components need wiring to real endpoints
Wait for its report. Do not implement in parallel yourself.
5. Review with the user
Walk through the endpoints created and the test results, then:
"Funktionieren die Endpunkte so? Fällt dir ein Randfall ein, den wir noch testen sollten?"
Iterate by sending follow-up instructions to the same sub-agent.
6. Wrap up
Verify before declaring done:
npm test,npm run lint,npm run typecheck,npm run buildpass- Zod validation on every write endpoint
- Session checked in every handler; ownership scoped inside the query
- If auth: passkey is the primary flow
- Indexes on filtered/sorted columns, list queries bounded
- Every new env var is in
.env.example - No secrets in source
- Frontend wired to real endpoints, mock data removed
- Spec updated with implementation notes (written and re-read)
features/INDEX.mdstatus is In Progress- User approved
Handoff
"Backend steht. Nächster Schritt:
/qazum Testen gegen die Acceptance Criteria."
Commit
feat(PROJ-X): Implement backend for [feature name]