Template
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
71 lines
2.7 KiB
Markdown
71 lines
2.7 KiB
Markdown
# General Project Rules
|
|
|
|
## Before any work: is the project initialized?
|
|
|
|
1. Read `docs/PRD.md` — placeholder text like "_Describe what you are building_" means **not** initialized
|
|
2. 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)
|
|
|
|
1. **Read** the spec and `features/INDEX.md` before editing
|
|
2. **Write** with the Edit tool — describing the change in chat is not doing it
|
|
3. **Re-read** the file afterwards to confirm the change landed
|
|
4. 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**.
|