TheStreamCode/agentic-rd-skill

Agentic R&D Workflow (Forschung & Entwicklung mit Agenten)

Verwenden Sie dieses in sich geschlossene Skill-Paket, um einen Markdown-basierten, Multi-Agenten-Labor-Workflow im aktuellen Arbeitsbereich zu automatisieren.

Dies ist eine allgemeine Adaption des Agent-Laboratory-Musters: unabhängige Evidenzprüfung, kollaborative Planerstellung, Aufgabenausführung oder Untersuchung, Ergebnisanalyse, Qualitätskontrolle und abschließende Berichterstellung. Es ist nicht auf wissenschaftliche Forschung beschränkt; wenden Sie denselben Labor-Workflow auf Produkt-, Business-, Technik-, Strategie-, Rechts-, Compliance-, Sicherheits-, UX-, Markt- und operative Anwendungsfälle an.

Entwickelt für Skill-kompatible Codierungsagenten mit Dateisystemzugriff. Bevorzugen Sie echte parallele Subagenten, wann immer die Umgebung diese unterstützt; verwenden Sie isolierte simulierte Durchläufe nur, wenn keine echten Subagenten verfügbar sind.

Paketinhalt

• SKILL.md: Aktivierungsregeln und Kernbetriebsanweisungen.
• references/generalized-lab-model.md: Universelles Agent-Labor-Modell und Anwendungsfall-Zuordnung.
• references/workflow.md: Vollständige Phasenabfolge und Genehmigungsschleuse.
• references/agent-roles.md: Anleitung zur Auswahl von Spezialistenrollen.
• references/quality-rules.md: Standards für Evidenz, Unsicherheit, Prüfung und Sicherheit.
• references/implementation-notes.md: Hinweise zu Installation, Gerüst, Subagenten und Dateiverwaltung.
• references/example-run.md: Ein kompaktes End-to-End-Beispiel, das die erwartete Dateispur und Ausgabequalität zeigt.
• assets/templates/: Markdown-Vorlagen für alle Workflow-Dateien.
• scripts/init-rd-workflow.mjs: Optionales Gerüst-Skript.
• scripts/validate-skill.mjs: Repository-Validierung für das öffentliche Skill-Paket.

Erste Aktion

1. Suchen Sie im aktuellen Arbeitsbereich nach project-brief.md.
2. Wenn es existiert, lesen Sie es vollständig, bevor Sie einen anderen Workflow-Schritt ausführen.
3. Wenn es nicht existiert und der Benutzer genügend Kontext gegeben hat, erstellen Sie es mit assets/templates/project-brief.md.
4. Wenn wesentlicher Kontext fehlt, stellen Sie nur die minimalen blockierenden Fragen.
5. Nachdem die Projektbeschreibung existiert, fahren Sie fort, ohne zwischen normalen Workflow-Phasen um Erlaubnis zu fragen.

Führen Sie scripts/init-rd-workflow.mjs aus, um project-brief.md und die erforderlichen work/-Dateien zu erstellen. Das Skript darf work/06-final-output.md nicht erstellen.

Erforderliche Ausgaben

Erstellen und verwenden Sie diese Struktur im aktiven Arbeitsbereich:

work/
├── 00-lab-notes.md
├── 01-orchestration-plan.md
├── 02-specialist-outputs/
├── 03-team-collaboration.md
├── 04-cross-review-notes.md
├── 05-stage-gate-review.md
└── 06-final-output.md

Jede Workflow-Phase ist einem bestimmten Ausgabepfad zugeordnet. Die nummerierten Laborphasen (Evidenzprüfung, Planerstellung, Ausführung, Ergebnisanalyse) sind keine separaten Dateien: Sie werden als eine Datei pro Spezialist in work/02-specialist-outputs/ materialisiert.

Phase	Ausgabepfad
Lab-Einrichtung	work/00-lab-notes.md
Orchestrierung	work/01-orchestration-plan.md
Evidenzprüfung, Plan, Ausführung, Ergebnisse (eine Datei pro Spezialist)	work/02-specialist-outputs/NN-<rolle>.md
Team-Zusammenarbeit (vom Orchestrator konsolidiert)	work/03-team-collaboration.md
Kreuzprüfung	work/04-cross-review-notes.md
Phasen-Gate-Prüfung	work/05-stage-gate-review.md
Abschließende Synthese	work/06-final-output.md

Erstellen oder schreiben Sie work/06-final-output.md erst, wenn work/05-stage-gate-review.md „Approved“ (Genehmigt) sagt.

Workflow

1. Lesen Sie references/workflow.md für die kanonische Phasenabfolge.
2. Lesen Sie references/generalized-lab-model.md, um den Anwendungsfall des Benutzers auf die Laborphasen abzubilden.
3. Lesen Sie references/agent-roles.md, bevor Sie Spezialisten auswählen.
4. Lesen Sie references/quality-rules.md vor der Kreuzprüfung, der Phasen-Gate-Prüfung und der abschließenden Synthese.
5. Verwenden Sie references/implementation-notes.md für die Skriptnutzung, das Subagentenverhalten und Dateiverwaltungsdetails.
6. Verwenden Sie Vorlagen aus assets/templates/ für generierte Workflow-Dateien.
7. Konsultieren Sie references/example-run.md für ein durchgearbeitetes End-to-End-Beispiel, wenn Sie sich über die erwartete Ausgabequalität unsicher sind.

Skalieren Sie auf die Projektbeschreibung

Passen Sie den Workflow-Umfang an die Projektbeschreibung an. Führen Sie kein vollständiges Multi-Wellen-Labor für eine kleine Frage durch.

• Triviale Projektbeschreibung: Der Orchestrator kann einen einzelnen Inline-Durchlauf ohne Subagenten durchführen. Dokumentieren Sie Evidenz, Annahmen und Risiken in work/00-lab-notes.md, schreiben Sie eine kurze Selbstprüfung in work/05-stage-gate-review.md und dann work/06-final-output.md. Die zwischengeschalteten Spezialisten-, Kollaborations- und Kreuzprüfungsdateien sind auf dieser Stufe optional. Die Phasen-Gate-Regel gilt weiterhin: Schreiben Sie 06-final-output.md erst, wenn 05-stage-gate-review.md „Approved“ (Genehmigt) sagt.
• Kleine oder enge Projektbeschreibung: Verwenden Sie ein oder zwei Spezialisten, führen Sie eine einzelne Welle durch und integrieren Sie die Zusammenarbeit in die Notizen des Orchestrators anstelle eines separaten Austauschs. Halten Sie Kreuzprüfung, Phasen-Gate-Prüfung und abschließende Synthese als einen einzelnen schnellen Durchlauf pro Schritt.
• Mittlere Projektbeschreibung: Verwenden Sie einige Spezialisten über ein bis zwei Wellen mit einem leichten Team-Kollaborationsschritt.
• Große oder regulierte Projektbeschreibung: Verwenden Sie die vollständige Phasenabfolge, mehrere Wellen, explizite Team-Zusammenarbeit und die relevanten Prüfrollen.

Behalten Sie unabhängig von der Größe immer das obligatorische Minimum bei: Evidenz-/Kontextprüfung, Planerstellung, Ausführung oder Untersuchung, Ergebnisanalyse, Risiko-/Annahmenabdeckung und die Phasen-Gate-Qualitätsschleuse vor der abschließenden Synthese. Alles andere ist optional und wird nur hinzugefügt, wenn es das Ergebnis wesentlich verändert. Siehe references/generalized-lab-model.md für die Skalierungsdetails.

Ausführungsregeln

• Wählen Sie die wenigsten Spezialistenrollen aus, die die Projektbeschreibung gut abdecken.
• Beziehen Sie immer Evidenz-/Kontextprüfung, Planerstellung, Ausführung oder Untersuchung, Ergebnisanalyse sowie Risiko-/Annahmenabdeckung ein.
• Bevorzugen Sie echte parallele Subagenten. Sie sind das primäre Ausführungsmodell für diese Fertigkeit, keine optionale Verbesserung.
• Starten Sie in jeder Phase alle unabhängigen Spezialisten, bevor Sie auf Ergebnisse warten. Führen Sie unabhängige Spezialisten nicht nacheinander aus, wenn parallele Subagenten verfügbar sind.
• Simulieren Sie anderenfalls Spezialisten als isolierte Durchläufe. Jeder Durchlauf muss nur die Projektbeschreibung, den Orchestrierungsplan und seinen zugewiesenen Umfang lesen, bevor er seine eigene Datei schreibt.
• Kollabieren Sie niemals die Spezialistenanalyse, Kreuzprüfung, Phasen-Gate-Prüfung und abschließende Synthese in eine einzige Antwort.
• Parallelisieren Sie die Arbeit unabhängiger Spezialisten, halten Sie jedoch die Abhängigkeitsschleusen sequenziell: Prüfung vor Plan, Plan vor Ausführung, Ausführung vor Ergebnisanalyse, Prüfung vor Abschlussbericht.
• Fordern Sie Zitate oder Quellenangaben für Tatsachenbehauptungen an, wenn Quellen verfügbar sind.
• Kennzeichnen Sie nicht belegte Behauptungen als Annahmen oder Schlussfolgerungen.
• Bewahren Sie Unsicherheit und die Grenzen regulierter Prüfungen.

Kollaboratives Team-Protokoll

• Behandeln Sie Subagenten als ein kollaborierendes Team, nicht als unverbundene Berichtsschreiber.
• Der Master-Orchestrator definiert Teamrollen, Zuständigkeiten, Abhängigkeiten und Kollaborationsregeln in work/01-orchestration-plan.md.
• Jeder Subagent schreibt nur seine eigene Spezialistenergebnisdatei und gibt seine Fragen, Abhängigkeiten, Meinungsverschiedenheiten und Übergabenotizen an den Orchestrator zurück (in seinem Ergebnis, nicht durch Bearbeiten einer gemeinsamen Datei).
• Der Orchestrator konsolidiert diese zurückgegebenen Notizen in work/03-team-collaboration.md. Lassen Sie niemals mehrere Subagenten gleichzeitig dieselbe Datei schreiben.
• Das Team muss gemeinsame Annahmen vor der Kreuzprüfung abgleichen.
• Die Kreuzprüfung bewertet sowohl die Spezialistenergebnisse als auch das Team-Kollaborationsprotokoll.
• Die abschließende Synthese muss geklärte Übereinstimmungen, ungeklärte Meinungsverschiedenheiten und wichtige Minderheitsmeinungen widerspiegeln.

Abbruchbedingungen

Halten Sie an und fragen Sie den Benutzer nur, wenn:

• Der Gegenstand oder das Ziel nicht identifizierbar ist.
• Die gewünschte Ausgabe nicht abgeleitet werden kann.
• Wichtige Einschränkungen in Konflikt stehen.
• Erforderliche externe Daten, Anmeldeinformationen, private Systeme, kostenpflichtige Tools oder nicht verfügbarer Netzwerkzugriff die Arbeit blockieren.
• Rechts-, Medizin-, Finanz-, Compliance-, Sicherheits- oder sicherheitskritische Beratung nicht innerhalb einer sicheren informativen Grenze gehalten werden kann.

Abschluss

Wenn der Workflow abgeschlossen ist, teilen Sie dem Benutzer mit, welche Dateien erstellt wurden und ob die Phasen-Gate-Prüfung die abschließende Synthese genehmigt hat. Halten Sie die Abschlussnachricht kurz.