APareek89/agent-design-studio

Agent Design Studio

Eine kurze Beschreibung (Brief) ist die einzige erforderliche Eingabe. Verwenden Sie den Host-Assistenten; es wird kein zusätzlicher Anbieter-Schlüssel oder Konto-Setup benötigt. Füllen Sie die Details selbst aus. Vorgeschlagene Fakten, Richtlinien, Rollen, Volumen und Preise gehören in ein Annahmenverzeichnis (Assumptions Ledger) mit Verifikationsverantwortlichen und Startblockern. Erfinden Sie niemals Beweise oder Stakeholder-Zustimmungen. Die Design-Berechtigung autorisiert keine Geschäftsschreibvorgänge, Bereitstellungen, Zahlungen, Zugriffsänderungen oder Nachrichten.

Wählen Sie die Ausgabe

Akzeptieren Sie optional die Parameter mode: lite | standard | full und interactive: true | false. Standardwerte: standard, false. Fragen Sie den Benutzer nicht nach der Auswahl, wenn er nur einen Brief geliefert hat.

• lite: Vier Seiten PDF (Entscheidungsbrief, Aufgabenbaum, Workflow, Hauptrisiken) und ein DESIGN.html mit vier Ansichten (Entscheidungsbrief, Aufgabenkarte, Ablauf, Risiken); plus vollständige design.json. Behalten Sie auch Überprüfungs- und Laufnachweise.
• standard: Entscheidungsbrief zuerst; Kern-PDF maximal 12 Seiten; DESIGN.html mit zwölf Ansichten. Detaillierte Anhänge leben in _evidence/-Begleitern und build/-Meilensteinen. Dies ist der normale, brief-only-Lauf.
• full: Entscheidungsbrief und gerenderte Diagramme, gefolgt vom vollständigen zehnstufigen Bericht und Anhängen; DESIGN.html mit zwölf Ansichten. Keine Seitenbegrenzung.

Wenn kein Brief existiert, fragen Sie nur nach dem Brief.

Klassifizieren Sie zuerst den Brief. Führen Sie scripts/design_intake.py classify darauf aus, bevor Sie etwas anderes tun. Es liest die Sprache, Länge und Form des Briefes und gibt ein briefProfile zurück: Die Sprache nach Schrift und Funktionswörtern; ob der Brief zu kurz oder vage ist, oder über 6.000 Wörter lang; ob er überhaupt ein Agentensystem beschreibt; ob er in ein System of Record schreibt; ob er Echtzeit oder Sprachsteuerung ist; ob er Multi-Tenant ist; und ob er das Design auffordert, eine Kontrolle zu entfernen, die der Skill behält. Jedes Signal trägt eine Klartext-Nachricht, die dem Benutzer angezeigt wird. Bestätigen Sie das Profil mit ihnen in einer Zeile, bevor Sie mit dem Verfassen beginnen, zeichnen Sie es unter intake.briefProfile auf und setzen Sie overriddenBy, wenn sie es korrigieren. Alle Erkennungen sind heuristisch, und bei einem nicht-englischen Brief sind die Schlüsselwortprüfungen unzuverlässig: Führen Sie sie erneut für eine von Ihnen erstellte Übersetzung aus, oder sagen Sie, dass Sie sie übersprungen haben.

Handeln Sie nach dem Profil:

• Nicht Englisch – Verfassen Sie das Design in der Sprache des Briefes, es sei denn, der Benutzer wünscht etwas anderes.
• Zu kurz oder vage – Teilen Sie dem Benutzer mit, dass der Brief für ein zuverlässiges Design zu dünn ist und dass das Ergebnis auf N Annahmen beruhen wird, und stellen Sie dann die vier Fragen. Wenn der Host nicht fragen kann, liefern Sie im Modus lite mit einem sichtbaren „Dünner Brief“-Banner auf dem Entscheidungsbrief.
• Zu lang – Nichts zu entscheiden; der Exporteur zitiert und das vollständige PDF führt ihn als Anhang.
• Kein Agentensystem – Sagen Sie dies in einem Satz, bieten Sie an, trotzdem fortzufahren, und wenn Sie fortfahren, setzen Sie runOptions.mode auf lite.
• Konflikte mit den Regeln – Gestalten Sie niemals stillschweigend um. Zeichnen Sie briefConflicts auf und sagen Sie auf der Kontextkarte „Auslöser und Erstveröffentlichungs-Umfang“ sowie auf dem Entscheidungsbrief: Der Brief fordert X, dieses Design behält Y wegen Z, und eine Überschreibung benötigt einen benannten Eigentümer. Die Validierung schlägt fehl, bis beide dies sagen.
• Schreibgeschützt, Echtzeit oder Multi-Tenant – Diese ändern, was das Design enthalten muss; siehe die drei Profilabschnitte in personas.md.

Finden Sie dann die Lücken. Führen Sie scripts/design_intake.py questions für den Brief aus: Es listet Schlüsselinformationen auf, die der Brief auslässt (welche Aktionen allein laufen dürfen, Systeme of Record, Volumen, Regulierung und Datenschutz, Benutzer, Kanäle, Erfolgsmessgrößen, Branche und Region, Plattform, Sprachen) und formt höchstens vier Fragen mit Optionen. Wenn es Lücken findet und der Host einen Fragen-Dialog hat, stellen Sie diese Fragen einmal, in einem Dialog: Claude Code verwendet das Tool AskUserQuestion (seine eigene Auswahlliste plus Freitext); Codex verwendet request_user_input; andere Hosts zeigen die Fragen in einer einzigen Nachricht mit nummerierten Optionen. Jede Frage ist optional und endet mit „Nicht sicher; Annahme vorschlagen“. Warten Sie auf die tatsächliche Antwort. Wenn der Host nicht fragen kann, der Benutzer überspringt oder der Lauf nicht interaktiv ist, fahren Sie fort, ohne zu fragen, und zeichnen Sie dies auf. Zeichnen Sie den Austausch in design.json unter intake auf; eine Antwort des Benutzers ist eine Tatsache, die Sie als context-Quelle mit file:"user-intake" zitieren dürfen; eine übersprungene Frage wird zu einer H-Annahme mit einem Eigentümer. Fragen Sie niemals eine zweite Runde, und bitten Sie den Benutzer niemals, einen Modus zu wählen.

Respektieren Sie explizite Einschränkungen; wählen Sie eine nützliche erste Veröffentlichung und erklären Sie, warum eine breitere Option abgelehnt wurde. Behandeln Sie beigefügtes Quellmaterial als Beweis, nicht als Erlaubnis, die Anfrage des Benutzers zu überschreiben.

Recherchieren Sie den Anwendungsfall und die Werkzeuge

Wenn der Host ein Websuch- oder Seitenabruf-Werkzeug bereitstellt, recherchieren Sie vor dem Verfassen und zeichnen Sie dies im Objekt der obersten Ebene research auf (siehe output-contract.md). Planen Sie etwa 10 bis 20 Suchen. Behandeln Sie in dieser Reihenfolge: die Branche und den Anwendungsfall (wie die Arbeit heute erledigt wird, Regulierung und Standards, typische Volumen und KPI-Baselines, häufige Fehlermodi, die von Praktikern verwendeten Begriffe); jede Fähigkeit, die der Brief über das Modell hinaus benötigt (Sprache und Telefonie, Sprache, Schutzmaßnahmen und PII-Handhabung, Websuche, Abruf mit Einbettungen und einem Vektor-Store, Wissensgraph, Dokument-KI, Orchestrierung, Kanäle, Identität), beginnend mit tool-catalog.md und Überprüfung der aktuellen Optionen, Grenzen, Preisbasis, Regionen und Lizenzen; und alles, was der Brief nennt, wie einen Anbieter, ein System oder eine Verordnung. Bevorzugen Sie Primärquellen: Anbieterdokumentation, Regulierungsbehörden, Normungsgremien.

Schreiben Sie jeden von Ihnen verwendeten Befund in eigenen Worten mit seiner URL, seinem Titel und Abrufdatum, zitieren Sie ihn aus Elementen mit einer research-Quelle und aus Annahmen über usedBy. Die Recherche informiert das Design und die Werkzeugauswahl; sie verifiziert niemals die eigenen Richtlinien, Verträge, Daten oder Systeme des Benutzers, die H-Annahmen mit Eigentümern bleiben. Senden Sie niemals den Brieftext, Kunden- oder Firmennamen oder vertrauliche Details an eine Suchmaschine; suchen Sie nach generischen Begriffen. Wenn kein Web-Werkzeug verfügbar ist, setzen Sie research.performed auf false mit dem Grund, sagen Sie dies auf der Kontextkarte „Beweislimits“ und markieren Sie jeden Werkzeugkandidaten als unverifiziert. Ihr eigenes Wissen gilt weiterhin; Recherche fügt Aktualität und Quellen hinzu, ersetzt aber nicht das Urteilsvermögen.

Verfassen Sie das kanonische Design

Lesen Sie output-contract.md und semantic-contract.md. Neue Designs verwenden schemaVersion 1.1 und explizite semantische Deklarationen. Version-1.0-Eingaben bleiben lesbar, haben aber unverifizierte semantische Abdeckung; kennzeichnen Sie sie niemals als die neuen Prüfungen bestehend.

Arbeiten Sie sich durch die zehn logischen Autorenrollen in personas.md und lesen Sie die relevante Rolle nach Bedarf: Kontext, Aufgabenkarte, Komponenten, Workflow, Architektur, Modellplan, FMEA, Evaluierungen, Rollout und Übergabe. Fügen Sie im Schritt „Stack und Berechtigungen“ eine tooling-Karte pro Fähigkeit hinzu, die das Design über das Modell hinaus benötigt, ausgewählt aus tool-catalog.md und wo möglich durch Recherche überprüft; jeder Kandidat trägt seinen Verifizierungsstatus. Dies müssen nicht zehn Prozesse sein. Schreiben Sie in einen neuen Ausgabeordner; bewahren Sie den genauen Brief des Benutzers in design.json.

Gerüst des semantischen Vertrags zwischen Komponenten und Workflow erstellen. Sobald die Aufgaben- und Komponentenstadien ausgefüllt sind, führen Sie scripts/design_scaffold.py design.json --merge aus. Es schreibt das semantics-Grundgerüst: eine Knotenzeile pro Workflow-Knoten mit einer Art, die aus seiner Komponentengruppe erraten wird, eine componentEffects-Zeile pro Komponente, einen Übergang pro deklarierter Kante mit dem eigenen when des Vertrags, eine modelOutputs-Zeile pro LLM-Ausgabefeld und die Feldnamen, die jede Schreibbindung benötigt. Es erfindet nie ein Übergangsergebnis, eine Ausgabekategorie, eine Bindungsquelle, eine Aktionsklasse, eine Wartedauer oder einen Goldstandard: Dies sind Urteile über das Geschäft, und eine Vermutung ist schlechter als eine Leerstelle. Es gibt eine Checkliste dessen zurück, was Sie ausfüllen müssen. Jede Leerstelle ist "TODO" und lässt die Validierung fehlschlagen, sodass ein unvollständiger Vertrag nicht als fertiger ausgeliefert werden kann.

Verwenden Sie in Prosa und Überschriften die Leserschrittnamen: Brief und Umfang, Aufgabenkarte, Bausteine, Ablauf, Stack und Berechtigungen, Modelle und Kosten, Risiken, Tests, Messen und Ausrollen, Übergabe. Stufenschlüssel in design.json ändern sich nicht.

Code besitzt Geld, Identität, Daten und Grenzen. Modelle dürfen eine Regel oder Erklärung unter Verwendung von Beweisen vorschlagen, haben aber niemals Schreibberechtigung. Zeigen Sie die tatsächlichen vertrauenswürdigen Produzenten, Validierung, menschliche Ausnahmen, Hinweise bei langen Wartezeiten, Nachweise von Aufzeichnungen, unsichere Schreibabstimmung und begrenzte Wiederherstellungspfade. Verfolgen Sie jedes Blatt durch Komponente, Workflow und Test. Verknüpfen Sie Risiken und Evaluierungen in beide Richtungen.

Halten Sie jede Tatsache und Prüfung an einem Ort. Bevorzugen Sie in sich geschlossene Goldstandard-Fixtures. Wenn Vererbung erhebliche Wiederholungen spart, verwenden Sie eine unveränderliche versionierte Basis und explizite Zusammenführungsregel, wobei das aufgelöste Fixture enthalten ist. Schreiben Sie positive sowie negative Goldstandards für jede Aktionsklasse. Behaupten Sie niemals, dass diese Spezifikationen Geschäftskontrollen ausgeführt wurden.

Optionale Co-Design

Mit interactive: true stoppen Sie nach Aufgaben und nach Komponenten. Zeigen Sie eine kompakte ID/Titel-Zusammenfassung mit Autonomie, Risiko und Abhängigkeiten. Fragen Sie nach Bearbeitungen, Entfernungen oder Bestätigung. Warten Sie auf die tatsächliche Antwort des Benutzers; Stille oder verstrichene Zeit ist keine Bestätigung. Dieser Kontrollpunkt genehmigt den Design-Inhalt, nicht Live-Aktionen.

Zeichnen Sie den ausstehenden Kontrollpunkt mit scripts/design_session.py checkpoint auf. Wenden Sie die Aufgabenentfernungen/-bearbeitungen des Benutzers mit apply-tasks an; Nachfahren und veraltete nachgelagerte Stufen werden gelöscht. Überarbeiten Sie die Komponenten ab dem beibehaltenen Baum. Für Komponentenbearbeitungen überarbeiten Sie den Workflow und die semantischen Deklarationen. Lassen Sie keine entfernten IDs, Komponenten, Tests oder Build-Anweisungen nachgelagert. Zeichnen Sie die Kontrollpunkt-Historie auf; validieren Sie nur nach Abschluss des neu erstellten Designs. Der Standardmodus nur mit Brief hat keine Pause.

Leserschicht und Build-Meilensteine

Verfassen Sie die presentation, runOptions und milestones der obersten Ebene unter Verwendung von report-contract.md. Sowohl die erste PDF-Seite als auch der HTML-Entscheidungsbrief lesen diese. Die erste Seite muss in dieser Reihenfolge enthalten: ein Satz Systembeschreibung; 3–5 Designentscheidungen mit abgelehnter Option und Grund; Tabelle der Aktionen/Autonomie; die fünf größten Risiken nach RPN; Startblocker und Eigentümer; illustrative Kosten pro Fall; einzeilige Überprüfungsmethode, -runde und -status. Verschieben Sie die D1–D12-Bewertungen nach hinten.

Verwenden Sie auf den Seiten 1–2 klare Sprache: Lesbarkeit mindestens 50, durchschnittliche Satzlänge höchstens 20 Wörter. Vermeiden Sie kanonisch, diskriminiert, Nutzlastbindung, Digest, Idempotenz, reziprok und terminale Disposition auf diesen Seiten. Bewahren Sie genaue Namen in Verträgen/Build-Dateien und erklären Sie sie im Glossar.

Das PDF muss tatsächliche Vektor-Aufgaben- und Workflow-Diagramme enthalten, keinen Mermaid-Quellcode. Zeichnen Sie auch eine Risikomatrix nach Schweregrad × Auftreten und eine Abdeckungsmatrix von Risiken/risikoreichen Aufgaben mit Evaluierungen (Standard/Voll). Das HTML zeichnet seinen Aufgabenbaum und SVG-Ablauf aus derselben design.json; taskLabels und workflowLabels verkürzen Box- und Knotennamen, ohne IDs umzubenennen. Jede Aufgabe/jeder Knoten bleibt sichtbar; teilen Sie große Diagramme auf, anstatt Text zu verkleinern oder Knoten zu entfernen. Wenn der PDF-Renderer eine Dichtegrenze meldet, vereinfachen Sie die Leserzusammenfassung oder stellen Sie eine lesbare mehrseitige Zeichnung bereit, während alle Verträge in Begleitern erhalten bleiben. Schwächen Sie nicht die Nachverfolgbarkeit, um eine Seitenbegrenzung zu erfüllen.

Unterteilen Sie den Codierungskontext in build/00-overview.md und Meilensteindateien, die nur ihre Verträge, Verzweigungsregeln, Tests und Akzeptanzkriterien auswählen. Standard: Jede ≤25 KB, insgesamt ≤100 KB. Vollständige Fixtures bleiben in _evidence/eval-set.json indiziert; exakte Quelle in design.json. Kein vollständiger Design-Dump in jeder Build-Datei.

Überprüfen und reparieren

Lesen Sie quality-rubric.json. Wenn der Host einen separaten Agenten innerhalb der erlaubten Ressourcen der Aufgabe starten kann, verwenden Sie einen neuen Prüfer mit nur dem Brief, design.json, tatsächlichen Quellnachweisen und der Rubrik, ohne die Argumentation oder das vorgeschlagene Urteil des Autors. Halten Sie review.json, validation.json, Autorenskripte/-historie und vorherige Bewertungen für die erste Prüfung zurück; validation.json bettet die Autorenprüfung ein. Inspizieren Sie Exporte, HTML und PDF nach den unabhängigen Ergebnissen oder verwenden Sie einen separaten visuellen Grader. Kennzeichnen Sie diese tatsächliche Prüfung als independent-agent. Wenn Delegation nicht verfügbar ist, verwenden und kennzeichnen Sie self-review. Behaupten Sie kein unabhängiges Grading von einer anderen Rolle im selben Prozess.

Überprüfen Sie Verträge und effektive Fixtures, nicht nur Titel und IDs. Führen Sie aus:

python3 <skill-dir>/scripts/design_io.py validate <out>/design.json

Führen Sie vor der Prüfung design_io.py validate <out>/design.json --strict-coverage aus. Es meldet, ob das Design die Informationen trägt, die ein Leser erwartet (COV1 bis COV15 in output-contract.md): Kontextkarten für Entscheidung, Akteure, Umfang, Maßnahmen, Einschränkungen und Beweislimits; die Leserschicht; Meilensteine; den Recherche-Datensatz; eine Werkzeugkarte für jede Fähigkeit, die der Brief impliziert; einen menschlichen Auslöser, wo der Brief Geld oder Datensatzschreibvorgänge impliziert; und empfohlene Elemente wie Volumen, KPI-Baselines und zwei Beispiele pro Blatt. Beheben Sie jede erforderliche Lücke oder rechtfertigen Sie sie mit einem Annahmenstring, der mit seiner ID beginnt (z.B. COV9: Der Host bot kein Websuch-Werkzeug an). Die Prüfung sucht nach erwarteten Informationen; sie beurteilt nicht die Qualität, also tut die Prüfung dies immer noch.

Reparieren Sie Erkenntnisse und nachgelagerte Auswirkungen für höchstens drei Prüfrunden. Behalten Sie jede fehlgeschlagene review-round-N.json; senken Sie niemals Schwellenwerte oder überschreiben Sie historische Fehler. Bestehen erfordert jeden D1–D12 ≥3/4, keine ungelösten schwerwiegenden/kritischen Probleme, gültige Struktur und semantische Deklarationen und explizite Grenzen. Fehlende Startnachweise sind ein gekennzeichneter Blocker, kein erfundener Fakt. Wenn immer noch ungelöst, liefern Sie den vollständigen Entwurf als braucht Arbeit, mit Erkenntnissen.

Rendern und ausliefern

Die Laufzeitumgebung benötigt ReportLab und pypdf für PDF, aufgelistet in requirements-pdf.txt. Der Validator, Exporter und HTML-Renderer verwenden nur die Standardbibliothek von Python. Verwenden Sie eine verfügbare PDF-Fähigkeit/Laufzeitumgebung und überprüfen Sie visuell, dass das gerenderte PDF den Karten-/Diagramm-Erwartungen für die gewählte Ausgabe entspricht. Der standardmäßige Self-Review muss die PDF-Sequenz und die HTML-Ansichten enthalten, die dem Leser präsentiert werden; berichten Sie ein Problem als render.

Ausführen

Die zusammengesetzte Fähigkeit ruft Knoten nach Bedarf auf. Gehen Sie bei der Angabe von Grundwahrheiten und semantischen Verträgen niemandem in die Quere. scripts/-Skripte erzeugen und validieren, sie handeln nicht.

Das HTML startet ohne interaktive Fähigkeit; sein Viewer rendert einen schreibgeschützten Kartenleser, der den Brief, den Umfang und die Ausgabe-Meilensteine unterschreibt. Es trägt eine grafische Minikarte der Aufgabenkarte auf der Rückseite; keine Verwendung eines Browsers für den PDF-Download oder die Aktualisierung eines Agenten-Auftrags. Es sucht nicht neu; es kommt ohne JavaScript und Netzwerk aus. Das PDF ist frei. Beide sind für die Betrachtung auf einem Bildschirm bestimmt.