kaizen

What this skill does

# Kaizen - Continuous Improvement Skill

Dieser Skill bringt bewaehrte Lean Manufacturing Methoden in die Softwareentwicklung. Entwickelt fuer fabrikIQ, anwendbar auf jedes TypeScript/React Projekt.

## Die 4 Saeulen des Kaizen

### 1. Continuous Improvement (Kaizen)
Kleine, inkrementelle Aenderungen statt Big Bang Refactoring.

**Prinzip**: Jeder Commit sollte den Code minimal besser hinterlassen als vorgefunden.

```typescript
// VORHER: Grosses Refactoring geplant
// "Ich refactore mal schnell die ganze Auth-Logik"

// KAIZEN: Kleine Schritte
// Commit 1: Extrahiere validateToken() aus auth.ts
// Commit 2: Fuege Typen fuer TokenPayload hinzu
// Commit 3: Ersetze any mit unknown + Type Guard
// Commit 4: Schreibe Unit Test fuer validateToken()
```

### 2. Poka-Yoke (Error Proofing)
Fehler durch Design verhindern, nicht durch Disziplin.

**TypeScript Constraints**:
```typescript
// FALSCH: Runtime Check (Fehler moeglich)
function processOrder(status: string) {
  if (status !== 'pending' && status !== 'approved') {
    throw new Error('Invalid status');
  }
}

// POKA-YOKE: Compile-Time Constraint (Fehler unmoeglich)
type OrderStatus = 'pending' | 'approved' | 'shipped' | 'cancelled';

function processOrder(status: OrderStatus) {
  // TypeScript verhindert ungueltige Werte
}
```

**Fail-Fast Pattern**:
```typescript
// FALSCH: Spaete Fehlererkennung
async function analyzeData(file: File) {
  const data = await parseFile(file);  // 10 Sekunden
  const result = await geminiAnalyze(data);  // 30 Sekunden
  if (!data.hasRequiredColumns()) {  // Fehler erst nach 40 Sekunden!
    throw new Error('Missing columns');
  }
}

// POKA-YOKE: Fail-Fast (fruehe Validierung)
async function analyzeData(file: File) {
  // Validierung ZUERST (< 1ms)
  const preview = await parseFilePreview(file, 10);
  if (!preview.hasRequiredColumns()) {
    throw new Error('Missing columns');  // Sofort!
  }

  // Teure Operationen NUR wenn valide
  const data = await parseFile(file);
  const result = await geminiAnalyze(data);
}
```

### 3. Standardized Work
Konsistente Patterns reduzieren kognitive Last und Fehler.

**API Response Pattern (fabrikIQ Standard)**:
```typescript
// Standard Response Format
interface ApiResponse<T> {
  success: boolean;
  data?: T;
  error?: {
    code: string;
    message: string;
    details?: unknown;
  };
  meta?: {
    timestamp: string;
    duration_ms: number;
    region: 'fra1';  // DSGVO
  };
}

// Alle Endpoints nutzen dieses Format
export async function handler(req: Request): Promise<Response> {
  const start = Date.now();
  try {
    const result = await processRequest(req);
    return Response.json({
      success: true,
      data: result,
      meta: {
        timestamp: new Date().toISOString(),
        duration_ms: Date.now() - start,
        region: 'fra1'
      }
    });
  } catch (error) {
    return Response.json({
      success: false,
      error: {
        code: error.code ?? 'UNKNOWN_ERROR',
        message: error.message
      }
    }, { status: error.status ?? 500 });
  }
}
```

### 4. Just-In-Time (YAGNI)
Implementiere nur was JETZT gebraucht wird.

```typescript
// FALSCH: "Vielleicht brauchen wir das spaeter"
interface User {
  id: string;
  email: string;
  name: string;
  // "Fuer spaeter"
  avatar?: string;
  preferences?: UserPreferences;
  notifications?: NotificationSettings;
  integrations?: ExternalIntegrations;
  analytics?: UserAnalytics;
}

// YAGNI: Nur aktuelle Requirements
interface User {
  id: string;
  email: string;
  name: string;
}

// Erweitern wenn tatsaechlich benoetigt (mit eigenem Commit)
```

---

## Befehle

### /why - 5-Whys Root Cause Analysis

**Trigger**: `/why`, `5 whys`, `root cause`, `warum passiert`

**Anwendung**: Bei Bugs, Production Incidents, wiederkehrenden Problemen

**Workflow**:

1. **Problem definieren** (konkret, messbar)
   ```
   Problem: API Timeout bei SECOM-Dataset (504 nach 60s)
   ```

2. **5x "Warum?" fragen**
   ```
   Why 1: Warum Timeout?
   → Gemini API braucht >60s fuer Antwort

   Why 2: Warum >60s?
   → Prompt enthaelt 590 Spalten x 1567 Zeilen

   Why 3: Warum so viele Daten?
   → Kein Column Sampling implementiert

   Why 4: Warum kein Sampling?
   → Urspruenglich nur kleine CSVs erwartet

   Why 5: Warum nicht angepasst?
   → Keine automatischen Performance-Tests mit grossen Dateien
   ```

3. **Root Cause identifizieren**
   ```
   Root Cause: Fehlende Performance-Testabdeckung fuer grosse Datasets
   ```

4. **Countermeasure definieren**
   ```
   Massnahme 1: Column Sampling (MAX_COLUMNS = 50) implementieren
   Massnahme 2: Performance-Test mit SECOM in CI/CD hinzufuegen
   Massnahme 3: Timeout-Monitoring mit Alerting einrichten
   ```

**Output-Format**:
```markdown
## 5-Whys Analyse

**Problem**: [Konkrete Beschreibung]
**Datum**: [ISO-8601]
**Betroffene Komponente**: [Datei/Service]

### Analyse

| Level | Frage | Antwort |
|-------|-------|---------|
| Why 1 | Warum [Symptom]? | [Antwort] |
| Why 2 | Warum [Antwort 1]? | [Antwort] |
| Why 3 | Warum [Antwort 2]? | [Antwort] |
| Why 4 | Warum [Antwort 3]? | [Antwort] |
| Why 5 | Warum [Antwort 4]? | [Antwort] |

### Root Cause
[Kernursache in einem Satz]

### Countermeasures
1. **Sofort** (< 1 Tag): [Quick Fix]
2. **Kurzfristig** (< 1 Woche): [Strukturelle Loesung]
3. **Langfristig** (< 1 Monat): [Praevention]
```

---

### /cause-and-effect - Ishikawa Diagram

**Trigger**: `/cause-and-effect`, `/ishikawa`, `/fishbone`, `ursache-wirkung`

**Anwendung**: Bei komplexen Problemen mit mehreren moeglichen Ursachen

**Die 6 M-Kategorien (Manufacturing)**:

1. **Mensch** (People): Skills, Training, Kommunikation
2. **Maschine** (Machine): Hardware, Tools, Infrastructure
3. **Material** (Material): Input-Daten, Dependencies
4. **Methode** (Method): Prozesse, Workflows, Patterns
5. **Messung** (Measurement): Monitoring, Tests, Metriken
6. **Milieu** (Environment): Production, Staging, Local

**Workflow**:

1. **Effekt definieren** (rechts)
   ```
   Effekt: Login schlaegt intermittierend fehl
   ```

2. **Ursachen nach Kategorie sammeln**
   ```
   MENSCH:
   ├── Nutzer loescht Cookies manuell
   └── Admin aendert Session-TTL ohne Kommunikation

   MASCHINE:
   ├── Vercel Cold Start > Session Check
   └── KV Storage Latenz-Spikes

   MATERIAL:
   ├── JWT Secret Rotation nicht synchron
   └── OAuth Token abgelaufen

   METHODE:
   ├── Kein Retry bei Session-Validierung
   └── Keine Graceful Degradation

   MESSUNG:
   ├── Keine Login-Erfolgsrate-Metrik
   └── Kein Alerting bei Auth-Fehlern

   MILIEU:
   ├── Production vs Preview unterschiedliche KV
   └── Lokale Entwicklung ohne echte Auth
   ```

3. **Wahrscheinlichste Ursachen priorisieren**

4. **Validierung planen** (Hypothesen testen)

**Output-Format**:
```
                    ┌─────────────────────────────────────────────────────┐
                    │                                                     │
    ┌───────────┐   │   ┌───────────┐       ┌───────────┐                │
    │  MENSCH   │───┼───│  MASCHINE │       │  MATERIAL │────────────────┤
    └───────────┘   │   └───────────┘       └───────────┘                │
         │          │        │                   │                       │
    ┌────┴────┐     │   ┌────┴────┐         ┌────┴────┐                  │
    │ Cookies │     │   │ Cold    │         │ JWT     │                  ▼
    │ geloescht│    │   │ Start   │         │ Rotation│          ┌──────────────┐
    └─────────┘     │   └─────────┘         └─────────┘          │    LOGIN     │
                    │                                             │    FEHLER    │
    ┌───────────┐   │   ┌───────────┐       ┌───────────┐        └──────────────┘
    │  METHODE  │───┼───│  MESSUNG  │       │   MILIEU  │────────────────┤
    └───────────┘   │   └───────────┘       └───────────┘                │
         │          │        │                   │                       │
    ┌────┴────┐     │   ┌────┴────┐         ┌────┴────┐