NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grünes Handbuch SKILL und Dokumentenstapel PRD mit Wegweiser dazwischen

Skill vs PRD: Die Definition

Ein Skill ist wiederverwendbares Prozesswissen für einen KI Agenten. Ein PRD ist ein Product Requirements Document und beschreibt die Anforderungen an ein konkretes Produkt. Der Skill sagt, wie gearbeitet wird. Das PRD sagt, was gebaut wird.
Der Unterschied klingt akademisch. Er ist es nicht. Wer Projektanforderungen in eine SKILL.md schreibt, bekommt einen Agenten, der im nächsten Repo losläuft und Features baut, die dort niemand bestellt hat. Wer umgekehrt Konventionen in jedes PRD kopiert, verbrennt Tokens und produziert Drift zwischen Dokumenten.
Beide Dokumente sind Kontext für denselben Agenten. Sie unterscheiden sich in Reichweite, Lebensdauer, Ladezeitpunkt und Ablageort. Diese vier Achsen entscheiden, was wohin gehört.

Inhalt

Skill und PRD mit NCA: Schnelle Hilfe vom Experten

Never Code Alone schreibt eigene Skills für den Produktivbetrieb. Das KI gestützte Content Marketing auf nevercodealone.de läuft selbst über Skills, die Block Strukturen, Konventionen und Qualitätsregeln dauerhaft im Agenten verankern. Wir kennen also aus eigener Erfahrung, wo die Grenze zwischen generischem Prozesswissen und projektspezifischer Anforderung verläuft. Unser Stack aus Sulu, Symfony, Astro und Cypress läuft täglich mit KI Agenten, dazu n8n und Paperclip für Workflows.
Passend dazu unterstützen wir Teams beim Vibe Coding Consulting, beim Aufbau belastbarer Best Practices für KI gestützte Entwicklung, beim Einstieg über das Vibe Coding Training, beim Aufsetzen von Qualitätsgates im PHP Consulting und bei der Auswahl passender KI Modelle für Entwickler. Wer den Aufbau einer SKILL.md im Detail sucht, findet ihn im Beitrag SKILL.md Aufbau und Trigger.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Die vier Achsen der Abgrenzung

Vier Fragen reichen, um jedes Stück Kontext sauber einzusortieren.
Reichweite. Gilt das in jedem Projekt oder nur in diesem? Ein Skill für Cypress Tests gilt überall, wo Cypress läuft. Die Anforderung, dass der Checkout drei Zahlarten unterstützt, gilt in genau einem Shop.
Lebensdauer. Überlebt das den nächsten Release? Ein Skill wächst über Jahre und wird geschärft. Ein PRD ist mit dem Release erledigt und wandert ins Archiv.
Ladezeitpunkt. Wer entscheidet, ob das in den Kontext kommt? Den Skill lädt der Agent selbst, sobald die Beschreibung im Frontmatter zur Aufgabe passt. Das PRD legst du bewusst dazu, wenn du an diesem Feature arbeitest.
Ablageort. Ein Skill liegt in einem eigenen Ordner mit SKILL.md, oft in einem Agent Plugin gebündelt und über mehrere Repos geteilt. Ein PRD liegt im Repo, meist unter docs, versioniert mit dem Code, den es beschreibt.
Der Ladezeitpunkt ist der eigentliche Knackpunkt. Skills laufen über Progressive Disclosure: Der Agent liest zuerst nur Name und Beschreibung, den vollen Inhalt erst bei Bedarf. Genau deshalb darf in einer SKILL.md nichts stehen, das nur in einem Projekt stimmt. Der Trigger unterscheidet nämlich nicht zwischen Repos.

Zwei Fehler, die Teams immer wieder machen

Fehler eins: Anforderungen wandern in die SKILL.md. Das Muster ist immer gleich. Ein Team schreibt einen Skill für das eigene Shop Projekt, packt Produktnamen, Datenbankschema und Feature Wünsche hinein und teilt den Skill dann im Team. Im nächsten Repo triggert er trotzdem, weil die Beschreibung im Frontmatter nicht projektspezifisch ist. Der Agent baut Dinge, die dort niemand wollte.
Die Gegenprobe ist einfach: Wenn ein Satz einen Produktnamen, eine Kundenanforderung oder ein Datum enthält, gehört er nicht in einen Skill.
Fehler zwei: Konventionen wandern ins PRD. Hier kopiert jemand die Coding Standards, die Teststrategie und den Commit Stil in jedes neue Anforderungsdokument. Das kostet Tokens bei jedem Lauf und erzeugt Drift. Nach drei PRDs stehen drei leicht unterschiedliche Versionen derselben Regel im Repo, und der Agent zieht sich die falsche.
Beides sind Symptome desselben Denkfehlers: Kontext wird als ein Topf behandelt statt als geordnete Kette. Wie sich PRD, ADR, Spec und BDD zueinander verhalten, steht ausführlich in der Dokumentenkette für KI Coding.

AGENTS.md als Zwischenform

Zwischen Skill und PRD gibt es eine dritte Ebene, die oft übersehen wird. AGENTS.md ist repo spezifisch wie ein PRD, aber dauerhaft wie ein Skill. Dort steht, wie dieses eine Projekt gebaut, getestet und deployed wird.
Die Zuordnung wird damit dreiteilig:
  • Skill – gilt überall, lebt dauerhaft, Agent lädt selbst
  • AGENTS.md – gilt in diesem Repo, lebt dauerhaft, Agent lädt beim Start
  • PRD – gilt für dieses Feature, lebt bis zum Release, du lädst bewusst
Wer diese drei Ebenen sauber trennt, spart bei jedem Lauf Kontext und bekommt reproduzierbare Ergebnisse. Wer sie mischt, debuggt am Ende nicht den Code, sondern die eigene Dokumentation.

Der Skill, der PRDs schreibt

Die sauberste Kombination beider Ebenen ist ein Skill, der PRDs erzeugt. Er enthält kein Projektwissen, sondern nur das Verfahren: welche Fragen gestellt werden, welche Struktur das Dokument bekommt, welche Abschnitte Pflicht sind.
Ein solcher Skill bleibt generisch und funktioniert in jedem Repo. Das Ergebnis ist projektspezifisch und landet im Repo. Genau so soll die Trennung aussehen.
Ein brauchbares PRD hat sechs Abschnitte:
  • Problem und Kontext
  • Zielgruppe
  • Scope und ausdrücklich Non Goals
  • User Stories mit Akzeptanzkriterien
  • Messbare Erfolgskriterien
  • Offene Fragen
Den größten Nutzen bringen die Non Goals und die Akzeptanzkriterien. Ohne Non Goals erfindet jeder Agent Features dazu. Ohne Akzeptanzkriterien gibt es keinen Punkt, an dem etwas fertig ist. Frameworks wie BMAD oder OpenSpec formalisieren genau diesen Schritt. Wir helfen Teams dabei, solche Ansätze gegen direktes Vibe Coding einzuordnen.

Skill und PRD im direkten Vergleich

Merkmal Skill PRD
Reichweite projektübergreifend ein Projekt
Lebensdauer dauerhaft, wächst über Jahre bis zum Release
Ladezeitpunkt Agent lädt per Trigger du legst bewusst dazu
Inhalt Verfahren und Konventionen Anforderungen und Scope
Ablageort Skill Ordner mit SKILL.md Repo, meist unter docs
Änderungsanlass neues Verfahren neue Anforderung

Wann Skill, wann PRD: der Praxistest

Im Alltag entscheidet ein Satz. Stell dir vor, du wechselst morgen in ein völlig anderes Projekt. Nimmst du diesen Text mit? Dann ist es ein Skill. Bleibt er zurück? Dann gehört er ins PRD oder in die AGENTS.md.
Ein paar Beispiele aus dem Produktivbetrieb:
  • Skill: Wie ein Cypress Test aufgebaut wird, welche Selektoren erlaubt sind, wie Fixtures organisiert werden
  • Skill: Welche Schritte ein Review durchläuft, bevor ein Merge erlaubt ist
  • AGENTS.md: Welche Befehle dieses Repo baut und testet, welche Ordner tabu sind
  • PRD: Dass der neue Filter drei Kriterien kombinieren muss und Sortierung nach Datum unterstützt
Wichtig bleibt die Reihenfolge: Erst stehen die Qualitätsgates, dann kommt die Dokumentation. Statische Analyse, Unit Tests, funktionale Tests und ein kontrollierter Agent Loop fangen ab, was ein PRD nie abfängt. Ein Anforderungsdokument ersetzt keine Tests. Es beschreibt nur, was getestet werden soll.

Skills teach Claude how to complete specific tasks in a repeatable way.

anthropics/skills, Offizielles Agent Skills Repository – README auf GitHub

Skill und PRD in der Praxis bei Never Code Alone

Wir arbeiten täglich mit OpenCode und Open Weight Modellen, lokal über Ollama und für große Coding Modelle aus der Cloud. Die Trennung zwischen Skill und PRD ist für uns keine Theorie, sondern der Grund, warum unsere Agenten über viele Projekte hinweg gleich arbeiten. Prozesswissen liegt im Skill, Projektwissen liegt im Repo.
Vor der Dokumentation stehen bei uns immer die Qualitätsgates. Statische Analyse mit PHPStan und Psalm, Unit Tests mit PHPUnit, End to End Tests mit Cypress. Erst wenn diese Gates laufen, bringt strukturierte Anforderungsdokumentation echten Nutzen. Umgekehrt lässt sich kein PRD gegen fehlende Tests durchsetzen.
Verwandte Themen im NCA Glossar: Agent Skills und das Vercel Ökosystem, Agent Plugins als offener Paketstandard, Everything Claude Code Skills, Claude Code Plugin Marketplace, Vise Coding mit Guardrails und SwarmForge mit TDD.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu Skill und PRD

Die wichtigsten Fragen aus der Praxis, kurz beantwortet.

Was ist der Unterschied zwischen Skill und PRD 2026?

Ein Skill enthält wiederverwendbares Prozesswissen und gilt projektübergreifend. Ein PRD beschreibt die Anforderungen an ein konkretes Produkt und gilt nur dort. Der Skill sagt, wie gearbeitet wird, das PRD sagt, was gebaut wird. Beide sind Kontext für denselben Agenten, unterscheiden sich aber in Reichweite, Lebensdauer, Ladezeitpunkt und Ablageort.

Gehören Projektanforderungen in die SKILL.md 2026?

Nein. Die Beschreibung im Frontmatter entscheidet, wann ein Skill triggert, und sie unterscheidet nicht zwischen Repositories. Steht Projektwissen im Skill, baut der Agent im nächsten Projekt Dinge, die dort niemand bestellt hat. Eine einfache Gegenprobe: Enthält ein Satz einen Produktnamen, eine Kundenanforderung oder ein Datum, gehört er nicht in den Skill.

Braucht jedes Projekt ein PRD 2026?

Nein. Für kleine Bugfixes und klar umrissene Änderungen reicht eine gute Issue Beschreibung. Ein PRD lohnt sich, sobald mehrere Personen beteiligt sind, der Scope unklar ist oder ein Agent über mehrere Schritte hinweg arbeiten soll. Die Faustregel: Wenn du die Frage nach dem Scope zweimal beantworten musst, schreib es auf.

Wie lang sollte ein PRD 2026 sein?

So kurz wie möglich. Zwei bis drei Seiten reichen für die meisten Features. Wichtiger als Länge ist Vollständigkeit an den kritischen Stellen: Non Goals, Akzeptanzkriterien und offene Fragen. Lange PRDs werden nicht gelesen, weder von Menschen noch effektiv von Agenten, weil sie den Kontext unnötig aufblähen.

Ersetzt ein PRD die Tests 2026?

Nein. Ein PRD beschreibt, was getestet werden soll, aber es prüft nichts. Ohne statische Analyse, Unit Tests und End to End Tests bleibt jede Anforderungsdokumentation eine Absichtserklärung. Bei uns stehen die Qualitätsgates zuerst, danach kommt die strukturierte Dokumentation. Umgekehrt funktioniert es nicht.

Was gehört in die AGENTS.md?

Alles, was in genau diesem Repository dauerhaft gilt. Also Build und Test Befehle, Ordnerstruktur, verbotene Bereiche und projektspezifische Konventionen. Damit ist die AGENTS.md die Zwischenform: repo spezifisch wie ein PRD, aber dauerhaft wie ein Skill. Sie wird beim Start geladen, nicht per Trigger.

Kann ein Skill ein PRD erzeugen?

Ja, und das ist die sauberste Kombination beider Ebenen. Ein Skill für PRDs enthält nur das Verfahren: welche Fragen gestellt werden, welche Struktur das Dokument bekommt, welche Abschnitte Pflicht sind. Der Skill bleibt generisch und funktioniert überall. Das erzeugte PRD ist projektspezifisch und landet im Repo.

Wie verhindere ich, dass ein Skill im falschen Repo triggert?

Über die Beschreibung im Frontmatter. Sie muss das Verfahren benennen, nicht das Projekt. Formulierungen wie für unser Shop System sind ein Warnsignal. Wer wirklich projektgebundene Trigger braucht, gehört mit dem Inhalt in die AGENTS.md des jeweiligen Repositories statt in einen geteilten Skill.

Wo liegt ein PRD im Repository?

Üblich ist ein docs Ordner, versioniert mit dem Code, den das Dokument beschreibt. Der Vorteil: Das PRD durchläuft dieselben Reviews wie der Code und veraltet nicht unbemerkt in einem separaten Wiki. Nach dem Release wandert es ins Archiv, bleibt aber über die Git Historie nachvollziehbar.

Was sind Non Goals und warum sind sie wichtig?

Non Goals benennen ausdrücklich, was nicht gebaut wird. Sie sind der wirksamste Teil eines PRDs, weil KI Agenten ohne diese Grenze zuverlässig Features dazu erfinden. Ein Satz wie Mehrsprachigkeit ist in dieser Iteration ausgeschlossen spart mehr Aufwand als drei Seiten positiver Beschreibung.

Wie unterscheidet sich ein PRD von einer Spec?

Ein PRD beschreibt das Problem und die gewünschte Wirkung aus Produktsicht. Eine Spec beschreibt die technische Umsetzung. Beide greifen ineinander, aber sie beantworten verschiedene Fragen. Wie sich PRD, ADR, Spec und BDD zueinander verhalten, steht ausführlich in unserem Beitrag zur Dokumentenkette für KI Coding.

Lohnt sich die Trennung auch für Einzelentwickler?

Ja, sogar besonders. Wer allein arbeitet, wechselt trotzdem zwischen Projekten. Ein sauber geschriebener Skill nimmt das Prozesswissen mit, ohne Ballast aus dem alten Projekt einzuschleppen. Der Aufwand für die Trennung fällt einmal an, der Nutzen wiederholt sich bei jedem neuen Repository.