AInauten-Joker-Listen

PROMPT Joker-System Tokenmaxxing Füge den Prompt unten in die ChatGPT Work Desktop-App oder Claude Cowork / Code-App ein. „Tokenmaxxing" bedeutet: ungenutztes AI-Kontingent in dauerhaft nützliche Arbeit umwandeln, statt es verfallen zu lassen. Auftrag Du richtest für mich ein persönliches Joker-System ein. Ein Joker ist eine umfangreiche, nicht dringende Aufgabe, die freie AI-Nutzungszeit sinnvoll verwertet und nach dem Start ohne meine Hilfe zu einem prüfbaren Ergebnis kommt. Antworte auf Deutsch. Dieser erste Lauf ist ausschließlich Bestandsaufnahme und Vorschau: Lies die erlaubten Quellen, entwirf das System und zeige mir exakt, was du anlegen würdest. Verändere keine Datei, keine Instructions und keinen Zeitplan. Warte danach auf meine ausdrückliche Freigabe. Regeln Diese Regeln gelten für jeden Teil des Systems – Liste, Instructions-Ergänzung, Wochen-Task und jeden Joker-Lauf: 1. Nur ich starte Joker. Listenpflege und Wochen-Task starten niemals einen Joker, auch keine reine Lesearbeit. 2. Keine externen Wirkungen: keine Veröffentlichung, kein Versand, kein Scheduling, keine Zahlung, Bestellung, DNS-Änderung, Anmeldung oder Rechteausweitung. 3. Keine produktive Datenänderung, keine dauerhafte Löschung. Quelldateien bleiben unverändert; geschrieben wird nur in joker.md, joker-results/ oder einen ausdrücklich freigegebenen isolierten Branch. 4. Keine Secrets, Tokens, Zugangsdaten, privaten Schlüssel oder sensiblen Inhalte lesen oder ins Ergebnis schreiben. .env-Dateien, Schlüsseldateien, OAuth-Zustände und Browserprofile bleiben zu. 5. Private Chatarchive, Chat-Exporte, Session-Logs und Kalender sind nicht stillschweigend freigegeben; sie brauchen eine separate, ausdrückliche Freigabe mit Bestand, Zeitraum und Zweck. 6. Kein „erledigt" ohne gespeicherten und erneut gelesenen Zielzustand. Ziel Drei getrennt freigebbare Bausteine: 1. joker.md – priorisierte, auf mich zugeschnittene Aufgaben. 2. Eine kleine Ergänzung meiner projektbezogenen Instructions, damit passende Kandidaten in normalen Gesprächen erkannt und in joker.md nachgeführt werden. 3. Ein wiederkehrender Vorschlags-Task, der die Liste zu einem von mir bestätigten Zeitpunkt aktualisiert und höchstens drei Joker zum manuellen Start empfiehlt. Bevorzugt werden Joker, die nach dem Lauf weiterarbeiten: ein nutzbares Wissenssystem, getestete Agents, eine eingeführte Routine, eine Vorlage, ein sicherer Prototyp. Ein Audit ist nur dann ein guter Joker, wenn sein Bericht selbst die benötigte Entscheidung ermöglicht oder der Auftrag daraus direkt ein geprüftes, reversibles System baut. Was als Joker zählt Ein Kandidat qualifiziert sich nur, wenn alle Bedingungen erfüllt sind: * mindestens 30 Minuten echte aktive AI-Arbeit (Download-, Warte- oder Renderzeit zählt nicht); kürzere Aufgaben werden nie künstlich aufgebläht; * nach dem Start keine Rückfrage, Freigabe oder Entscheidung von mir; * am Ende mindestens eine konkret benannte lokale Ergebnisdatei oder ein Ergebnispaket mit klarer Einstiegsdatei; * mit vorhandenen Daten, Tools und Rechten realistisch abschließbar; * nicht dringend und kein typischer Auftrag für einen normalen Arbeitstag; * klarer späterer Nutzen: Zeitersparnis, bessere Entscheidung, Wiederverwendung, Risikoreduktion oder ein dauerhaft nutzbarer Ablauf; * vereinbar mit den Invarianten; * klare Stop-Regeln und ein überprüfbares Fertig-Kriterium. Nicht in die Liste gehören: normale To-dos, vage Ideen, reine Unterhaltung, künstlich aufgeblähte Aufgaben, Arbeiten mit menschlichen Zwischenentscheidungen. Laufzeitklassen (grobe Schätzung mit Unsicherheit, keine erfundene Präzision): * S: 30–60 Minuten aktive Arbeit * M: 1–3 Stunden * L: über 3 Stunden Priorisierung (gilt für die Erstliste und den Wochen-Task), je Kriterium 1–5: dauerhafter Nutzen · Passung zu meiner belegten Arbeitsgeschichte · Nutzen pro aktiver Laufzeit · Evidenz der Grundlage · Abschlusswahrscheinlichkeit ohne Rückfrage · niedriges Risiko. Ein Kandidat mit einer 1 bei Evidenz oder Abschlusswahrscheinlichkeit kommt nicht in die Top 3. Wie ein Joker läuft Start. Ich starte einen Joker in einer frischen Session mit: „Starte Joker aus /joker.md". Der Auftrag im Eintrag muss deshalb vollständig und ohne Platzhalter sein. Arbeitsweise. Ein starker Joker lernt aus meiner tatsächlichen Arbeit und baut daraus etwas Benutzbares: 1. Er rekonstruiert aus den freigegebenen Quellen den relevanten Teil meiner bisherigen Arbeit: wiederkehrende Aufgaben, Entscheidungen, Korrekturen, Begriffe, Projekte, Arbeitsweisen. 2. Er benennt Wissenslücken und recherchiert nur diese – möglichst Primärquellen, Links im Ergebnis. Recherche um der Recherche willen zählt nicht als Arbeit. 3. Er baut die kleinste Version, die ich danach wirklich verwenden kann. 4. Er testet an zwei bis drei echten, vorhandenen Fällen; bei sensiblen Daten mit lokalen, anonymisierten Kopien. 5. Er schreibt eine kurze Übergabe: Nutzung, Grenzen, Testresultate, offene Entscheidungen für mich. Ergebnisordner. Jeder Joker schreibt nach joker-results/<ID>-<slug>/ mit mindestens: * README.md – Einstieg und Übergabe; * receipt.md – Start, Ende, geprüfte Quellen, Testresultate, Zwischenstände, offene Entscheidungen. Statuspflege. Der laufende Joker ändert in joker.md genau zwei Dinge: seine Statuszeile und das Aktualisierungsdatum. läuft wird nur durch einen ausdrücklich gestarteten Lauf gesetzt. Zwischenstände. Nach jedem Meilenstein den Stand sichern, damit ein Abbruch keinen Verlust bedeutet. Stoppen. Bei ungeklärter Entscheidung, neuem Rechtebedarf oder Sicherheitsrisiko: Stand sichern, Status blockiert, sicher stoppen. Nach der im Eintrag genannten Obergrenze aktiver Arbeit ohne erreichtes Fertig-Kriterium: Stand sichern, Status teilweise, stoppen. Status * Kandidat – belegt, aber Auftrag noch nicht vollständig oder nicht geprüft * bereit – Auftrag vollständig, Rechte vorhanden, sofort startbar * läuft – ausdrücklich gestartet * teilweise – gestoppt mit gesichertem Zwischenstand * blockiert – braucht eine Entscheidung oder Freigabe von mir; bleibt sichtbar in der aktiven Liste * erledigt – Fertig-Kriterium erreicht, Receipt vorhanden * archiviert – erledigt oder überholt, mit Datum ins Archiv verschoben Phase 1: Read-only-Bestandsaufnahme Ausschließlich lesend: 1. Ermittle den aktuellen Arbeitsbereich und schlage einen sichtbaren, dauerhaften Speicherort für joker.md und joker-results/ vor. Absoluter Pfad, wenn zuverlässig bestimmbar; keinen Pfad erfinden. 2. Prüfe nur Quellen, die im Arbeitsbereich zugänglich, freigegeben und relevant sind: Projektübersichten, Readmes, Aufgabenlisten, Notizen, Statusdateien, wiederkehrende Abläufe, installierte Tools, Metadaten offener Aufgaben. Bevorzuge strukturierte Indizes und aktuelle Statusdateien. 3. Wenn nicht freigegebene Bestände (Invariante 5) einen erkennbaren Nutzen hätten: in der Vorschau Bestand, Zeitraum und Zweck vorschlagen, nicht öffnen. 4. Prüfe, wo projektbezogene Instructions sicher ergänzt werden könnten. Lokal/projektbezogen ist Standard; eine globale Änderung braucht separate Begründung und Freigabe. 5. Prüfe, ob die Umgebung wiederkehrende Tasks unterstützt. Wenn nicht: nur kopierbare Task-Anweisung liefern, keine Automation behaupten. 6. Gehe davon aus, dass du Restbudget und Reset-Zeitpunkt nicht kennst. Frage nicht nach Zugangsdaten. Schlage einen festen Wochenzeitpunkt in der erkannten lokalen Zeitzone vor. Nenne Projekte, Tools, offene Arbeit oder Berechtigungen nur, wenn du sie belegen konntest. Trenne bestätigte Fakten von Annahmen. Phase 2: Vorschau ohne Änderungen A. Joker-Datei * genauer Pfad zu joker.md und joker-results/; * kompakte Tabelle aller Kandidaten: ID, Name, Nutzen in einem Satz, Laufzeitklasse, benötigte Rechte, Priorität; * drei repräsentative Kandidaten vollständig ausformuliert (alle Pflichtfelder aus Phase 4); * geprüfte und bewusst nicht geprüfte Quellen; * vorgeschlagener Umfang für persönliche Bestände (Chats, Notizen, Kalender), ohne sie zu öffnen; * Datenschutz- und Berechtigungsrisiken. B. Instructions-Ergänzung Zeige den vollständigen Block zwischen <!-- JOKER-SYSTEM:START --> und <!-- JOKER-SYSTEM:END -->, höchstens etwa 100 Wörter – Regeln verdichten, nicht aufzählen. Inhaltlich muss er abdecken: * Nachführen ist für den genannten Pfad einmalig freigegeben; fehlt der Pfad oder liegt der Auftrag in einem anderen Arbeitsbereich, wird nichts neu angelegt. * Gespeichert wird nur, was alle Joker-Kriterien erfüllt; wiederkehrende Reibung, mehrfach gelöste Aufgaben und häufige Korrekturen sind Kandidaten, einmalige Kleinigkeiten nicht. * Vor dem Anhängen Duplikate und Erledigtes prüfen. * Nur joker.md ergänzen oder aktualisieren; nie einen Joker starten; externe Aktionen und zusätzliche Rechte bleiben freigabepflichtig. * Änderung in einem Satz melden, dann den eigentlichen Auftrag fortsetzen. Zeige den exakten Zielpfad und einen kleinen Vorher-nachher-Diff. Bestehende Regeln bleiben unverändert. C. Wochen-Task Zeige Name, Zeitpunkt, Zeitzone und den vollständigen Task-Text. Der Task: 1. liest joker.md und das letzte Receipt (Zeitpunkt, geprüfte Quellen); 2. sichtet bevorzugt Quellen, die sich seither verändert haben; 3. ergänzt neue Kandidaten, aktualisiert bestehende, führt Duplikate zusammen; 4. erkennt Abschluss über receipt.md im Ergebnisordner, archiviert Erledigtes und Überholtes mit Status und Datum, löscht nie still; 5. priorisiert nach dem zentralen Schema; 6. schlägt höchstens drei Joker vor, mit Reihenfolge; Parallelität nur bei unabhängigen Quellen, Schreibzielen und Anmeldesitzungen, standardmäßig höchstens zwei parallel; 7. wählt nach Laufzeitklassen, nicht nach erfundenem Restbudget, und sagt das; 8. aktualisiert Liste und ein kurzes Receipt – und startet nichts. Phase 3: Freigabe Schließe die Vorschau mit genau diesen Optionen: * A = nur joker.md und joker-results/ anlegen oder aktualisieren * B = zusätzlich die gezeigte Instructions-Ergänzung einfügen * C = zusätzlich den gezeigten Wochen-Task einrichten (nur mit bestätigtem Zeitpunkt und Zeitzone) * Ä = Änderungswünsche, danach neue Vorschau * N = nichts verändern Empfiehl A+B+C, aber nur ausdrücklich genannte Buchstaben gelten als Freigabe. A erlaubt weder B noch C noch Zugriff auf Bestände nach Invariante 5 – dafür nenne ich Quellen und Zeiträume zusätzlich. Frühere allgemeine Zustimmung, Schweigen oder das Einfügen dieses Prompts sind keine Freigabe. Warte auf meine Antwort. Führe Phase 4 im ersten Turn nicht aus. Phase 4: Nur nach Freigabe einrichten Bei A Erstelle oder aktualisiere joker.md; vorhandene Einträge, Status und Receipts bleiben erhalten. Inhalt: * Titel, Pfadkonfiguration, Erstellungs- und Aktualisierungsdatum; * geprüfte und nicht geprüfte Quellen; * bis zu 15 belegte Kandidaten – wenn nur fünf tragen, bleiben es fünf; * Archiv; Änderungsverlauf. Pflichtfelder je aktivem Eintrag: * stabile ID, prägnanter Name, Status; * belegte Grundlage (interne Quellen mit Pfad) und Grund für die Joker-Eignung; * erwarteter Nutzen; Lieferpfad joker-results/<ID>-<slug>/ mit Einstiegsdatei; * extern zu recherchierende Wissenslücke, falls nötig; * zu bauende Dateien oder Systeme, reale Testfälle, Inhalt der Übergabe; * Laufzeitklasse und Obergrenze aktiver Arbeit; * benötigte Rechte: Lesen lokal, Schreiben lokal, nur falls nötig Netz read-only; * Ausführungsrisiko und konkrete Fehlermöglichkeiten; * Stop-Regeln und überprüfbare Fertig-Kriterien; * vollständiger, direkt startbarer Auftrag ohne Platzhalter. Lies die Datei nach dem Schreiben erneut: Zahl der Einträge, Pflichtfelder, eindeutige Lieferpfade, Mindestlaufzeit, Rechte, Stop-Regeln. Bei B Ergänze exakt den freigegebenen Marker-Block; bei vorhandenem Block nur den Inhalt zwischen den Markern aktualisieren. Zeige den geschriebenen Diff und lies die Zieldatei erneut. Ohne Schreibzugriff: Block zum manuellen Einfügen liefern, B als nicht ausgeführt markieren. Bei C Richte den bestätigten Task mit bestätigtem Zeitpunkt und lokaler Zeitzone über die kleinste vorhandene Scheduling-Funktion ein. Lies die gespeicherte Konfiguration zurück. Ohne Scheduling: vollständige Task-Anweisung liefern, C als nicht ausgeführt markieren. Abschluss Kompakter Receipt: * ausgeführte Bausteine A, B, C; * Pfade der geschriebenen Dateien; * bei B Marker und Diff-Ergebnis; * bei C Name, Zeitplan, Zeitzone, gespeicherter Status; * Ergebnis der Readbacks; * alles, was mangels Fähigkeit, Zugriff oder Freigabe nicht ausgeführt wurde. Anhang: Kalibrierung Die Beispiele zeigen die Qualitätsgrenze; ihre Themen sind keine Vorgabe. Jeder Vorschlag muss aus belegtem Kontext entstehen. Gültiger Joker – Projektfriedhof durchleuchten * Grundlage: Im freigegebenen Projektordner liegen mehrere ähnliche Projektfassungen ohne dokumentierten nächsten Schritt. * Nutzen/Lieferung: joker-results/J03-projektfriedhof/README.md mit Fundstellen, Unterschieden, offenen Entscheidungen, Aufräumplan. * Laufzeitklasse: M, Obergrenze 2 h. * Rechte: Lesen lokal, Schreiben lokal. * Stop-Regeln: Nichts löschen, verschieben, zusammenführen oder überschreiben; unklare Zugehörigkeit als „ungeklärt" markieren. * Fertig, wenn: alle Kandidaten mit Quellenpfad erfasst und drei Stichproben gegen die Originaldateien geprüft. Kein Joker – „Schreibe 50 Social-Media-Posts auf Vorrat" Ablehnen: viel Output, kein belegter Bedarf, kein Veröffentlichungszweck, kein Qualitätsmaßstab. Passende Alternative: ein wiederverwendbares Content-System, an zwei vorhandenen Inhalten getestet. Blockierter Kandidat – „Agent für Support-Anfragen" Als blockiert aufnehmen, nicht starten. Nennen: benötigte Quellen, lesbare Daten, ob nur interne Entwürfe erlaubt sind, welche Freigabe vor einem Test fehlt. Blockiert ist kein Fehlschlag, sondern wartet auf meine Entscheidung. Muster, die oft tragen (nur bei belegtem Bedarf): * Second Brain aus freigegebenen Notizen und Projekten – Index, Quellenbezug, Vorlagen, geprüfte Beispielnotizen; * Rettungskarte für den Workspace – abgebrochene, doppelte, halbfertige Projekte finden, für die wichtigsten Wiederaufnahme-Pakete bauen; * Agentenpaket für nachweislich wiederkehrende Aufgaben – Rolle, Input, Ablauf, Stop-Regeln, Output, Testfälle; * messbare Verbesserung einer vorhandenen App im isolierten Branch – Benchmarks, Vorher-nachher-Bericht für Tempo, Bedienung oder visuelle Klarheit, kein Deployment; * bewusst ambitionierter Wochenend-Build aus Inspirationsmaterial, einer alten Idee oder einem wiederkehrenden Nervfaktor – kleines Game, Dashboard oder lokales Tool mit lauffähigem Prototyp, Tests und Anleitung, kein Deployment; * Produktideen-Labor – meine Fähigkeiten und beobachteten Probleme mit externen Nachfragesignalen abgleichen, die stärksten Ideen nachvollziehbar bewerten; * persönlicher Kurs zu einem konkreten Lernziel – geprüfte Quellen, Übungen, Lernplan, Fortschrittsdatei; * mehrere plausible Zukunftsszenarien aus ausdrücklich gelieferten Annahmen plus realistische Wochenroutine – Fakten, Annahmen und Spekulation getrennt; keine medizinische, rechtliche oder finanzielle Prognose.