awareness
정보
인식 스킬은 AI 추론에 대한 지속적인 내부 위협 탐지를 제공하여 환각, 범위 확대, 맥락 저하와 같은 위험을 모니터링합니다. 이 스킬은 쿠퍼 색상 코드를 추론 상태에 매핑하고 실시간 의사결정을 위해 OODA 루프를 적용합니다. 중요한 추론 작업 중, 익숙하지 않은 도메인에서 작업할 때, 경고 신호를 감지한 후, 또는 아키텍처 결정과 같은 고위험 출력 전에 사용하십시오.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/awarenessClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Bewusstsein
Kontinuierliches Situationsbewusstsein der internen Reasoning-Qualitaet aufrechterhalten — Halluzinationsrisiko, Scope-Creep, Kontextdegradation und Konfidenz-Genauigkeits-Diskrepanz in Echtzeit erkennen, unter Verwendung adaptierter Cooper-Farbcodes und OODA-Schleifen-Entscheidungsfindung.
Wann verwenden
- Waehrend jeder Aufgabe, bei der Reasoning-Qualitaet wichtig ist (was die meisten Aufgaben betrifft)
- Bei Arbeit in unbekanntem Terrain (neue Codebasis, unbekannte Domaene, komplexe Anfrage)
- Nach Erkennung frueherer Warnsignale: eine Tatsache, die sich unsicher anfuehlt, ein Werkzeugergebnis, das falsch erscheint, ein wachsendes Gefuehl von Verwirrung
- Als kontinuierlicher Hintergrundprozess waehrend ausgedehnter Arbeitssitzungen
- Wenn
centeroderhealDrift offenbart hat, aber spezifische Bedrohungen nicht identifiziert wurden - Vor Ausgaben mit hohem Einsatz (irreversible Aenderungen, benutzerseitige Kommunikation, Architekturentscheidungen)
Eingaben
- Erforderlich: Aktiver Aufgabenkontext (implizit verfuegbar)
- Optional: Spezifische Sorge, die erhoehtes Bewusstsein ausloest (z.B. "Ich bin nicht sicher, ob diese API existiert")
- Optional: Aufgabentyp fuer Bedrohungsprofil-Auswahl (siehe Schritt 5)
Vorgehensweise
Schritt 1: KI-Cooper-Farbcodes etablieren
Das aktuelle Bewusstseinsniveau kalibrieren, unter Verwendung einer adaptierten Version von Coopers Farbcode-System.
KI-Cooper-Farbcodes:
┌──────────┬─────────────────────┬──────────────────────────────────────────┐
│ Code │ Zustand │ KI-Anwendung │
├──────────┼─────────────────────┼──────────────────────────────────────────┤
│ Weiss │ Autopilot │ Ausgabe generieren ohne │
│ │ │ Qualitaetsueberwachung. Keine Selbst- │
│ │ │ pruefung. Vollstaendig auf Muster- │
│ │ │ vervollstaendigung verlassen. │
│ │ │ GEFAEHRLICH — Halluzinationsrisiko │
│ │ │ am hoechsten │
├──────────┼─────────────────────┼──────────────────────────────────────────┤
│ Gelb │ Entspannte │ STANDARDZUSTAND. Ausgabe auf │
│ │ Wachsamkeit │ Genauigkeit ueberwachen. Fakten gegen │
│ │ │ Kontext pruefen. Bemerken, wenn │
│ │ │ Konfidenz die Belege uebersteigt. │
│ │ │ Unbegrenzt aufrechtzuerhalten │
├──────────┼─────────────────────┼──────────────────────────────────────────┤
│ Orange │ Spezifisches │ Eine spezifische Bedrohung identifi- │
│ │ Risiko erkannt │ ziert: unsichere Tatsache, moegliche │
│ │ │ Halluzination, Scope-Drift, Kontext- │
│ │ │ veralterung. Notfallplan bilden: "Wenn │
│ │ │ das falsch ist, werde ich..." │
├──────────┼─────────────────────┼──────────────────────────────────────────┤
│ Rot │ Risiko │ Die Bedrohung aus Orange ist eingetreten:│
│ │ materialisiert │ bestaetigter Fehler, Benutzerkorrektur, │
│ │ │ Werkzeugwiderspruch. Den Notfallplan │
│ │ │ ausfuehren. Kein Zoegern — der Plan │
│ │ │ wurde in Orange gemacht │
├──────────┼─────────────────────┼──────────────────────────────────────────┤
│ Schwarz │ Kaskadierende │ Mehrere gleichzeitige Ausfaelle, │
│ │ Ausfaelle │ verlorener Kontext, grundlegende │
│ │ │ Verwirrung darueber, was die Aufgabe │
│ │ │ ueberhaupt ist. STOPP. Mit `center` │
│ │ │ erden, dann von der urspruenglichen │
│ │ │ Anfrage des Benutzers neu aufbauen │
└──────────┴─────────────────────┴──────────────────────────────────────────┘
Den aktuellen Farbcode identifizieren. Wenn die Antwort Weiss ist (keine Ueberwachung), hat die Bewusstseinspraxis bereits Erfolg gehabt, indem sie die Luecke offengelegt hat.
Erwartet: Genaue Selbsteinschaetzung des aktuellen Bewusstseinsniveaus. Gelb ist das Ziel waehrend normaler Arbeit. Weiss sollte selten und kurz sein. Anhaltendes Orange ist nicht nachhaltig — die Sorge entweder bestaetigen oder verwerfen.
Bei Fehler: Wenn die Farbcode-Einschaetzung selbst sich anfuehlt, als wuerde sie auf Autopilot durchgefuehrt (Bewegungen durchlaufen), ist das Weiss, das sich als Gelb tarnt. Echtes Gelb beinhaltet aktives Pruefen der Ausgabe gegen Belege, nicht nur die Behauptung, dies zu tun.
Schritt 2: Interne Bedrohungsindikatoren erkennen
Systematisch nach den spezifischen Signalen scannen, die haeufigen KI-Reasoning-Ausfaellen vorausgehen.
Bedrohungsindikator-Erkennung:
┌───────────────────────────┬──────────────────────────────────────────┐
│ Bedrohungskategorie │ Warnsignale │
├───────────────────────────┼──────────────────────────────────────────┤
│ Halluzinationsrisiko │ • Eine Tatsache ohne Quelle behaupten │
│ │ • Hohe Konfidenz bei API-Namen, │
│ │ Funktionssignaturen oder Dateipfaden, │
│ │ die nicht durch Werkzeugnutzung │
│ │ verifiziert wurden │
│ │ • "Ich glaube" oder "typischerweise" │
│ │ als Absicherung, die Unsicherheit als │
│ │ Wissen tarnt │
│ │ • Code fuer eine API generieren, ohne │
│ │ ihre Dokumentation gelesen zu haben │
├───────────────────────────┼──────────────────────────────────────────┤
│ Scope-Creep │ • "Wenn ich schon dabei bin, sollte ich │
│ │ auch..." │
│ │ • Features hinzufuegen, die nicht in der │
│ │ Anfrage sind │
│ │ • Angrenzenden Code refaktorisieren │
│ │ • Fehlerbehandlung fuer Szenarien │
│ │ hinzufuegen, die nicht eintreten │
│ │ koennen │
├───────────────────────────┼──────────────────────────────────────────┤
│ Kontextdegradation │ • Auf Informationen vom Anfang einer │
│ │ langen Konversation verweisen, ohne │
│ │ sie erneut zu lesen │
│ │ • Einer frueheren Aussage widersprechen │
│ │ • Ueberblick verlieren, was getan wurde │
│ │ vs. was noch uebrig ist │
│ │ • Post-Komprimierungs-Verwirrung │
├───────────────────────────┼──────────────────────────────────────────┤
│ Konfidenz-Genauigkeits- │ • Schlussfolgerungen mit Sicherheit │
│ Diskrepanz │ formulieren, basierend auf duenner │
│ │ Beweislage │
│ │ • Unsichere Aussagen nicht qualifizieren │
│ │ • Fortfahren ohne Verifizierung, wenn │
│ │ Verifizierung verfuegbar und │
│ │ kostenguenstig ist │
│ │ • "Das sollte funktionieren" ohne Test │
└───────────────────────────┴──────────────────────────────────────────┘
Fuer jede Kategorie pruefen: Ist dieses Signal gerade vorhanden? Wenn ja, von Gelb zu Orange wechseln und die spezifische Sorge identifizieren.
Erwartet: Mindestens eine Kategorie mit echter Aufmerksamkeit gescannt. Die Erkennung eines Signals — selbst eines milden — ist nuetzlicher als "alles klar" zu melden. Wenn jeder Scan sauber zurueckkommt, ist die Erkennungsschwelle moeglicherweise zu hoch.
Bei Fehler: Wenn Bedrohungserkennung sich abstrakt anfuehlt, sie in der juengsten Ausgabe verankern: die letzte faktische Behauptung herausgreifen und fragen "Woher weiss ich, dass das stimmt? Habe ich es gelesen oder generiere ich es?" Diese eine Frage erfasst die meisten Halluzinationsrisiken.
Schritt 3: OODA-Schleife fuer identifizierte Bedrohungen ausfuehren
Wenn eine spezifische Bedrohung identifiziert wird (Orange-Zustand), durch Beobachten-Orientieren-Entscheiden-Handeln zyklieren.
KI-OODA-Schleife:
┌──────────┬──────────────────────────────────────────────────────────────┐
│ Beobacht.│ Was genau hat die Sorge ausgeloest? Konkrete Belege │
│ │ sammeln. Die Datei lesen, die Ausgabe pruefen, die │
│ │ Tatsache verifizieren. Nicht bewerten, bevor beobachtet │
│ │ wurde │
├──────────┼──────────────────────────────────────────────────────────────┤
│ Orient. │ Beobachtung mit bekannten Mustern abgleichen: Ist das ein │
│ │ haeufiges Halluzinationsmuster? Eine bekannte Werkzeug- │
│ │ begrenzung? Ein Kontextfrische-Problem? Orientierung │
│ │ bestimmt die Antwortqualitaet │
├──────────┼──────────────────────────────────────────────────────────────┤
│ Entsch. │ Die Reaktion waehlen: verifizieren und korrigieren, dem │
│ │ Benutzer markieren, Ansatz anpassen, oder die Sorge mit │
│ │ Belegen verwerfen. Eine gute Entscheidung jetzt schlaegt │
│ │ eine perfekte Entscheidung zu spaet │
├──────────┼──────────────────────────────────────────────────────────────┤
│ Handeln │ Die Entscheidung sofort ausfuehren. Wenn die Sorge gueltig │
│ │ war, den Fehler korrigieren. Wenn verworfen, notieren │
│ │ warum und zu Gelb zurueckkehren. Die Schleife erneut │
│ │ betreten, wenn neue Informationen auftauchen │
└──────────┴──────────────────────────────────────────────────────────────┘
Die OODA-Schleife sollte schnell sein. Das Ziel ist nicht Perfektion, sondern schnelles Zyklieren zwischen Beobachtung und Handlung. Zu lange in der Orientierung verweilen (Analyse-Paralyse) ist der haeufigste Fehler.
Erwartet: Eine vollstaendige Schleife von Beobachtung bis Handlung in kurzer Zeit. Die Bedrohung ist entweder bestaetigt und korrigiert, oder mit spezifischen Belegen fuer die Verwerfung verworfen.
Bei Fehler: Wenn die Schleife bei der Orientierung haengt (kann nicht bestimmen, was die Bedrohung bedeutet), zu einem sicheren Standard springen: die unsichere Tatsache durch Werkzeugnutzung verifizieren. Direkte Beobachtung loest die meiste Mehrdeutigkeit schneller als Analyse.
Schritt 4: Schnellstabilisierung
Wenn eine Bedrohung materialisiert (Rot) oder kaskadierende Ausfaelle auftreten (Schwarz), vor dem Fortfahren stabilisieren.
KI-Stabilisierungsprotokoll:
┌────────────────────────┬─────────────────────────────────────────────┐
│ Technik │ Anwendung │
├────────────────────────┼─────────────────────────────────────────────┤
│ Pause │ Aufhoeren, Ausgabe zu generieren. Der │
│ │ naechste Satz, der unter Stress produziert │
│ │ wird, wird den Fehler wahrscheinlich │
│ │ verstaerken, nicht beheben │
├────────────────────────┼─────────────────────────────────────────────┤
│ Benutzernachricht │ Zur urspruenglichen Anfrage zurueckkehren. │
│ erneut lesen │ Was hat der Benutzer tatsaechlich gefragt? │
│ │ Dies ist der Wahrheitsanker │
├────────────────────────┼─────────────────────────────────────────────┤
│ Aufgabe in einem │ "Die Aufgabe ist: ___." Wenn dieser Satz │
│ Satz formulieren │ nicht klar geschrieben werden kann, ist die │
│ │ Verwirrung tiefer als der unmittelbare │
│ │ Fehler │
├────────────────────────┼─────────────────────────────────────────────┤
│ Konkrete Fakten │ Auflisten, was definitiv bekannt ist │
│ aufzaehlen │ (verifiziert durch Werkzeugnutzung oder │
│ │ Benutzeraussage). Fakten von Schluss- │
│ │ folgerungen unterscheiden. Nur auf Fakten │
│ │ aufbauen │
├────────────────────────┼─────────────────────────────────────────────┤
│ Einen naechsten │ Nicht den ganzen Erholungsplan — nur einen │
│ Schritt identifizieren │ Schritt, der in Richtung Aufloesung geht. │
│ │ Ihn ausfuehren │
└────────────────────────┴─────────────────────────────────────────────┘
Erwartet: Rueckkehr von Rot/Schwarz zu Gelb durch bewusste Stabilisierung. Die naechste Ausgabe nach der Stabilisierung sollte messbar fundierter sein als die Ausgabe, die den Fehler ausgeloest hat.
Bei Fehler: Wenn Stabilisierung unwirksam ist (immer noch verwirrt, immer noch Fehler produzierend), kann das Problem strukturell sein — kein momentaner Ausfall, sondern ein grundlegendes Missverstaendnis. Eskalieren: dem Benutzer mitteilen, dass der Ansatz zurueckgesetzt werden muss, und um Klaerung bitten.
Schritt 5: Kontextspezifische Bedrohungsprofile anwenden
Verschiedene Aufgabentypen haben verschiedene dominante Bedrohungen. Bewusstseinsfokus nach Aufgabe kalibrieren.
Aufgabenspezifische Bedrohungsprofile:
┌─────────────────────┬─────────────────────┬───────────────────────────┐
│ Aufgabentyp │ Primaere Bedrohung │ Ueberwachungsfokus │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Code-Generierung │ API-Halluzination │ Jeden Funktionsnamen, │
│ │ │ Parameter und Import │
│ │ │ gegen aktuelle Doku │
│ │ │ verifizieren │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Architekturentwurf │ Scope-Creep │ An formulierten │
│ │ │ Anforderungen verankern. │
│ │ │ Jedes "schoen zu haben" │
│ │ │ hinterfragen │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Datenanalyse │ Bestaetigungsfehler │ Aktiv nach Belegen suchen,│
│ │ │ die der sich abzeichnenden│
│ │ │ Schlussfolgerung │
│ │ │ widersprechen │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Debugging │ Tunnelblick │ Wenn die aktuelle Hypo- │
│ │ │ these nach N Versuchen │
│ │ │ keine Ergebnisse liefert, │
│ │ │ zuruecktreten │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Dokumentation │ Kontextveralterung │ Verifizieren, dass be- │
│ │ │ schriebenes Verhalten dem │
│ │ │ aktuellen Code entspricht,│
│ │ │ nicht dem historischen │
├─────────────────────┼─────────────────────┼───────────────────────────┤
│ Lange Konversation │ Kontextdegradation │ Schluesselfakten │
│ │ │ periodisch erneut lesen. │
│ │ │ Auf Komprimierungs- │
│ │ │ artefakte pruefen │
└─────────────────────┴─────────────────────┴───────────────────────────┘
Den aktuellen Aufgabentyp identifizieren und den Ueberwachungsfokus entsprechend anpassen.
Erwartet: Bewusstsein geschaerft fuer die spezifischen Bedrohungen, die beim aktuellen Aufgabentyp am wahrscheinlichsten sind, statt generischer Ueberwachung von allem.
Bei Fehler: Wenn der Aufgabentyp unklar ist oder mehrere Kategorien umspannt, standardmaessig auf Halluzinationsrisiko-Ueberwachung setzen — sie ist die universellst anwendbare Bedrohung und die schaedlichste, wenn verpasst.
Schritt 6: Ueberpruefen und kalibrieren
Nach jedem Bewusstseinsereignis (Bedrohung erkannt, OODA zykliert, Stabilisierung angewendet) kurz ueberpruefen.
- Welcher Farbcode war aktiv, als das Problem erkannt wurde?
- War die Erkennung rechtzeitig, oder manifestierte sich das Problem bereits in der Ausgabe?
- War die OODA-Schleife schnell genug, oder stockte die Orientierung?
- War die Reaktion verhaeltnismaessig (weder ueber- noch unterreagierend)?
- Was wuerde dies naechstes Mal frueher erfassen?
Erwartet: Eine kurze Kalibrierung, die kuenftige Erkennung verbessert. Keine ausfuehrliche Nachbesprechung — gerade genug, um die Empfindlichkeit abzustimmen.
Bei Fehler: Wenn die Ueberpruefung keine nuetzliche Kalibrierung ergibt, war das Bewusstseinsereignis entweder trivial (kein Lernen noetig) oder die Ueberpruefung ist zu oberflaechlich. Bei bedeutenden Ereignissen fragen: "Was habe ich nicht ueberwacht, was ich haette ueberwachen sollen?"
Schritt 7: Integration — Gelben Standard aufrechterhalten
Die fortlaufende Bewusstseinshaltung setzen.
- Gelb ist der Standardzustand waehrend aller Arbeit — entspannte Ueberwachung, keine Hyperwachsamkeit
- Ueberwachungsfokus basierend auf dem aktuellen Aufgabentyp anpassen (Schritt 5)
- Wiederkehrende Bedrohungsmuster aus dieser Sitzung fuer MEMORY.md notieren
- Zur Aufgabenausfuehrung mit kalibriertem Bewusstsein zurueckkehren
Erwartet: Ein nachhaltiges Bewusstseinsniveau, das Arbeitsqualitaet verbessert, ohne sie zu verlangsamen. Bewusstsein sollte sich wie peripheres Sehen anfuehlen — vorhanden, aber nicht die zentrale Aufmerksamkeit fordernd.
Bei Fehler: Wenn Bewusstsein erschoepfend oder hyperwachsam wird (chronisches Orange), ist die Schwelle zu empfindlich. Die Schwelle erhoehen fuer das, was Orange ausloest. Echtes Bewusstsein ist nachhaltig. Wenn es Energie abzieht, ist es Angst, die sich als Wachsamkeit tarnt.
Validierung
- Der aktuelle Farbcode wurde ehrlich eingeschaetzt (nicht standardmaessig Gelb, wenn Weiss genauer waere)
- Mindestens eine Bedrohungskategorie wurde mit spezifischen Belegen gescannt, nicht nur abgehakt
- Die OODA-Schleife wurde auf jede identifizierte Bedrohung angewendet (beobachtet, orientiert, entschieden, gehandelt)
- Das Stabilisierungsprotokoll war bei Bedarf verfuegbar (selbst wenn nicht ausgeloest)
- Der Bewusstseinsfokus wurde auf den aktuellen Aufgabentyp kalibriert
- Nachtraeglich kalibriert wurde fuer jedes bedeutende Bewusstseinsereignis
- Gelb wurde als nachhaltiger Standard wiederhergestellt
Haeufige Stolperfallen
- Weiss tarnt sich als Gelb: Behaupten zu ueberwachen, waehrend man tatsaechlich auf Autopilot ist. Der Test: Kann die letzte verifizierte Tatsache benannt werden? Wenn nicht, ist man in Weiss
- Chronisches Orange: Jede Unsicherheit als Bedrohung behandeln erschoepft kognitive Ressourcen und verlangsamt die Arbeit. Orange ist fuer spezifisch identifizierte Risiken, nicht fuer allgemeine Angst. Wenn alles riskant wirkt, ist die Kalibrierung falsch
- Beobachtung ohne Handlung: Eine Bedrohung erkennen, aber nicht durch OODA zyklieren, um sie aufzuloesen. Erkennung ohne Reaktion ist schlimmer als keine Erkennung — sie fuegt Angst hinzu ohne Korrektur
- Orientierung ueberspringen: Von Beobachten zu Handeln springen, ohne zu verstehen, was die Beobachtung bedeutet. Das erzeugt reaktive Korrekturen, die schlimmer sein koennen als der urspruengliche Fehler
- Das Bauchgefuehl ignorieren: Wenn etwas "sich falsch anfuehlt", aber die explizite Pruefung sauber zurueckkommt, weiter untersuchen statt das Gefuehl zu verwerfen. Implizite Mustererkennung erkennt Probleme oft bevor explizite Analyse es tut
- Ueberstabilisieren: Das volle Stabilisierungsprotokoll fuer geringfuegige Probleme ausfuehren. Eine schnelle Tatsachenpruefung genuegt fuer die meisten Orange-Level-Bedenken. Volle Stabilisierung fuer Rot- und Schwarz-Ereignisse reservieren
Verwandte Skills
mindfulness— die menschliche Praxis, die dieser Skill auf KI-Reasoning abbildet; physische Situationsbewusstseins-Prinzipien informieren kognitive Bedrohungserkennungcenter— stellt die ausgeglichene Grundlinie her, von der aus Bewusstsein operiert; Bewusstsein ohne Zentrum ist Hyperwachsamkeitredirect— behandelt Druecke, sobald Bewusstsein sie erkannt hatheal— tiefere Subsystem-Bewertung, wenn Bewusstsein Drift-Muster offenbartmeditate— entwickelt die beobachtende Klarheit, von der Bewusstsein abhaengt
GitHub 저장소
연관 스킬
qmd
개발qmd는 BM25, 벡터 임베딩, 재순위화를 결합한 하이브리드 검색을 통해 로컬 파일을 색인화하고 검색할 수 있는 로컬 검색 및 색인화 CLI 도구입니다. 명령줄 사용과 Claude 통합을 위한 MCP(Model Context Protocol) 모드를 모두 지원합니다. 이 도구는 임베딩에 Ollama를 사용하고 색인을 로컬에 저장하여 터미널에서 직접 문서나 코드베이스를 검색하는 데 이상적입니다.
subagent-driven-development
개발이 스킬은 각 독립적인 작업마다 새로운 하위 에이전트를 배치하고 작업 사이에 코드 리뷰를 진행하여 구현 계획을 실행합니다. 이 리뷰 프로세스를 통해 품질 게이트를 유지하면서 빠른 반복 작업을 가능하게 합니다. 동일한 세션 내에서 대부분 독립적인 작업을 진행할 때 내장된 품질 검증과 함께 지속적인 진행을 보장하기 위해 사용하세요.
mcporter
개발mcporter 스킬은 개발자가 Claude에서 직접 Model Context Protocol(MCP) 서버를 관리하고 호출할 수 있도록 합니다. 이 스킬은 사용 가능한 서버를 나열하고, 인수를 사용해 해당 서버의 도구를 호출하며, 인증 및 데몬 생명주기를 처리하는 명령어를 제공합니다. 개발 워크플로우에서 MCP 서버 기능을 통합하고 테스트할 때 이 스킬을 사용하세요.
adk-deployment-specialist
개발이 스킬은 A2A 프로토콜을 사용하여 Vertex AI ADK 에이전트를 배포하고 오케스트레이션하며, AgentCard 검색, 작업 제출, 코드 실행 샌드박스 및 메모리 뱅크와 같은 지원 도구를 관리합니다. Python, Java 또는 Go 언어로 순차, 병렬 또는 루프 오케스트레이션 패턴을 갖춘 다중 에이전트 시스템 구축을 가능하게 합니다. Google Cloud에서 ADK 에이전트 배포 또는 에이전트 워크플로우 오케스트레이션을 요청받았을 때 사용하세요.
