tomtdhzz/requirement-orchestrator

Requirement Orchestrator

Verwandle eine Softwareanfrage in unabhängig überprüfbare Arbeit, während ein einziger steuernder Agent für Umfang, Abhängigkeiten, Nachweise und Integration verantwortlich bleibt. Diese Fertigkeit ist ein Orchestrierer, kein Prompt-Generator.

Wähle einen semantischen Modus

• analyze: Untersuche die Anfrage und die Codebasis, pflege das Aufgabenbuch und erstelle einen Ausführungsplan, ohne Code zu ändern. Dies ist der Standard, wenn keine Implementierung angefordert wurde.
• diagnose: Reproduziere und erkläre einen gemeldeten Fehler, trenne bestätigte Grundursache, Nachweise, Unbekanntes und empfohlene Reparaturpfade. Die Diagnose ist das Ergebnis; ändere keinen Code.
• execute: Verteile abgegrenzte Arbeit, überprüfe zurückgegebene Ergebnisse und schließe die Integration ab. Betritt diesen Modus nur, wenn der Benutzer die Implementierung oder Ausführung autorisiert hat.
• challenge: Teste eine bestehende Anforderung, Zerlegung oder Entwurf auf Auslassungen und Risiken, ohne das bestätigte Produktziel zu ändern. Siehe references/challenge.md.

Dies sind semantische Modi auf Fertigkeitsebene. Sie rufen keinen nativen Plan-Modus einer Plattform, EnterPlanMode oder obligatorische Explore/Plan-Agenten auf oder erfordern diese. Verwende native Modi nur, wenn sie unabhängig nützlich und mit den Einschränkungen des Benutzers kompatibel sind.

Für eine Aufgabe mit einer einzigen Grundursache und ohne Delegierung verwende direkt die Kontrollschleife. Lese references/spec-driven.md, um die Spezifikation zu gestalten (Anforderungen, Abnahmeszenarien, Verträge). Lese references/context-grounding.md, bevor du in einer bestehenden Codebasis zerlegst. Lese references/decomposition.md, wenn es mehr als eine Kandidatenaufgabe, eine Dienst-/Domänengrenze, eine Terminierungsentscheidung oder einen Build-/Bereitstellungsfehler gibt, bei dem der Repository-Zustand ursächlich sein könnte. Lese references/verification.md für Standards zu Abnahmenachweisen. Lese references/ledger.md, wenn die Arbeit mehrere Aufgaben, Agenten, Sitzungen oder Plattformen umfasst. Lese references/mutation.md, wenn die Ausführung bestehende Artefakte neu schreibt, löscht oder über mehr als eines hinweg verzweigt oder in ein externes System schreibt. Durchgeführte Durchläufe: references/examples/feature-example.md und references/examples/bug-example.md.

Führe im diagnose-Modus den beobachteten oder reproduzierten Fehler, die bestätigte Grundursache und Nachweise, nicht verifizierte Punkte, Auswirkungen und empfohlene Reparaturpfade auf. Höre dort auf, es sei denn, der Benutzer autorisiert separat execute.

Kontrollschleife

1. Lege das Ziel, den Umfang, die Abnahmekriterien, die Randbedingungen und die verifizierten Code-Fakten fest. Stelle zuerst Unbekanntes auf sicheren Grund (references/context-grounding.md), drücke das Ergebnis dann als Spezifikation aus – Anforderungen, Abnahmeszenarien und Verträge (references/spec-driven.md). Untersuche ermittelbare Fakten; frage den Benutzer nur nach Entscheidungen, die Umfang, Abnahme oder Richtung wesentlich beeinflussen. Konsultiere vor der Zerlegung die Wissensdatenbank der Fähigkeiten (siehe references/knowledge-base.md), um die vorhandenen Fertigkeiten abzurufen, die für das Ziel und einen gleichartigen Domänenvergleich relevant sind; bevorzuge die Wiederverwendung oder Übernahme einer bekannten Fähigkeit gegenüber der Recherche von Grund auf und halte die gewählten Fähigkeiten im Aufgabenbuch fest.
   • Lese frühere Projekterfahrungen, falls vorhanden (references/experience.md), und behandle sie als Kandidaten zur Überprüfung, nicht als Evangelium.
   • Erstelle für einen nicht-trivialen Build nach der Spezifikation einen technischen Entwurf (references/tech-design.md) – Architektur, detailliertes Design, Alternativen, Querschnittsaspekte – und lege die Artefakte gemäß dem docs/-Layout ab (references/deliverables.md).
2. Versuche bei einem gemeldeten Fehler oder Ausfall eine proportionale lokale Reproduktion, bevor du eine Grundursache behauptest. Vergleiche den beobachteten Fehler mit dem Bericht. Solange nicht reproduziert oder durch gleichwertige direkte Nachweise gestützt, kennzeichne Aussagen zur Grundursache als Hypothesen und gib an, was noch nicht verifiziert ist.
3. Wähle eine primäre Zerlegungsachse und erstelle abgegrenzte Aufgaben. Leite die gemeinsamen Verträge ab und friere sie ein, bevor abhängige oder parallele Arbeiten beginnen (references/spec-driven.md). Halte Abhängigkeiten und aufgabenübergreifende Verträge explizit fest. Spiegele die resultierenden Aufgabengruppen in einen phasierten TODO (siehe Fortschrittsoberfläche).
4. Behalte genau einen steuernden Agenten. Der Controller besitzt das Aufgabenbuch, die Entscheidungen über die Verteilung, den Überprüfungsstatus, die Neuplanung und die endgültige Integration.
5. Verteile nur Aufgaben mit einem vollständigen Vertrag. Lese references/agent-contract.md vor der ersten Verteilung. Führe vor der Verteilung von Schreibvorgängen in ein System außerhalb des lokalen Arbeitsverzeichnisses den untenstehenden Zielsystem-Vorabcheck durch.
6. Nimm ein Worker-Ergebnis in die review-Phase auf, überprüfe seine Nachweise und Grenzen anhand der Standards für Abnahmenachweise (references/verification.md), markiere es dann als completed oder gib es mit spezifischen Feststellungen zurück. Überprüfe bei einer Massen- oder externen Mutation durch unabhängiges Rücklesen und ein strukturelles Delta, nicht anhand des gemeldeten Erfolgszählers des Tools.
7. Berechne betroffene Abhängigkeiten nach Entdeckungen, Fehlern oder Umfangsänderungen neu. Überarbeite den kleinsten betroffenen Zweig.
8. Erkläre die Anfrage erst dann als abgeschlossen, wenn aufgabenbezogene Prüfungen, aufgabenübergreifende Verträge und jedes Abnahmeszenario gemeinsam bestanden sind; das End-to-End-Gate ist in references/verification.md definiert. Hänge bei Abschluss alle qualifizierenden projektspezifischen Erfahrungen an das Erfahrungsprotokoll an (references/experience.md). Die Verbesserung der Fertigkeit selbst aus dem Durchlauf ist eine separate Opt-in-Aktion – nur angeboten, wenn eine Erfahrung allgemein und wiederkehrend ist, nur angewendet, wenn der Benutzer sie wählt, niemals automatisch (siehe references/experience.md).

Fortschrittsoberfläche

Halte einen sichtbaren phasierten TODO synchron mit dem Aufgabenbuch, damit der Benutzer Phasen und Fortschritte auf Schritt-Ebene sieht, nicht nur Prosa. Das Aufgabenbuch bleibt die detaillierte Quelle der Wahrheit (Abhängigkeiten, Umfänge, Verträge, Nachweise); der phasierte TODO ist seine Fortschrittsansicht.

• Initialisiere eine Phase pro Zerlegungsgruppe, dann eine abschließende Abnahmephase (für einen Fehlerfluss: 对照 / 修复 / 验证; für einen Feature-Fluss: die Feature-Gruppen, gefolgt von 全量验收). Jedes Element ist eine abgegrenzte Aufgabe oder ein Überprüfungsschritt, formuliert als Ergebnis in 5–10 Wörtern.
• Treibe es mit der nativen Aufgabenliste der Plattform, niemals mit einem handformatierten Baum. Verwende bei Claude/omp das todo-Tool: init mit list: [{phase, items}], dann start/done pro Element. Verwende bei Codex dessen Plan/update-plan-Mechanismus.
• Aktualisiere den Status aus echtem Fortschritt: Markiere ein Element als in Bearbeitung, wenn seine Aufgabe verteilt ist, und als erledigt, erst nachdem der Controller completed im Aufgabenbuch vermerkt hat. Phasenzahlen (N/M) verfolgen dann die verifizierte Abnahme, nicht die Verteilung.
• Halte die beiden konsistent: Ein TODO-Element entspricht genau einer Aufgabenbuch-Aufgabe oder einem Überprüfungsschritt. Berechne beide gemeinsam während der Neuplanung neu.
• In den Modi analyze und diagnose sind die Phasen Untersuchungs- oder Diagnoseschritte, und deren Abschluss ändert keinen Code.

Auslieferbare Artefakte

Trenne veröffentlichbare Dokumente vom internen Orchestrierungszustand: Leserorientierte Dokumente kommen unter docs/ (docs/prd/ Spezifikation, docs/tech-design/ Entwurf); das Aufgabenbuch, der Plan und die Erfahrungen sind interner Arbeitszustand unter .ai-work/ – niemals unter docs/ und für ein veröffentlichbares Projekt gitignoriert. Siehe references/deliverables.md.

Erstelle für jeden nicht-trivialen Build nach der Spezifikation und vor dem execute-Modus einen technischen Entwurf: Architektur, detailliertes Design, betrachtete Alternativen und Querschnittsaspekte (references/tech-design.md). Überspringe diesen Schritt für eine Reparatur mit einer einzigen Grundursache, bei der die Spezifikation plus eine Aufgabenliste ausreicht.

Überprüfe jedes generierte Markdown-Auslieferbare vor der Übergabe selbst: Lies es erneut und bestätige, dass es so dargestellt wird, wie der Leser es sehen wird – Struktur intakt, eingefasste/Mermaid-Blöcke tatsächlich parsbar (stelle sie dar, schätze nicht), Links auflösbar. Ein Parse-/Darstellungsfehler ist ein jetzt zu behebender Mangel. Siehe references/deliverables.md und die Zeile Dokument / Diagrammartefakt in references/verification.md.

Wenn das Auslieferbare ein eigenständiges Projekt ist, umfasst „erledigt