aitormf/agent-skills

Verwandelt eine vage oder halb definierte Idee in ein Lastenheft (Problem, Benutzer, User Stories, Anforderungen, Randfälle und Abnahmekriterien) durch ein rundenbasiertes Interview. Verwende es, wenn du aufgefordert wirst, ein Lastenheft zu schreiben, ein Feature zu definieren, Anforderungen zu klären oder von einer Idee zu etwas Umsetzbarem zu gelangen.

Was ist agent-skills?

Diese Fähigkeit führt einen strukturierten, rundenbasierten Interviewprozess durch, um eine unklare Idee in ein vollständiges Lastenheft (Spec) zu verwandeln. Der Agent übernimmt die Gesprächsführung und stellt gezielt Fragen zu Problem, Benutzern, User Stories, Umfang, Randfällen, nicht-funktionalen Anforderungen, Sicherheit und Abnahmekriterien. Offene Fragen werden explizit als Multiple-Choice zur Auswahl gestellt, sodass nie stillschweigend Annahmen getroffen werden. Das Ergebnis ist ein `spec.md` und ggf. ein `plan.md` im Ordner `docs/specs/<Datum>-<Typ>-<Name>/`, die zuerst als Entwurf (`draft`) vorliegen und erst nach Freigabe durch den Benutzer auf `approved` gesetzt werden. Die Fähigkeit ist plattformunabhängig und eignet sich für Agenten wie Claude Code, Cursor oder Codex, die eine Spezifikation für die anschließende Planung benötigen.

Funktioniert mit~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/aitormf/agent-skills/tree/HEAD/skills/idea-to-spec

Dokumentation

Von der Idee zum Lastenheft

Hilf der Person, eine Idee in ein lastenheftreifes Lastenheft zu verwandeln. Du führst das Gespräch; die Person gibt die Antworten.

Artefakte und Status

Jedes Arbeitselement lebt in docs/specs/<YYYYMMDD>-<Typ>-<Name>/. Der Typ folgt Conventional Commits (feat, fix, refactor, docs…) und der Name ist kebab-case. Falls dieses Verzeichnis bereits existiert, hänge -2 an.
spec.md und plan.md tragen status: draft | approved | obsolete in ihrem Frontmatter. Nur eine Person setzt approved.
Wenn du ein genehmigtes Artefakt änderst, setze es zurück auf draft und teile dies mit.
Aufgabenverwaltung (Priorität, Verantwortlicher, Erledigt) ist nicht Aufgabe dieser Fähigkeit: sie lebt im Tracker. Falls es ein Ticket gibt, kommt dessen ID in issue:.

Verhalten

Beginne mit einer Zusammenfassung der Idee in einem kurzen Absatz.
Identifiziere, was fehlt, um ein gutes Lastenheft zu schreiben, und stelle die minimale Anzahl nützlicher Fragen, zuerst die blockierenden.
Konzentriere dich auf das Was und das Warum, nicht auf das Wie: keine Frameworks oder Architektur, es sei denn, die Person fragt danach. Das gehört zu spec-to-plan.
Falls docs/ARCHITECTURE.md existiert, lies es, um die Begriffe des Glossars zu verwenden und Konflikte mit den Prinzipien zu erkennen.

Fragen pro Runde

Problem und erwartetes Ergebnis.
Benutzer und Akteure.
User Stories (was jede*r braucht und warum).
Umfang und Nicht-Umfang.
Verhalten und Randfälle: leere, ungültige oder massive Daten; Ausfälle externer Abhängigkeiten; gleichzeitige Aktionen.
Nicht-funktionale Einschränkungen.
Sicherheit, falls es Daten, Authentifizierung oder externe Eingaben betrifft: Datensensitivität, wer was tun darf, welche Eingaben nicht vertrauenswürdig sind und welche Negativtests benötigt werden.
Abnahmekriterien („Gegeben …, wenn …, dann …“).

Wenn nach einer Runde noch etwas unklar ist, frage nur nach diesem Teil.

Offene Fragen

Nimm niemals stillschweigend eine Antwort an. Stelle bei jeder ungelösten Frage:

[Frage]

A) [Dein Standardvorschlag, falls vorhanden]

B) [Offensichtliche Alternative]

C) Als offene Frage im Lastenheft belassen

D) Andere Antwort

Sie gilt erst als gelöst, wenn die Person antwortet oder sich entscheidet, sie offen zu lassen.

Format jeder Antwort: Was ich verstehe · Offene Fragen · Nächster Schritt.

Umfang

Passe die Tiefe an die Änderung an. Schlage den Pfad vor und lass die Person entscheiden:

Änderung	Artefakte
Einzeiliger Fehler	Keine, oder nur `tasks.md`
Komplexer Fehler	`spec.md` + `tasks.md`
Kleines Feature	`spec.md` + `plan.md` + `tasks.md`
Produktionsfeature oder Architektur-Refactoring	Alles, mit Überprüfung von Lastenheft und Plan

Wann aufhören

Höre auf, wenn genug vorhanden ist für: Ziel, Problem, Benutzer, User Stories, Umfang und Nicht-Umfang, funktionale und nicht-funktionale Anforderungen, Randfälle und Abnahmekriterien.

Dann:

Schlage den Verzeichnisnamen vor und erstelle den Entwurf von spec.md aus assets/spec-template.md mit status: draft. Lösche die optionalen Abschnitte, die nicht zutreffen.
Zeige den Entwurf an und schreibe ihn erst, wenn die Person ihn genehmigt.
Vorgeschlagener nächster Schritt: Überprüfung mit review-spec. Wenn es klein ist und die Person zufrieden ist, kann sie es auf approved setzen und zu spec-to-plan übergehen.