context-driven-development

Überblick über das context-driven-development-Skill

Was das context-driven-development-Skill leistet

Das context-driven-development-Skill hilft dir dabei, in einem conductor/-Verzeichnis einen kleinen Satz an Projekt-Kontextartefakten aufzubauen und zu pflegen, damit KI-gestützte Entwicklung auf einer stabilen, wiederverwendbaren Grundlage arbeitet. Statt dein Projekt in jedem Chat erneut zu erklären, definierst du Kerndokumente wie product.md, tech-stack.md, workflow.md und tracks.md und hältst sie aktuell, wenn sich das Projekt weiterentwickelt.

Für wen sich die Installation lohnt

Dieses Skill ist besonders sinnvoll für alle, die mit Conductor-ähnlichen Workflows, KI-Entwicklung über mehrere Sessions oder im Team arbeiten und dabei Produktabsicht, Stack-Entscheidungen und Arbeitsverfolgung über Prompts hinweg konsistent halten müssen. Besonders nützlich ist es für:

• das Aufsetzen neuer Projekte
• das Onboarding eines KI-Agenten in eine bestehende Codebase
• Teams, die wiederverwendbaren Projektkontext wollen
• Nutzer, die zwischen Sessions ständig Kontext verlieren

Der eigentliche Job-to-be-done

Die meisten Nutzer brauchen nicht einfach „mehr Dokumentation“. Sie brauchen KI-Ausgaben, die nicht ständig vom Kurs abkommen. Die praktische Aufgabe von context-driven-development besteht darin, vages, nur für eine Session gültiges Projektwissen in verwaltete Artefakte zu überführen, die Implementierung, Planung und Übergaben dauerhaft überstehen.

Was es von normalem Prompting unterscheidet

Ein normaler Prompt kann deine App einmal beschreiben. Das context-driven-development-Skill gibt dir eine Struktur, um diese Beschreibung über längere Zeit aktuell und intern konsistent zu halten. Der eigentliche Unterschied liegt nicht primär in der Codegenerierung, sondern im Aufbau und in der Synchronisierung von Kontext vor und während der Entwicklung.

Was du bekommst, wenn es passt

Wenn du context-driven-development for Context Engineering einsetzt, liegt der größte Nutzen in besserer Kontinuität:

• klarere Produktabsicht
• dokumentierte Stack-Entscheidungen
• explizite Erwartungen an den Workflow
• nachverfolgbare Arbeitseinheiten statt loser TODOs
• besseres Agenten-Onboarding für Brownfield-Repositories

Wann es keine gute Wahl ist

Überspring dieses Skill, wenn du nur ein einmaliges Code-Snippet brauchst, keine Projektdokumente pflegen willst oder nicht in einem Workflow arbeitest, in dem dauerhafter Kontext spätere Ergebnisse verbessert. Den größten Mehrwert liefert es, wenn am selben Projekt wiederholt gearbeitet wird.

So nutzt du das context-driven-development-Skill

Installationskontext und wo dieses Skill liegt

Dieses Skill stammt aus dem Repository wshobson/agents unter plugins/conductor/skills/context-driven-development. Das übliche Installationsmuster in Skills-fähigen Umgebungen ist:

npx skills add https://github.com/wshobson/agents --skill context-driven-development

Nach der Installation rufst du es in deiner KI-Umgebung dann auf, wenn du Projektkontext aufbauen oder aktualisieren willst, statt direkt in die Implementierung zu springen.

Diese Dateien solltest du vor der ersten Nutzung lesen

Für einen schnellen Start mit möglichst wenig Rätselraten solltest du zuerst diese Dateien lesen:

1. plugins/conductor/skills/context-driven-development/SKILL.md
2. plugins/conductor/skills/context-driven-development/references/artifact-templates.md

SKILL.md erklärt, wann du das Skill einsetzen solltest, wie die Artefakte zusammenhängen und wie der Pflege-Workflow aussieht. references/artifact-templates.md ist der praktische Beschleuniger: Dort siehst du die erwartete Struktur von product.md, tech-stack.md und den zugehörigen Dateien, damit du dem Agenten schneller vollständige Eingaben geben kannst.

Welche Eingaben das context-driven-development-Skill braucht

Das Skill funktioniert am besten, wenn du genug Ausgangsmaterial lieferst, um Kontextartefakte zu erzeugen oder zu aktualisieren. Gute Inputs umfassen meist:

• Projekttyp: Greenfield oder Brownfield
• aktuelle Repository- oder Ordnerstruktur
• Produktzweck und Zielnutzer
• technische Einschränkungen und Stack-Entscheidungen
• Präferenzen für den Entwicklungsworkflow
• aktuelle Roadmap, Meilensteine oder Arbeitspakete
• bestehende Doku wie README.md, Tickets, Architektur-Notizen oder Code

Wenn du nur sagst: „set up context for my app“, wird die Ausgabe generisch. Wenn du Produkt, Stack, Workflow und Belege aus dem bestehenden Repo mitlieferst, werden die Artefakte deutlich handlungsnäher.

Greenfield-Nutzung: ein neues Projekt starten

Bei einem neuen Projekt solltest du context-driven-development verwenden, um die zentralen Artefakte aufzusetzen, bevor viel Code geschrieben wird. Eine gute Anfrage enthält:

• was das Produkt ist
• für wen es gedacht ist
• welche Kernfunktionen im Scope sind und welche nicht
• den erwarteten Stack
• Erwartungen an Deployment und Tests
• wie Arbeit nachverfolgt werden soll

Hier ist das Skill besonders wertvoll, weil es Entscheidungen erzwingt, die sonst oft unscharf bleiben, bis die Implementierung schon begonnen hat.

Brownfield-Nutzung: Kontext aus einem bestehenden Repo extrahieren

Für eine bestehende Codebase solltest du das Skill bitten, den Kontext aus dem Repository abzuleiten und zu strukturieren. Verweise dabei auf:

• den Source-Tree
• Dependency-Dateien
• CI-Konfiguration
• README und Issue-Historie
• bestehende Dokumentation
• Namenskonventionen und Hinweise auf den Workflow

Genau hier entsteht für viele Nutzer schnell echter Einführungsnutzen: Der context-driven-development-Leitfaden hilft dabei, ein Repo, das „funktioniert, aber schwer zu erklären ist“, in Artefakte zu überführen, die ein Agent später wiederverwenden kann.

Die zentralen Artefakte und wofür sie jeweils da sind

Das Repository konzentriert sich auf einige dauerhafte Dateien in conductor/:

• product.md: Problem, Nutzer, Lösung, Features, Metriken, Roadmap
• tech-stack.md: Sprachen, Frameworks, Dependencies, Infrastruktur, Tools
• workflow.md: wie Entwicklung konkret ablaufen soll
• tracks.md: Arbeitseinheiten, Status oder die laufende Struktur der Auslieferung

Wichtig ist nicht nur, dass Dateien erstellt werden, sondern dass sie zueinander passen. Produktentscheidungen sollten mit den Stack-Entscheidungen übereinstimmen, Workflow-Regeln zur Teamrealität passen, und nachverfolgte Arbeit sollte mit Roadmap und Implementierungsprioritäten abgestimmt sein.

Aus einem groben Ziel einen starken context-driven-development-Aufruf machen

Ein schwacher Prompt:

• „Use context-driven-development for my project.“

Ein stärkerer Prompt:

• „Use context-driven-development to create initial conductor/ artifacts for a brownfield SaaS repo. Infer product scope from README.md, src/, and issue labels. Capture stack choices from package.json, Docker config, and CI. Create product.md, tech-stack.md, workflow.md, and tracks.md. Flag assumptions separately from confirmed facts.”

Warum das besser funktioniert:

• es benennt den Zustand des Repos
• es benennt die Zielartefakte
• es nennt die Belegquellen
• es verlangt die Trennung von Annahmen und Fakten

Empfohlener Workflow für die erste Einführung

Ein praxisnaher context-driven-development-Ablauf für den Einstieg:

1. Aktuelle Belege aus Repo und Dokumentation zusammentragen.
2. Das Skill bitten, die zentralen conductor/-Artefakte zu entwerfen.
3. Auf sachliche Fehler und fehlende Einschränkungen prüfen.
4. Widersprüche zwischen Produkt-, Stack- und Workflow-Dokumenten auflösen.
5. Erst danach mit Implementierungs- oder Planungsaufgaben starten, die auf diesen Artefakten aufbauen.
6. Das Skill nach größeren Änderungen an Scope, Architektur oder Workflow erneut ausführen.

Diese Reihenfolge ist wichtig, weil das Skill darauf ausgelegt ist, nachgelagerte Arbeit zu verbessern, nicht nur einmal Dokumente zu erzeugen.

So nutzt du die Artefakt-Templates sinnvoll

Die Datei references/artifact-templates.md ist besonders hilfreich, wenn dem Skill nur Teilinformationen vorliegen. Statt den Agenten fehlende Abschnitte erfinden zu lassen, solltest du direkte Antworten zu Template-Feldern geben, etwa zu:

• Ziel-Personas
• Feature-Status
• Erfolgsmetriken
• Begründung für Dependencies
• Hosting-Entscheidung
• Test- und Lint-Toolchain

Je mehr du aus dem Template mit realen Einschränkungen füllen kannst, desto weniger Nacharbeit fällt später an.

Praktische Tipps, die die Ausgabequalität spürbar verbessern

Für bessere Ergebnisse mit context-driven-development:

• bitte den Agenten, Unbekanntes ausdrücklich zu markieren
• trenne Ist-Zustand und angestrebten Soll-Zustand
• sag ihm, ob Entscheidungen fest, vorläufig oder noch offen sind
• gib Beispiele eures Team-Workflows, wenn workflow.md wichtig ist
• verlange Konsistenzprüfungen, bevor du die Artefakte übernimmst

Ein nützliches Muster ist: „Draft, then validate for cross-file contradictions.“ So lassen sich Inkonsistenzen erkennen, etwa wenn die Roadmap mobile Apps verspricht, während Stack und Workflow klar auf ein reines Web-MVP hindeuten.

FAQ zum context-driven-development-Skill

Lohnt sich context-driven-development, wenn ich ohnehin gute Prompts schreibe

Meistens ja, wenn du am selben Projekt regelmäßig weiterarbeitest. Gute Prompts helfen in einer einzelnen Session. Das context-driven-development-Skill hilft dir dabei, belastbaren Kontext aufzubauen, auf den spätere Prompts verweisen können, statt ihn jedes Mal neu zu konstruieren.

Ist das anfängerfreundlich

Ja, aber nur, wenn du bereit bist, grundlegende Projektfragen zu beantworten. Das Skill gibt Struktur, nicht automatisch fachliche Klarheit. Anfänger mit vagen Projektzielen bekommen weiterhin eher generische Artefakte, solange Nutzer, Features und Rahmenbedingungen nicht konkreter definiert sind.

Funktioniert es nur mit Conductor

Es ist für Conductor-ähnliche Kontextartefakte konzipiert, daher passt es dort am besten. Die zugrunde liegende Methode ist aber übertragbar: strukturierte Dokumente zu Produkt, Stack, Workflow und Tracking helfen auch in anderen KI-gestützten Setups.

Wo liegt die wichtigste Grenze des Skills

Es ersetzt weder Implementierungserfahrung noch eine Systemdesign-Prüfung. context-driven-development ist am stärksten, wenn es darum geht, Projektkontext zu organisieren, Beziehungen zwischen Artefakten sichtbar zu machen und Dokumentation mit der tatsächlichen Arbeit abzugleichen.

Worin unterscheidet es sich davon, einfach ein README zu pflegen

Ein README ist meist breit angelegt und an ein externes Publikum gerichtet. Dieses Skill schiebt stärker in Richtung operativer Entwicklungskontext: was das Produkt ist, warum der Stack so gewählt wurde, wie Arbeit durch das System läuft und was über Agenten-Sessions hinweg konsistent bleiben soll.

Wann sollte ich context-driven-development nicht verwenden

Nutze es nicht für winzige Wegwerfexperimente, einmalige Skripte oder Projekte, bei denen du die Artefakte nicht pflegen wirst. Der Wert entsteht durch laufende Wiederverwendung und Synchronisierung, nicht durch den ersten Entwurf allein.

So verbesserst du das context-driven-development-Skill

Gib dem Skill Belege statt Wunschbilder

Der größte Qualitätssprung entsteht, wenn du das Skill mit echten Repo-Belegen und realen Entscheidungen erdest. Hänge konkrete Dateien, Konfigurationen und Feature-Listen an oder verweise darauf. Wenn du nur Ziele und Ambitionen lieferst, lesen sich die Artefakte schnell wie generische Planungsdokumente statt wie belastbarer Arbeitskontext.

Bitte um bestätigte Fakten statt vermuteter Annahmen

Ein häufiger Fehler besteht darin, beobachtbare Repo-Fakten mit Vermutungen zu vermischen. Verbessere context-driven-development-Ergebnisse, indem du zwei Ebenen verlangst:

• aus Dateien oder Doku bestätigt
• aus Mustern oder fehlenden Informationen abgeleitet

Das beschleunigt die Prüfung deutlich und reduziert unbeabsichtigtes Drift.

Schärfe jedes Artefakt auf Entscheidungen zu

Nutzer interessiert vor allem, ob die Artefakte spätere Coding-Sessions tatsächlich besser machen. Das erreichst du, indem du jede Datei konsequent entscheidungsorientiert hältst:

• product.md: wer, welches Problem, welcher Scope, welche Erfolgsmetriken
• tech-stack.md: welche Tools gewählt wurden und warum
• workflow.md: wie Änderungen vorgeschlagen, umgesetzt, getestet und geprüft werden
• tracks.md: was aktiv, blockiert, als Nächstes geplant oder erledigt ist

Wenn ein Abschnitt keine zukünftige Coding-Entscheidung unterstützen kann, kürze ihn.

Konsistenz prüfen, bevor du der Ausgabe vertraust

Das Skill wird deutlich nützlicher, wenn du es gezielt nach Widersprüchen suchen lässt, zum Beispiel nach:

• einem Produktscope, der über die Roadmap hinausgeht
• Stack-Entscheidungen, die zu Deployment-Vorgaben im Konflikt stehen
• Workflow-Erwartungen, die von den Tools im Repo nicht getragen werden
• tracks, die nicht zu den aktuellen Prioritäten passen

Dieser Validierungsschritt ist eine der wertvollsten Gewohnheiten für context-driven-development for Context Engineering.

Prompts mit konkreten Repo-Leseanweisungen verbessern

Statt nur „analyze my repo“ zu sagen, solltest du präzisieren, wo die maßgebliche Wahrheit liegt. Zum Beispiel:

• „Use package.json, Dockerfile, .github/workflows/, and README.md as primary evidence.”
• „Treat issue labels and milestone names as workflow clues.”
• „Prefer explicit config over naming heuristics.”

So verringerst du halluzinierte Details zu Stack und Prozessen.

Nach dem ersten Entwurf iterieren, nicht davor

Ein gutes Muster ist draft -> review -> refine. Bitte zuerst um vollständige Artefakte und starte dann einen zweiten Durchlauf, etwa mit diesen Anforderungen:

• generische Fülltexte entfernen
• fehlende Einschränkungen ergänzen
• Annahmen in Fragen umwandeln
• tracks an die Roadmap angleichen
• Stack-Begründungen mit exakten Versionen ergänzen, sofern bekannt

Diese Iteration führt meist zu besseren Ergebnissen, als den ersten Prompt bis ins Letzte perfektionieren zu wollen.

Halte die Artefakte lebendig, wenn sich das Projekt verändert

Die Entscheidung für eine context-driven-development-Installation zahlt sich nur aus, wenn die Dokumente aktuell bleiben. Führe das Skill erneut aus oder prüfe die Artefakte neu, wenn sich Folgendes ändert:

• die Architektur
• die Prioritäten
• das Tooling
• Onboarding-Reibung im Team
• Agenten-Ausgaben, die von der tatsächlichen Projektrealität abzuweichen beginnen

Veralteter Kontext ist oft schlimmer als fehlender Kontext, weil er falsche Sicherheit erzeugt.