This skill brings proven Lean Manufacturing methods into software development. Developed for fabrikIQ, applicable to any TypeScript/React project.
The 4 Pillars of Kaizen
1. Continuous Improvement (Kaizen)
Small, incremental changes instead of big bang refactoring.
Principle: Every commit should leave the code minimally better than it was found.
// VORHER: Grosses Refactoring geplant
// "Ich refactore mal schnell die ganze Auth-Logik"
// KAIZEN: Small steps // Commit 1: Extract validateToken() from auth.ts // Commit 2: Add types for TokenPayload // Commit 3: Replace any with unknown + Type Guard // Commit 4: Write unit test for 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:
// 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
Consistent patterns reduce cognitive load and errors.
API Response Pattern (fabrikIQ Standard):
// 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)
Implement only what is needed NOW.
// 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)
Commands
/why - 5-Whys Root Cause Analysis
Trigger: /why, 5 whys, root cause, warum passiert
Application: For bugs, production incidents, recurring problems
Workflow:
-
Define problem (concrete, measurable)
Problem: API Timeout bei SECOM-Dataset (504 nach 60s) -
Ask "Why?" 5x
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 -
Identify root cause
Root Cause: Fehlende Performance-Testabdeckung fuer grosse Datasets -
Define countermeasure
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:
## 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
Application: For complex problems with multiple possible causes
The 6 M Categories (Manufacturing):
- Man (People): Skills, Training, Communication
- Machine (Machine): Hardware, Tools, Infrastructure
- Material (Material): Input Data, Dependencies
- Method (Method): Processes, Workflows, Patterns
- Measurement (Measurement): Monitoring, Tests, Metrics
- Milieu (Environment): Production, Staging, Local
Workflow:
-
Define effect (right)
Effekt: Login schlaegt intermittierend fehl -
Collect causes by category
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 -
Prioritize most likely causes
-
Plan validation (test hypotheses)
Output Format:
┌─────────────────────────────────────────────────────┐
│ │
┌───────────┐ │ ┌───────────┐ ┌───────────┐ │
│ MENSCH │───┼───│ MASCHINE │ │ MATERIAL │────────────────┤
└───────────┘ │ └───────────┘ └───────────┘ │
│ │ │ │ │
┌────┴────┐ │ ┌────┴────┐ ┌────┴────┐ │
│ Cookies │ │ │ Cold │ │ JWT │ ▼
│ geloescht│ │ │ Start │ │ Rotation│ ┌──────────────┐
└─────────┘ │ └─────────┘ └─────────┘ │ LOGIN │
│ │ FEHLER │
┌───────────┐ │ ┌───────────┐ ┌───────────┐ └──────────────┘
│ METHODE │───┼───│ MESSUNG │ │ MILIEU │────────────────┤
└───────────┘ │ └───────────┘ └───────────┘ │
│ │ │ │ │
┌────┴────┐ │ ┌────┴────┐ ┌────┴────┐ │
│ Kein │ │ │ Keine │ │ Prod vs │ │
│ Retry │ │ │ Alerting│ │ Preview │ │
└─────────┘ │ └─────────┘ └─────────┘ │
│ │
└─────────────────────────────────────────────────────┘
## Priorisierte Hypothesen
| # | Kategorie | Ursache | Wahrscheinlichkeit | Validierung |
|---|-----------|---------|-------------------|-------------|
| 1 | Maschine | Cold Start | Hoch | Logs auf "first request" pruefen |
| 2 | Material | JWT Rotation | Mittel | Secret-Aenderungshistorie pruefen |
| 3 | Methode | Kein Retry | Mittel | Retry-Logik implementieren, messen |
/plan-do-check-act - PDCA Cycle
Trigger: /pdca, /plan-do-check-act, deming cycle, verbesserungszyklus
Application: For feature implementation, refactoring, process improvement
Workflow:
┌─────────────────────┐
│ │
│ ┌─────┐ ───────► ┌─────┐
│ │PLAN │ │ DO │
│ └─────┘ ◄─────── └─────┘
│ ▲ │
│ │ ▼
│ ┌─────┐ ┌─────┐
│ │ ACT │ ◄─────── │CHECK│
│ └─────┘ └─────┘
│ │
└─────────────────────┘
(Iterate)
Phase 1: PLAN
- Define goal (SMART: Specific, Measurable, Achievable, Relevant, Time-bound)
- Formulate hypothesis
- Define success criteria
- Identify risks
## PLAN
**Ziel**: API Response Time < 10s fuer 95% der Requests (aktuell: 30s)
**Deadline**: 2025-01-15
**Hypothese**: Column Sampling auf 50 Spalten reduziert Tokens um 80%
**Erfolgskriterien**:
- [ ] P95 Latency < 10s
- [ ] Keine Qualitaetsverlust in Analyse-Output
- [ ] SECOM-Dataset funktioniert ohne Timeout
**Risiken**:
- Sampling koennte wichtige Spalten ausschliessen
- Nutzer erwarten alle Spalten in Analyse
Phase 2: DO
- Implementation in small steps
- Documentation during implementation
- Isolated changes (feature branch)
## DO
**Branch**: feature/column-sampling
**Commits**:
1. `feat: add MAX_COLUMNS constant (50)`
2. `feat: implement column sampling in fileParser`
3. `test: add SECOM sampling test`
4. `docs: update AGENTS.md with sampling details`
**Notizen**:
- Erste 50 Spalten genommen (alphabetisch)
- TODO: Smarter Algorithmus (Varianz-basiert)
Phase 3: CHECK
- Measure results vs. success criteria
- Document unexpected side effects
- Collect lessons learned
## CHECK
**Messungen**:
| Metrik | Ziel | Ist | Status |
|--------|------|-----|--------|
| P95 Latency | < 10s | 8.2s | OK |
| SECOM Timeout | 0 | 0 | OK |
| Analyse-Qualitaet | Keine Regression | Minor | WARNUNG |
**Beobachtungen**:
- Qualitaet leicht gesunken (fehlende Korrelationen)
- Erste 50 Spalten nicht optimal (viele NaN-Spalten)
**Lessons Learned**:
- Alphabetische Auswahl ist suboptimal
- Varianz-basierte Auswahl wuerde bessere Spalten finden
Phase 4: ACT
- Decide: standardize or iterate?
- Adapt process based on learnings
- Plan the next PDCA cycle
## ACT
**Entscheidung**: ITERIEREN (nicht standardisieren)
**Verbesserungen fuer naechsten Zyklus**:
1. Varianz-basierte Spaltenauswahl implementieren
2. Nutzer-Feedback zu Analyse-Qualitaet einholen
3. A/B-Test: 50 vs 75 Spalten
**Naechster PDCA-Zyklus**:
- Start: 2025-01-16
- Fokus: Smart Column Selection Algorithm
Integration with fabrikIQ
When to use which command?
| Situation | Command | Rationale |
|---|---|---|
| Production bug | /why |
Fast root cause analysis |
| Complex bug with many factors | /cause-and-effect |
Structured cause collection |
| Plan a new feature | /plan-do-check-act |
Iterative implementation |
| Refactoring | /plan-do-check-act |
Measurable improvement |
| Recurring error | /why then /cause-and-effect |
Combined analysis |
Automatic triggers
This skill activates automatically on:
git logwith pattern "fix:" or "hotfix:"- Vercel deployment failures
- Test failures in CI/CD
- Keywords: "bug", "fehler", "timeout", "crash", "regression"
Quality gate integration
After every PDCA cycle:
npx tsc --noEmit # TypeScript Check
npm run build # Build
npm run test # Unit Tests
npm run test:e2e # E2E (optional)
Checklist before code changes
- Continuous improvement: Is the change incremental? (Max 1 feature per commit)
- Poka-yoke: Are errors prevented by types? (No runtime validation where compile-time is possible)
- Standardized work: Does the code follow established patterns? (API response format, error handling)
- Just-in-time: Is only what is needed NOW implemented? (No "for later")
Documentation
After every analysis:
- Store result in
docs/kaizen/file - Commit message with Kaizen reference:
fix: resolve timeout (5-Whys #12) - Lessons learned in CHANGELOG.md
Resources
Developed for fabrikIQ - Manufacturing Intelligence Platform GDPR-compliant | Region fra1 | Dresden AI Insights