# 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**.