isdoi/ich-habe-eine-idee-skill

Ich habe eine Idee

Halte unfertige, aber möglicherweise wichtige Ideen des Nutzers fest, entwickle sie gemeinsam mit ihm weiter und pflege sie als nachvollziehbares Markdown-Dokument. Bewahre die Autorenschaft des Nutzers; biete das Verständnis, Gegenbeispiele, Lösungsansätze und Übersetzungsfähigkeiten der KI an, überschreite jedoch nicht die Befugnis zur Implementierung.

Kernvertrag

• Eine unabhängige Idee wird nur in einem einzigen lebenden Markdown-Dokument gepflegt.
• Neue Dateien befinden sich standardmäßig unter docs/ideas/IDEA-YYYYMMDD-<slug>.md.
• Das einzige legitime Ergebnis dieses Skills ist die Erstellung oder Aktualisierung dieses Markdowns sowie ein kurzer Dialog mit dem Nutzer.
• Es wird kein Quellcode des Projekts geändert, kein Issue, Task, PRD, Implementierungsplan oder Prototyp erstellt, kein Build, Test oder Deployment ausgeführt und kein Implementierungs-Agent aufgerufen.
• status: shaped bedeutet lediglich, dass die Idee Gestalt angenommen hat; es bedeutet niemals implementation_authorization: granted.
• Ohne ausdrückliche Genehmigung des Autors bleibt implementation_authorization: not-granted.
• Nach Autorisierung durch den Autor wird nur das Dokument aktualisiert, eine Übergabe ausgegeben und dieser Skill beendet; innerhalb dieses Skills darf nicht mit der Arbeit begonnen werden.

1. Bestimmung des Interaktionsmodus

Bestimme nach folgender Priorität:

1. Eindeutige Idee: Der Nutzer verwendet /idea, Ich habe eine Idee, I have an idea oder einen gleichwertigen expliziten Ausdruck. Erfasse sofort, ohne zu fragen, ob ein Dokument erstellt werden soll.

2. Implizite Idee mit hoher Sicherheit: Der Nutzer schlägt etwas Neues, langfristig Entwicklungsfähiges vor, z.B. ein Produkt, eine Erfahrung, eine Architektur oder eine kreative Herangehensweise, etwa „Wäre es nicht gut, wenn …“. Teile dem Nutzer zuerst mit: „Ich habe diese Idee aufgegriffen“, und erfasse sie dann.

3. Vage Absicht: Ein Satz könnte sowohl eine neue Idee als auch eine sofortige Änderung sein, z.B. „Sollte hier nicht ein Export-Button hin?“. Frage nur:

   Schlagen Sie eine Idee vor, die weiterverfolgt werden sollte, oder möchten Sie, dass ich sie jetzt direkt ändere?

   Erstelle kein Dokument, bevor der Nutzer geantwortet hat.

4. Eindeutige Ausführung: Fehler, mechanische Änderungen, konkrete Implementierungen, Faktenfragen oder die Weiterführung bestehender Aufgaben. Löse diesen Skill nicht aus.

5. Vermischung von neuer Idee und Arbeitsauftrag: Führe zuerst diesen Skill aus, um die Idee zu dokumentieren; halte den expliziten Arbeitsauftrag als Autorisierung fest. Beende diesen Skill nach der Übergabe, andere Workflows lesen das Dokument anschließend.

Es ist verboten zu fragen: „Soll ich ein Idea-Dokument erstellen?“. Durch die Installation und Aktivierung dieses Skills hat der Host eine fortlaufende Autorisierung für diesen Workflow zur Ideenerfassung erteilt; falls das Host-Projekt explizite Regeln hat, haben diese Vorrang. Was wirklich geklärt werden muss, ist das Kooperationsmodell, nicht der Dateivorgang.

2. Suchen vor Erstellen

Vor dem Erstellen eines neuen Dokuments muss zunächst gesucht werden:

1. Extrahiere aus der Äußerung des Nutzers Themen, Synonyme, Schlüsselentitäten und mögliche Tags.
2. Suche mit rg in vorhandenen Markdown-Dateien in folgender Reihenfolge:
   • docs/ideas/
   • docs/product/
   • docs/architecture/
   • docs/adr/
3. Lies die relevantesten Kandidatendokumente und beurteile sie semantisch, nicht nur nach Dateinamen.
4. Gehe nach folgenden Regeln vor:
   • Gleiche Idee: Aktualisiere das vorhandene Ideendokument.
   • Vorhandenes Produkt-, Architektur- oder ADR-Dokument, das bereits eine eindeutige Tatsachenquelle ist: Aktualisiere dieses Markdown oder verlinke vom neuen Ideendokument darauf; erstelle keine konkurrierende Schlussfolgerung.
   • Verwandt, aber mit unterschiedlichem Umfang: Erkläre die Überschneidungen und frage, ob das bestehende Dokument fortgeführt oder eine neue unabhängige Idee erstellt werden soll.
   • Keine relevanten Aufzeichnungen: Erstelle ein neues Dokument.
   • Kann nicht festgestellt werden, ob es sich um eine Dublette handelt: Führe nicht automatisch zusammen, lass den Autor über die Identität der Idee entscheiden.

Bevorzuge rg --files und rg -n -i --glob '*.md'. Überspringe Verzeichnisse, die nicht existieren; betrachte das Fehlen von docs/ideas/ nicht als Fehler.

3. Minimale Erfassung

Verwende beim Erstellen die Struktur von assets/idea-record-template.md und fülle alle Platzhalter aus. Halte dich an folgende Regeln:

• Verwende lokales Datum und ISO 8601 Zeit.
• Dateiname im Format IDEA-YYYYMMDD-<slug>.md; slug als kurzes, stabiles ASCII-Kebab-Case.
• id identisch mit dem Dateinamen-Hauptteil, nach der ersten Erstellung unverändert.
• Wenn der Pfad bereits existiert, prüfe zuerst auf Dubletten; füge nur bei Bestätigung einer anderen Idee die kürzeste numerische Erweiterung hinzu, überschreibe niemals.
• Anfangs-status ist captured, version ist 0.1, Implementierungsautorisierung ist not-granted.
• Speichere die Äußerung des Nutzers, die die Richtung der Idee bestimmt, unverändert; vermische keine Paraphrasen der KI mit den Zitaten.
• Schreibe in den „Aktuellen Zustand“ nur das stärkste vorläufige Verständnis und markiere explizit, was noch nicht geformt ist.
• Kennzeichne KI-Schlussfolgerungen als „Einschätzung“ oder „Annahme“, nicht als Entscheidung oder Tatsache des Nutzers.
• Teile dem Nutzer nach der Erstellung oder Aktualisierung den Pfad des Dokuments mit und gehe dann in natürlicher Weise in die Diskussion über.

Erstelle oder aktualisiere nur dieses eine Markdown-Dokument. Erstelle keine weiteren Ergebnisdateien für Indizes, Zusammenfassungen oder Aufgabenverwaltung.

4. Gemeinsame Entwicklung der Idee

Halte in jeder Runde die folgende Reihenfolge ein:

1. Wiederhole zunächst aus Nutzersicht, warum diese Idee gültig ist, um zu zeigen, dass der Ursprung verstanden wurde.
2. Gib den substanziellen Beitrag der KI: Ergänze Struktur, schlage Lösungen vor, zeige Zielkonflikte auf, biete Gegenbeispiele oder Empfehlungen.
3. Konzentriere dich immer nur auf eine Frage, die die Richtung am meisten beeinflussen kann; verwende keine Fragebögen, um den Nutzer zu verhören.
4. Lies Informationen aus Projektdateien selbstständig; frage den Nutzer nicht wiederholt.
5. Unterscheide explizit zwischen Autorenabsicht, Fakten, Einschätzungen, Annahmen, Entscheidungen und offenen Fragen.
6. Aktualisiere dasselbe Dokument, sobald neue Autorenabsichten, wichtige Korrekturen, Entscheidungen, Grenzen oder entscheidende Unbekannte auftauchen:
   • Schreibe den „Aktuellen Zustand“ als neueste, prägnante Momentaufnahme um;
   • Füge in „Entwicklung, Entscheidungen & Grenzen“ den bisherigen Verlauf ein;
   • Hake offene Fragen ab, ändere sie oder füge neue hinzu;
   • Aktualisiere updated_at und den Versionsverlauf.

Aktualisiere das Dokument nicht mechanisch für Floskeln, stilistische Verbesserungen oder wiederholte Inhalte, die das Verständnis nicht verändern.

5. Pflege des Fünf-Block-Dokuments

Behalte die fünf Hauptblöcke der Vorlage und ihre Semantik bei:

1. Aktueller Zustand / Current Shape: Ein-Satz-Definition, Kernwert, aktuelle Empfehlung.
2. Ursprung & Autorenoriginal / Origin & Raw Intent: Ursprünglicher Ausdruck und tatsächlicher Beweggrund; füge Schlüsselzitate nur hinzu, ändere sie nicht stillschweigend.
3. Entwicklung, Entscheidungen & Grenzen / Evolution, Decisions & Boundaries: Diskussionsverlauf, Entscheidungen und Begründungen, verworfene Alternativen, Grenzen und Nicht-Ziele.
4. Offene Fragen & Annahmen / Open Questions & Assumptions: Noch zu klärende Punkte, die die Entscheidung des Autors oder den Nachweis von Fakten erfordern.
5. Versionsverlauf / Changelog: Nur hinzufügen; erkläre, welche Änderungen an Verständnis, Status und Entscheidungen vorgenommen wurden.

Halte Frontmatter und Statusanzeige im Kopfbereich synchron. Der „Aktuelle Zustand“ kann umgeschrieben werden; Autorenoriginal, historische Entscheidungen und der Versionsverlauf dürfen nicht gelöscht werden. Wenn eine frühere Entscheidung verworfen wird, markiere sie als superseded und verlinke die neue Entscheidung; erfinde keinen einmaligen Konsens.

6. Statusübergänge

• captured: Ursprung ist gespeichert, noch keine substanzielle Erkundung begonnen.
• exploring: Mindestens eine substanzielle Diskussion hat das Verständnis verändert oder erweitert.
• shaped: Die KI hat eine vollständige Synthese gegeben, und der Autor hat dies durch natürliche Sprache wie „Ich stimme zu“, „Genau so“, „Passt schon“, „Kann so eingefroren werden“ explizit bestätigt.
• parked: Der Autor hat explizit pausiert, oder die Voraussetzungen für eine Fortsetzung sind noch nicht gegeben; dokumentiere den Pausengrund und die Bedingungen für einen Neustart.
• superseded: Eine neue Idee oder Entscheidung hat diese Idee explizit abgelöst; behalte bidirektionale Verweise bei.

Die KI kann eine Konvergenz vorschlagen, darf aber exploring nicht eigenständig in shaped ändern. Allgemeine Komplimente, das Fragen nach dem nächsten Schritt oder „klingt gut“ gelten nicht automatisch als Arbeitsfreigabe.

7. Implementierungsautorisierung & Übergabe

Betrachte nur eindeutige Äußerungen des Autors als Autorisierung, z.B.:

• „Leg los“
• „Fang an, diese Idee umzusetzen“
• „Autorsiert für die Umsetzung“
• Äußerungen, die im gleichen Kontext dieselbe Bedeutung haben.

Nach Erhalt der Autorisierung:

1. Aktualisiere implementation_authorization auf granted.
2. Speichere das Originalzitat des Autors, den Zeitpunkt und den Umfang der Autorisierung in „Entwicklung“ und „Versionsverlauf“.
3. Gib eine kurze Übergabe aus: Ideen-ID, absoluter Pfad des Dokuments, aktueller Zustand, noch bestehende Unbekannte.
4. Stelle klar, dass dieser Skill beendet ist und der Implementierer zuerst das Markdown lesen muss.
5. Stoppe sofort; rufe keinen Implementierungsskill auf, ändere keinen Quellcode und führe keine Implementierungsbefehle aus.

Die Autorisierung gilt nur für die explizit genannte Idee, nicht für andere Ideen oder über den genannten Umfang hinaus.

8. Ausnahmen & Korrekturen

• Der Autor korrigiert die ursprüngliche Bedeutung: Behalte die alte Aussage bei, dokumentiere die Korrektur in „Entwicklung“ und aktualisiere den aktuellen Zustand.
• Der Autor ändert die Richtung vollständig: Behalte die alte Historie; behandle die neue Richtung als große Wendung derselben Idee, es sei denn, der Autor bestätigt, dass es eine unabhängige Idee ist.
• Nach automatischer Erfassung sagt der Autor: „Das war keine Idee“: Markiere das Dokument als parked, dokumentiere den Grund für die Fehlklassifikation und beginne keine Erkundung.
• Dubletten gefunden: Lösche oder führe sie nicht stillschweigend zusammen; lege die Beweise dar und lass den Autor über die Tatsachenquelle entscheiden.
• Dialog unterbrochen: Behalte den aktuellen Status und die offenen Fragen, sodass der nächste KI-Agent das Dokument fortsetzen kann.

9. Ausgabe gegenüber dem Nutzer

Halte es kurz: Erkläre, welches Dokument aktualisiert wurde, den aktuellen status, den Status der Implementierungsautorisierung und eine Frage, die in dieser Runde am meisten der weiteren Diskussion wert ist. Kopiere nicht das gesamte Dokument erneut in den Chat.