---
name: pre-task-existence-check
description: "Vor JEDER nicht-trivialen Aufgabe akkurat prüfen ob die Arbeit schon ganz oder teilweise existiert — Code, Brain, Linear, Memory, Supabase-Chat"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: a797444d-f638-4793-9109-583ec26e97d3
---

Bevor eine nicht-triviale Aufgabe gestartet wird (Skill bauen, Skript schreiben, Service anlegen, Refactor, Feature implementieren): akkurat prüfen ob die Arbeit ganz oder teilweise schon existiert.

**Why:** Kais hat das 13.05.2026 als Standing Order formuliert nach zwei aufeinanderfolgenden Vorfällen in einer Session:
1. AKP-Briefing fragte „Eval-Skill bauen?" — `eval-driven-agent-dev` war seit KAR-75 fertig (10/10 Pilot-Cases)
2. Aria baute Sprint B AI-Radar parallel — `/root/aria/scripts/aria-radar-fetch.py` lief seit 12.05.2026 23:07 mit aktivem systemd-Timer

Aria-Zitat Kais: „Du hast in letzter [Zeit] öfters Sachen gestartet die du bereits gemacht hattest. Überprüfe sehr akkurat IMMER bevor du eine Aufgabe startest. Schaue im Code, im Brain, Supabase chat usw wo es Sinn macht. Dann starte."

**How to apply — Pre-Task-Checklist (überall wo sinnvoll):**
- **Code-Tree**: `ls`, `find`, `grep` auf Ziel-Verzeichnisse für Files mit ähnlichem Namen oder Zweck
- **systemd**: `systemctl list-units --type=service,timer | grep -i <feature>` — gibt es schon Unit?
- **Brain**: `aria-brain-search.py "<feature>"` + Read der Top-Hits, nicht nur Snippet-Konsum
- **Linear**: KAR-Issue-Status (Backlog / In Progress / Done) + Description lesen — UND Sub-Issues + verwandte Issues durchsuchen (mcp__list_issues mit filter, nicht nur das genannte Issue)
- **git log**: für Code-Tasks `git log --all --oneline --grep="<feature>"` + `git log -- <relevant-path>` — gemergeter PR ist „done", auch wenn nicht im aktuellen Branch
- **Memory**: relevante Standing Orders / Pattern checken
- **Supabase Chat-Log**: bei Aufgaben die aus früheren Sessions kommen — `aria-chat-search` oder SQL gegen `aria_chat_log` (wenn der Auftrag „weiterführen" suggeriert)
- **Skills**: `ls /root/.claude/skills/` + SKILL.md lesen bevor neuer Skill angelegt wird
- **Tiefe vor Breite**: erst alle Quellen abklappern, dann ein vollständiges Status-Bild zurück an Kais. Nicht halb-prüfen und mit Implementation starten

**Standing-Order-Verschärfung 14.05.2026 (nach KAR-161-Drift):**
Kais-Zitat: „Immer eine tiefe Linear und Brain Analyse machen und dann alles andere machen. Dann nächste Schritte umsetzen."

- Bei jeder neuen Aufgabe ZUERST: tiefe Linear-Analyse (Issue + Sub-Issues + verwandte + git log) UND tiefe Brain-Analyse (Notes + git history der Notes)
- DANN: vollständiges Status-Bild an Kais (was existiert, was fehlt, was wäre redundant)
- ERST DANACH: Vorschlag für nächste Schritte, NIE Implementation ohne diese Analyse

Drift-Historie 14.05.2026:
1. KAR-179 (aria-brain MCP): existierte als V5 Sprint 6 — Duplikat verworfen
2. KAR-188 (Hybrid-Search PGLite): existierte als KAR-120 (pgvector) — Plan falsch
3. KAR-161 (Schema-Dopplung): KAR-162 + KAR-163 (Sub-Issues, gestern Nacht 22:13 gemerged in PR #36) — Implementation-Branch verworfen

**Wann besonders wichtig:**
- AKP-Briefing-getriggerte „Skill bauen?"-Frage
- Multi-Session-Tasks (Sprint X / Y)
- Backlog-getriggerte Implementation
- „Mach mal das" wenn Kontext fehlt

**Memory-Verwandt:** [[feedback_always_read_brain_proactively]] (Brain reading), [[feedback_subagent_audit_verify_with_repo_docs]] (verify before escalation), [[feedback_brain_documentation_pflicht]] (dokumentieren — die andere Seite)

**Skill-Verwandt (ab 17.05.2026):** `pre-task-supabase-state-check` (Live-Supabase-Check vor Migration-Tasks, KAR-283) — adressiert den Supabase-State-Drift den dieser Standing Order am 15.05.2026 nicht abgefangen hat. `migration-author-checklist` (Authorship-Discipline waehrend Migration-Write, KAR-280).