chore: initial commit (Ausgangszustand der Vorlage)

.claude/rules/general.md

@@ -0,0 +1,75 @@
+# General Project Rules
+
+## New Project Detection (MANDATORY)
+Before starting ANY work, check if the project has been initialized:
+1. Read `docs/PRD.md` - if it still contains placeholder text like "_Describe what you are building_", the project is NOT initialized
+2. Read `features/INDEX.md` - if the features table is empty, no features have been defined
+
+**If the project is not initialized:**
+- Do NOT write any code or create any components
+- Do NOT skip ahead to implementation
+- Instead, tell the user: "This project hasn't been set up yet. Let's start by defining what you want to build. Run `/init` with a description of your idea (e.g. `/init I want to build a task management app`)."
+- If the user already described their idea in the current message, run `/init` automatically with their description
+
+**If the project is initialized but the user requests a feature not yet in INDEX.md:**
+- Guide them to run `/write-spec` first to create the feature spec before any implementation
+
+## Feature Tracking
+- All features are tracked in `features/INDEX.md` - read it before starting any work
+- Feature specs live in `features/PROJ-X-feature-name.md`
+- Feature IDs are sequential: check INDEX.md for the next available number
+- One feature per spec file (Single Responsibility)
+- Never combine multiple independent functionalities in one spec
+
+## Git Conventions
+- Commit format: `type(PROJ-X): description`
+- Types: feat, fix, refactor, test, docs, deploy, chore
+- Check existing features before creating new ones: `ls features/ | grep PROJ-`
+- Check existing components before building: `git ls-files src/components/`
+- Check existing APIs before building: `git ls-files src/app/api/`
+
+## Human-in-the-Loop
+- Always ask for user approval before finalizing deliverables
+- Present options using clear choices rather than open-ended questions
+- Never proceed to the next workflow phase without user confirmation
+
+## Status Updates (MANDATORY - Write-Then-Verify)
+After completing work on any feature, you MUST update tracking files. Follow this exact sequence:
+
+1. **Read** the feature spec (`features/PROJ-X-*.md`) and `features/INDEX.md` BEFORE editing
+2. **Write** your changes using the Edit tool — do NOT just describe what you would write
+3. **Re-read** the file AFTER editing to verify the changes are actually present
+4. **If changes are missing**, repeat step 2 — never claim updates were made without verifying
+
+**What to update in the feature spec:**
+- Status field in the header (Planned → In Progress → In Review → Deployed)
+- Implementation notes: what was built, what changed, any deviations from the original spec
+- Bug fixes or design changes discovered during implementation
+
+**What to update in `features/INDEX.md`:**
+- Feature status column must match the feature spec header
+- Valid statuses: Roadmap → Planned → Architected → In Progress → In Review → Approved → Deployed
+  - **Roadmap**: after `/init` — feature identified, no spec file yet
+  - **Planned**: after `/write-spec`
+  - **Architected**: after `/architecture`
+  - **In Progress**: after `/frontend` or `/backend` starts
+  - **In Review**: after `/qa` starts
+  - **Approved**: after `/qa` passes (no critical/high bugs)
+  - **Deployed**: after `/deploy`
+
+**NEVER do this:**
+- Do NOT say "I've updated the feature spec" without actually calling the Edit tool
+- Do NOT summarize changes in chat as a substitute for writing them to the file
+- Do NOT skip updates because "it's obvious" or "minor"
+
+## File Handling
+- ALWAYS read a file before modifying it - never assume contents from memory
+- After context compaction, re-read files before continuing work
+- When unsure about current project state, read `features/INDEX.md` first
+- Run `git diff` to verify what has already been changed in this session
+- Never guess at import paths, component names, or API routes - verify by reading
+
+## Handoffs Between Skills
+- After completing a skill, suggest the next skill to the user
+- Format: "Next step: Run `/skillname` to [action]"
+- Handoffs are always user-initiated, never automatic