writing-plans

Überblick über den writing-plans Skill

Was der writing-plans Skill macht

Der writing-plans Skill hilft dabei, aus einer Feature-Spec oder einem Anforderungsdokument einen detaillierten Implementierungsplan zu machen, bevor mit dem Coden begonnen wird. Seine Kernaufgabe ist nicht die Ideenfindung, sondern ein umsetzbarer, reviewbarer Plan, der davon ausgeht, dass die implementierende Person nur wenig Kontext zur Codebasis hat und trotzdem klare Hinweise auf Dateiebene, Testschritte und eine sinnvolle Aufgabenreihenfolge braucht.

Für wen sich writing-plans eignet

Dieser Skill ist besonders geeignet für Engineers, Tech Leads und agentengestützte Workflows, die bereits eine klar abgegrenzte Anforderung haben und jetzt einen Ausführungsplan für Requirements Planning benötigen. Besonders nützlich ist er, wenn die Arbeit mehrere Dateien umfasst, Tests und Dokumentation berührt oder an jemanden übergeben wird, der die ursprüngliche Spec nicht selbst verfasst hat.

Der eigentliche Job-to-be-done

Nutzer von writing-plans wollen in der Regel Implementierungsraten vermeiden. Der Mehrwert ist nicht einfach „einen Plan erstellen“, sondern „einen Plan erstellen, dem ein fähiger Engineer ohne versteckte Annahmen folgen kann“. Dazu gehört, welche Dateien angefasst werden, wie sich die Arbeit in kleine Aufgaben zerlegen lässt, was getestet werden muss und an welcher Stelle der Umfang vor der Implementierung besser getrennt werden sollte.

Was diesen Skill von einem generischen Prompt unterscheidet

Der writing-plans skill ist bewusst meinungsstark an den Stellen, die zählen:

• er fordert einen Scope-Check vor der Zerlegung
• er verlangt, Dateiverantwortlichkeiten vor dem Schreiben der Aufgaben zuzuordnen
• er bevorzugt kleine, testbare Schritte statt breiter Phasen
• er geht davon aus, dass auf Implementierungsseite nur wenig Domänenkontext vorhanden ist
• er enthält einen Reviewer-Prompt, um zu prüfen, ob der Plan tatsächlich umsetzbar ist

Damit ist er deutlich stärker als ein Einzeiler wie „write me an implementation plan“, wenn die Qualität der Übergabe wichtig ist.

Wann writing-plans besonders gut passt

Verwende writing-plans, wenn du Folgendes hast:

• eine schriftliche Spec, ein Ticket oder ein Anforderungsdokument
• eine mehrstufige Änderung mit relevanten Implementierungsdetails
• die Notwendigkeit, Code, Tests und Dokumentation gemeinsam zu koordinieren
• ein Repository, in dem Dateigrenzen und Reihenfolge wichtig sind

Wenn du nur eine schnelle Gliederung oder eine grobe Schätzung brauchst, ist das möglicherweise schwergewichtiger als nötig.

So verwendest du den writing-plans Skill

writing-plans Installationskontext

Das Repository stellt innerhalb des Skills keinen eigenen package-spezifischen Installer bereit. Der praktikable writing-plans install-Weg ist daher, die übergeordnete Skill-Sammlung hinzuzufügen und den Skill daraus aufzurufen:

npx skills add https://github.com/obra/superpowers --skill writing-plans

Wenn deine Umgebung einen anderen Skill-Loader verwendet, installiere die Sammlung obra/superpowers und wähle writing-plans aus skills/writing-plans.

Diese Dateien zuerst lesen

Für eine schnelle Bewertung beginne mit:

• skills/writing-plans/SKILL.md
• skills/writing-plans/plan-document-reviewer-prompt.md

SKILL.md beschreibt den eigentlichen Planungsablauf. Der Reviewer-Prompt zeigt, welche Qualitätslatte der Plan erfüllen soll — hilfreich, bevor du dich entscheidest, den Skill produktiv einzusetzen.

Welche Eingaben der Skill braucht

writing-plans usage funktioniert am besten, wenn du Folgendes mitgibst:

• die Ausgangs-Spec bzw. die Anforderungen
• das Ziel-Repository oder den betroffenen Bereich der Codebasis
• Einschränkungen bei Architektur, Tooling, Deadlines oder Abwärtskompatibilität
• den gewünschten Ausgabeort des Plans, falls du nicht den Standardpfad nutzen willst
• ob die Arbeit in mehrere unabhängige Pläne aufgeteilt werden soll

Ohne eine echte Spec erzeugt der Skill oft eine plausibel wirkende Struktur, aber deutlich schwächere Implementierungshinweise.

Mit der vorgeschriebenen Ankündigung starten

Die Upstream-Anweisungen verlangen ausdrücklich, dass der Agent Folgendes ankündigt:

I'm using the writing-plans skill to create the implementation plan.

Wenn du den Skill in einen Agent-Workflow integrierst, solltest du diese Zeile beibehalten. Sie macht den Aufruf sichtbar und reduziert Unklarheit darüber, welcher Planungsstandard gerade angewendet wird.

Vor dem Coden nutzen, idealerweise in einem eigenen Worktree

Der Skill ist für die Planung vor der Implementierung gedacht und erwartet, in einem separaten Worktree zu laufen, der Upstream durch einen Brainstorming-Workflow erzeugt wurde. Auch wenn du dieses genaue Companion-Setup nicht nutzt, bleibt die Absicht wichtig: in einem isolierten Kontext planen, bevor Code geändert wird, damit der Plan ein bewusst erstelltes Artefakt ist und nicht bloß ein Nebenprodukt des Codens.

Wie man aus einem groben Ziel einen starken Prompt macht

Schwacher Prompt:

• „Make a plan for adding billing.“

Stärkerer Prompt:

• “Use the writing-plans skill to create an implementation plan for adding team billing to our SaaS app. Spec: docs/specs/team-billing.md. Repo areas likely involved: apps/web, services/billing, db/schema. Constraints: Stripe is already used for individual billing, do not break existing subscriptions, include migration and rollback considerations, and call out tests and docs. If the spec spans independent subsystems, propose separate plans.”

Warum das funktioniert:

• die Spec wird konkret benannt
• wahrscheinliche Dateien oder Module werden eingegrenzt
• Rahmenbedingungen genannt, die die Zerlegung beeinflussen
• eine Aufteilung des Scopes wird zugelassen, statt alles in einen übergroßen Plan zu pressen

Der Planungsreihenfolge des Skills folgen

Ein guter writing-plans guide sollte der im Repository angelegten Reihenfolge folgen:

1. prüfen, ob die Spec in mehrere separate Pläne aufgeteilt werden sollte
2. Dateien ihren Verantwortlichkeiten zuordnen, bevor Aufgaben heruntergebrochen werden
3. kleine, umsetzbare Implementierungsaufgaben formulieren
4. Tests, Dokumentation und Validierungsschritte aufnehmen
5. den fertigen Plan gegen die Spec prüfen

Das Überspringen des Schritts zur Dateistruktur ist der häufigste Grund für vage Aufgaben.

Was eine gute Ausgabe enthalten sollte

Ein starker Plan aus writing-plans for Requirements Planning sollte in der Regel enthalten:

• das Ziel des Plans und die verlinkte Spec
• die Dateien, die erstellt oder geändert werden
• warum jede Datei existiert oder geändert wird
• Aufgaben, die klein genug sind, um unabhängig umgesetzt und überprüft zu werden
• Testhinweise, nicht nur Coding-Schritte
• Aktualisierungen an Doku oder Migrationen, falls relevant
• genug Detail, damit ein anderer Engineer nicht steckenbleibt

Wenn die Ausgabe vor allem aus groben Themenphasen wie „backend“, „frontend“ oder „QA“ besteht, ist sie wahrscheinlich zu grob.

Standard-Speicherort für Pläne und wann du ihn überschreiben solltest

Der Skill schlägt vor, Pläne hier zu speichern:

docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md

Weiche davon ab, wenn dein Repository bereits eine Planungskonvention hat, etwa docs/plans/ oder specs/implementation/. Entscheidend sind Konsistenz und ein Pfad, den Reviewer später wiederfinden.

So nutzt du den Reviewer-Prompt

Nach dem ersten Entwurf solltest du plan-document-reviewer-prompt.md als Vorlage für einen zweiten Review-Durchgang verwenden. Die Review-Kriterien sind praxisnah:

• Vollständigkeit
• Ausrichtung an der Spec
• Aufgabenzerlegung
• Umsetzbarkeit

Das ist ein wichtiger Unterschied des writing-plans skill: Er hört nicht bei der Generierung auf, sondern liefert gleich einen schlanken Acceptance-Check für das Plan-Artefakt mit.

Praktischer Workflow, der gut funktioniert

Ein verlässlicher Ablauf sieht so aus:

1. Spec und Repository-Kontext zusammentragen
2. writing-plans ausführen
3. prüfen, ob die Aufteilung des Plans sinnvoll ist
4. Dateigrenzen und Aufgabengranularität kontrollieren
5. den Plan mit dem Reviewer-Prompt prüfen
6. den Plan überarbeiten, bevor die Implementierung beginnt

So liefert der Skill den größten Mehrwert als Planungsgate, nicht nur als Schreibabkürzung.

writing-plans Skill FAQ

Ist writing-plans gut für Einsteiger?

Ja, sofern Einsteiger bereits eine einigermaßen konkrete Spec haben. Der Skill gleicht fehlenden Codebasis-Kontext aus, indem er explizite Hinweise zu Dateien und Tests erzwingt. Weniger hilfreich ist er, wenn das eigentliche Problem noch in unscharfer Produktfindung besteht.

Worin unterscheidet sich das davon, eine AI einfach nach einem Implementierungsplan zu fragen?

Generische Prompts liefern oft gut formulierte, aber oberflächliche Pläne. writing-plans ist nützlicher, weil es auf Zerlegung auf Dateiebene, Testbarkeit und saubere Übergabe an die implementierende Person drängt. Das bedeutet in der Praxis meist weniger Nacharbeit, sobald das Coding beginnt.

Wann sollte ich writing-plans nicht verwenden?

Überspringe den Skill, wenn:

• die Änderung sehr klein und lokal ist
• du den Produktumfang noch festlegst
• du eher Architektur-Exploration als Ausführungsplanung brauchst
• die Arbeit bewusst experimentell ist und sich voraussichtlich sofort wieder ändern wird

In solchen Fällen sind leichte Notizen oft sinnvoller als ein formaler Plan.

Erfordert der Skill einen bestimmten Stack oder ein bestimmtes Framework?

Nein. Der Skill ist prozessorientiert statt framework-spezifisch. Seine Hinweise lassen sich über verschiedene Stacks hinweg übertragen, weil sie sich auf Zerlegung, Dateiverantwortlichkeiten, Tests und Reviewbarkeit konzentrieren.

Kann writing-plans mit großen Specs umgehen?

Ja, aber nur, wenn du den Scope-Check ernst nimmst. Die Quelle warnt ausdrücklich davor, dass mehrere unabhängige Subsysteme in der Regel zu separaten Plänen werden sollten. Wenn du alles in einen einzigen riesigen Plan zwingst, leidet fast immer die Qualität der Aufgaben.

Reicht writing-plans allein für Requirements Planning?

Für implementierungsorientiertes Requirements Planning oft ja. Für Anforderungen in der Discovery-Phase nein. Der Skill setzt voraus, dass bereits klar ist, was gebaut werden soll, und nun ein verlässlicher Weg zur Umsetzung benötigt wird.

So verbesserst du den writing-plans Skill

Mehr Kontext zum Repository liefern

Der einfachste Weg, die Ergebnisse von writing-plans zu verbessern, ist das Benennen wahrscheinlicher Verzeichnisse, Module oder Dateien. Der Skill möchte Dateiverantwortlichkeiten früh zuordnen; wenn du potenzielle Touchpoints mitlieferst, wird die Ausgabe konkreter und weniger generisch.

Unabhängige Subsysteme früh trennen

Wenn deine Spec unterschiedliche Themen vermischt, trenne sie, bevor du einen finalen Plan anforderst. Beispiel:

• Auth-Änderungen
• Billing-Änderungen
• Admin-UI-Änderungen

Diese Dinge können produktseitig gemeinsam ausgeliefert werden und trotzdem separate Pläne verdienen, wenn sie unabhängig implementiert und getestet werden können.

Das Mapping der Dateiverantwortlichkeiten explizit anfordern

Wenn der erste Entwurf zu vage ist, fordere gezielt:

• “List each file to add or modify and state its responsibility before writing tasks.”

Das passt eng zur Struktur des Skills und behebt unscharfe Zerlegung meist zuverlässig.

Kleinere Aufgabengranularität erzwingen

Ein häufiger Fehlmodus sind Aufgaben, die zu groß für eine sichere Umsetzung sind. Fordere:

• Aufgaben, die testbaren Fortschritt erzeugen
• klare Grenzen pro Aufgabe
• explizite Validierung nach jeder größeren Änderung

Hier verbessert sich writing-plans usage am deutlichsten: kleinere Aufgaben lassen sich leichter reviewen, zuweisen und umsetzen.

Testanforderungen konkret machen

Bitte nicht nur um „include tests“. Gib stattdessen an:

• welche Testebene relevant ist
• welche vorhandenen Test-Suites aktualisiert werden sollen
• ob Migrations-, Integrations- oder Regressionsprüfungen erforderlich sind

Der Skill gewichtet Tests ohnehin stark, aber bessere Constraints machen den Plan deutlich nützlicher.

Den ersten Entwurf mit reviewer-getriebener Iteration verbessern

Nutze die Reviewer-Vorlage als Redaktionswerkzeug, nicht nur als letzte Hürde. Frage nach dem ersten Plan:

• welche Anforderungen aus der Spec fehlen
• an welchen Stellen Aufgaben nicht handlungsfähig sind
• wo die implementierende Person steckenbleiben könnte
• ob Scope Creep vorliegt

So entsteht ein deutlich schärferer zweiter Entwurf als mit allgemeinen „improve the plan“-Prompts.

Auf diese häufigen Fehlmodi achten

Der writing-plans skill ist schwächer, wenn:

• die Spec unvollständig ist
• Dateigrenzen geraten statt im Repository verankert sind
• Aufgaben Ergebnisse beschreiben, aber keine Implementierungsschritte
• Tests erwähnt werden, aber nicht an konkrete Codeänderungen gebunden sind
• ein übergroßer Plan mehrere unabhängige Deliverables verdeckt

Wenn du so etwas siehst, überarbeite zuerst die Eingaben, bevor du dem Skill die Schuld gibst.

Constraints ergänzen, die Implementierungsentscheidungen verändern

Nützliche Constraints sind unter anderem:

• Anforderungen an Abwärtskompatibilität
• Performance-Erwartungen
• Migrationssicherheit
• Reihenfolge beim Deployment
• Dokumentationspflichten
• Regeln wie keine neuen Abhängigkeiten

Solche Details helfen writing-plans for Requirements Planning, einen Plan zu erzeugen, der zu deiner Umgebung passt statt zu einem generischen Idealbild.

Den Plan an den tatsächlichen Handoff-Anforderungen messen

Der richtige Qualitätstest ist einfach: Könnte ein anderer Engineer mit wenig Kontext anhand dieses Dokuments implementieren, ohne ständig nachfragen zu müssen? Wenn nicht, verbessere den Plan, bis Dateientscheidungen, Aufgabengrenzen und Validierungsschritte explizit sind.

Den Plan DRY und implementierungsfokussiert halten

Die Quellhinweise betonen DRY, YAGNI, TDD und häufige Commits. In der Praxis heißt das: doppelte Aufgaben entfernen, spekulative Arbeit vermeiden und Schritte bevorzugen, die sich schnell coden und verifizieren lassen. Diese Prinzipien beeinflussen die Qualität der Ausgabe stärker als einfach noch mehr Prosa.