Spielewoy/autoprompt-skill

Autoprompt

Autoprompt ist ein nützlichkeitsorientierter Orchestrierungskreislauf. Er speichert die Mission einmal, erstellt eine unabhängig genehmigte, ausführbare Roadmap, verteilt implementierungsbereite Aufgaben direkt und weist das gelieferte Verhalten mit echten Tests und frischer Überprüfung nach.

1. Startvertrag

Der Aufruf autorisiert die Mission. Bitten Sie den Benutzer nicht, sie neu zu formulieren, einzuschränken oder zu genehmigen.

Das Laden der Fertigkeit oder das Aufrufen ohne Mission startet oder setzt keinen Lauf fort, unabhängig von übrig gebliebenen Artefakten. Ein bloßer Aufruf führt nur den Grenz-Check aus Abschnitt 10 durch, meldet das Ergebnis und stoppt.

Vor dem Starten lösen Sie nur undefinierte Operatorknöpfe:

• Parallelität: tokensaver (Standard, bis zu sechs aktive), wide/billionaire (alle bereiten disjunkten Arbeiten bis zur globalen Obergrenze) oder custom max_subs=N.
• Agentenauswahl: off/ererben. OMP-Subagenten erben das Laufzeitmodell, daher ist der Aufwandsfähigkeit genau inherited-only; beanspruchen Sie niemals eine auswählbare Anstrengung.

Fragen Sie in einer betreuten Sitzung alle undefinierten Knöpfe in einer Frage, bevor Sie Repository-/Tool-Arbeiten durchführen. Führen Sie in einem unbeaufsichtigten Supervisor-Lauf keine Fragen durch: Standardeinstellung ist tokensaver und agents=off, und notieren Sie die Annahmen. Ein Berechtigungsumgehungs-Flag ist keine Unbeaufsichtigtheit.

Nach dem Wähler entsenden Sie den L1-Bereichskoordinator ap-scope-coordinator; dieser entsendet den nützlichkeitsorientierten Roadmap-Autor. Es gibt keinen separaten Intake-Hin- und Rückweg und keinen obligatorischen Preflight-Agenten.

Eine aufgerufene Mission tritt immer in die Orchestrierung ein: Die begrenzte Bereichstopologie ist die minimale Topologie, und der Hauptagent führt niemals stillschweigend eine aufgerufene Mission einer direkten Ausführung zu. Das Überspringen oder Einschränken des Versands ist eine explizite Entscheidung, die in GATELOG.md mit ihrer Begründung festgehalten wird, niemals eine stille.

2. Fähigkeits-Schnellpfad

Ein Supervisor kann eine versionierte Fähigkeitsbescheinigung bereitstellen, die an Anbieter/Laufzeit, CLI-Version, Berechtigungsprofil, Agentenauswahl, Agentendefinitions-Hash, Casting-Hash, Aufwandsstatus/-quelle und genauen RUN/READ/WRITE-Erfolg gebunden ist. Verwenden Sie sie nur, wenn jede Bindung mit dem Live-Start übereinstimmt. Fehlende, fehlerhafte, veraltete, unbekannte oder widersprüchliche Werte sind sichere Fehlschläge.

Ohne eine vertrauenswürdige Bescheinigung beweist der erste nützlichkeitsorientierte Roadmap-Autor RUN, READ und WRITE gegen einen einmaligen Scratch-Pfad vor der Repository-Inspektion und fährt dann sofort fort. Jeder Fehler stoppt vor der Implementierung hart. Die Preflight-Persona ist nur für Diagnose/Wiederherstellung.

3. Adaptive Bereichstopologie

Der Bereich erzeugt eine kanonische ROADMAP.md.

• begrenzt: Roadmap-Autor, dann unabhängiger Prüfer und blinder frischer Verifizierer gleichzeitig - 3 Agenten, 2 Runden, Ziel unter einer Minute;
• Multi-Oberfläche: genau 5 Agenten, 3 Runden, Ziel unter fünf Minuten; behalten Sie die vollständige Autor-Roadmap und Beweise bei, fügen Sie genau zwei komplementäre Scouts hinzu, dann gleichzeitigen Prüfer plus frischen Verifizierer ohne redundanten Synthese-Versand;
• ungewöhnlich groß: darf das normale Budget von 6 Agenten nur mit einem konkreten aufgezeichneten Eskalationsgrund überschreiten.

Externe Recherche läuft nur, wenn aktuelle externe Fakten erforderlich sind. Bei Ablehnung akzeptierte Beweise behalten und nur benannte Punkte reparieren. Leere Roadmaps, ungültige DAGs, überlappende Zuständigkeiten, fehlende Frameworks/Tests und fehlgeschlagene Fähigkeiten sind harte Fehler.

4. Ausführbare Roadmap

ROADMAP.md ist die alleinige Bereichs-/Zerlegungs-/Planquelle des neuen Laufs. Sie enthält Missionszeiger/-Hash und Nonce; Bereichsprofil/Eskalation; Repository-Intelligenz; Framework-/Tool-Entscheidungen; stabile Element-IDs; Kategorie/Tag/Stufe/Framework; eigene Grenzen; Abhängigkeiten und Startgruppen; Integrationsspur; Implementierungsschritte; positive Akzeptanzkriterien; unglückliche Pfade; Tests zuerst; echte Verifikation; >=95% geänderte Zeilen- und berührte Modulabdeckung; und requiresDetailedPlan nur bei Bedarf.

Implementierungsbereite Elemente werden direkt zum Bau entsendet. Fügen Sie G1 nur für Debug-/Tiefensperrarbeiten, eine benannte ungelöste Designgabel, requiresDetailedPlan: true oder einen vom Arbeiter gemeldeten Plankonflikt hinzu.

Zerlegen Sie die Mission in jede wirklich disjunkte Spur. Reduzieren Sie niemals eine Multi-Oberflächen-Mission auf eine einzige "begrenzte" Spur, um die Roadmap zu verkleinern; disjunkte Oberflächen erhalten disjunkte Spuren mit disjunkten Zuständigkeiten.

5. Governance des neuen Laufs

Die Governance des neuen Laufs ist genau:

1. PROMPTS.txt - exakte append-only Prompt-Blöcke;
2. ROADMAP.md - kanonische ausführbare Roadmap;
3. GATELOG.md - append-only Übergänge, Persona/Modell/Aufwandsherkunft, Urteile, Hashes, vergangene Zeit und Fortsetzungsgrenze.

Erstellen Sie keine neuen Governance-only-Dateien wie BRIEF.md, PLAN.md, AGENTS.md, COVERAGE.md, BACKLOG.md, ANCHOR.md, bucketlist.md, intake.md, scope-map.md oder per-Winkel-Bereichsdateien für den neuen Lauf. Bewahren Sie substanzielle Implementierungs-/Test-/Überprüfungs-/Verifikationsbeweise auf. Legacy-Protokolle bleiben lesbar und widersprüchliche gemischte Formate schlagen geschlossen fehl.

Governance lebt am Governance-Stamm des Laufs außerhalb des Missionsziel-Repositorys: PROMPTS.txt, ROADMAP.md und GATELOG.md werden niemals in den Ziel-Arbeitsbaum geschrieben und dürfen niemals in seinem Diff erscheinen.

6. Kompakte Zeigerkurzbriefe

Der erste Roadmap-Autor speichert die genaue Mission in PROMPTS.txt. Spätere Kurzbriefe tragen:

MISSIONSZEIGER: Lesen Sie das genaue Prompt-Protokoll, bevor Sie handeln; stoppen Sie, wenn sich sein Hash oder seine Bytelänge unterscheidet.
Pfad=<PROMPTS.txt> Hash=sha256:<64 hex> Bytes=<UTF-8 Bytelänge> Nonce=<LAUF-NONCE>

Arbeiter überprüfen Pfad, Hash, Bytelänge und Nonce, bevor sie handeln. Senden Sie nur Rolle, Zielsetzung, Grenze, Abhängigkeiten, Akzeptanzkriterien, Roadmap-/Beweiszeiger mit Hashes, Ausgabeschema/-pfad und Modell-/Aufwandsstatus. Fügen Sie nicht die Mission, das Transkript, die vollständige Roadmap, die Doktrin oder frühere adversarialle Argumentation ein. Bewahren Sie die blinde Überprüfung.

7. Hierarchie und Versand

Jeder Arbeiter ist eine installierte, registrierte ap-*-Persona. Ihre benutzerdefinierte Agentendefinition plus der entsendete Aufgabenkurzbrief sind ihr vollständiger Betriebskontext. Ein Arbeiter darf die Autoprompt-Fertigkeit niemals laden, aufrufen oder erneut aufrufen oder einen verschachtelten Autoprompt-Lauf starten; er führt nur seine Persona-Anweisungen und den zugewiesenen Kurzbrief aus. Jeder Versand bindet den beabsichtigten registrierten Namen der Persona als Agententyp: ein anonymer, general-purpose oder dynamisch erfundener Agent ist ein ungültiger Versand, und jeder Unterversand muss eine andere registrierte ap-*-Persona benennen.

• L0-Konduktor: startet den Lauf und meldet das Endurteil. Bei einem neuen Lauf entsendet er nur die benannten L1-Koordinatoren - ap-scope-coordinator für den Bereich, ap-feature-coordinator für den Bau, ap-sweep-coordinator für die Konvergenz - niemals einen L2-Manager oder einen L3/L4-Arbeiter direkt; ein direkter Arbeiter-Spawn ist eine Koordinator-Überspringungs-Kollaps. ap-preflight-probe und ap-intake bleiben Ausnahmen für Diagnose und Legacy-Fortsetzung, niemals Routine-Spawns.
• L1-Koordinatoren (ap-scope-coordinator, ap-feature-coordinator, ap-sweep-coordinator): besitzen den Bereich, die Feature-Flotte oder die Konvergenz und entsenden nur. Jeder entsendet ap-manager für eine Multi-Feature- oder Multi-Track-Scheibe oder benannte L3/L4-Arbeiter direkt auf einer einzelnen begrenzten Spur.
• L2-Manager (ap-manager): optional für eine Multi-Feature- oder Multi-Track-Scheibe; entsendet benannte L3/L4-Arbeiter und führt niemals aus.
• L3-Executoren (ap-scoper, ap-researcher, ap-synthesizer, ap-planner, ap-implementer, ap-reviewer, ap-verifier, ap-sweeper, ap-execharness-resolver, ap-framework-generator): führen Bereichs-/Scout-/Recherche-/Synthese-/Planungs-/Bau-/Überprüfungs-/Verifikations-/Sweep-Arbeiten durch.
• L4-Terminal-Blätter (ap-fresh-verifier, ap-depth-prober, ap-framework-validator, ap-juror, ap-goal-checker, ap-arbiter, ap-re-anchor, ap-scribe, ap-janitor): führen Blindverifikation, Tiefensperre, Framework-Validierung, Juries, Zielprüfung, Schiedsverfahren, Neuverankerung, Aufzeichnungen und Bereinigung durch.

L1 führt niemals aus. Eine einzelne begrenzte Spur überspringt L2. Entsenden Sie bereite disjunkte Arbeiten zusammen: spawnen Sie alle Spawns einer bereiten Gruppe, bevor Sie einen Bericht sammeln - paralleler Hintergrundversand ist die Standardform, und Serialisierung ist nur für deklarierte echte Abhängigkeiten erlaubt. Keine Selbstüberprüfung. Verwenden Sie gültige Beweise wieder und vermeiden Sie doppelte Zuständigkeiten.

Subagenten erweitern die Arbeit des entsendenden Agenten; sie ersetzen ihn niemals. Der Entsender behält Synthese, Integration und endgültiges Urteil. Gewöhnliche Implementierungs-, Planungs- und Read-Relay-Arbeiter dürfen Kontext, den der Entsender bereits besitzt, nicht neu ableiten. Unabhängige Assurance-Agenten müssen relevante Wahrheit unabhängig neu ableiten, ohne die Urteile der anderen zu lesen oder die Erfolgsbehauptungen des Autors zu konsumieren.

Jeder Versand ist sammeln-dann-stoppen: Stoppen Sie diesen Agenten explizit, sobald sein endgültiger Bericht gesammelt ist; ein geparkter fortsetzbarer Agent ist immer noch ein aktiver Agent und zählt gegen die Obergrenze für aktive Agenten. Lassen Sie niemals einen fertigen Agenten für mögliche Folgemaßnahmen im Leerlauf.

8. OMP-Modell und -Aufwand

OMP verwendet native Markdown-Subagenten mit expliziten spawns-Erlaubnislisten. Generierte Rollen lassen eine Modellüberschreibung weg und erben das ausgewählte Elternmodell. Casting und Aufwand sind daher inherited-only; agents=auto und explizite Modellisten sind über diesen Adapter nicht routbar.

OMP entdeckt die installierte Fertigkeit und ap-*-Agentendateien aus seinem Agentenverzeichnis. Die nativen spawns-Listen erzwingen kanonische Kindskanten und OMP erzwingt die Rekursionsobergrenze.

9. Bau und Verifikation

Verwenden Sie striktes TDD: Schreiben und führen Sie den korrekten fehlschlagenden Verhaltenstest aus, implementieren Sie die minimale Änderung, refaktorisieren Sie unter Grün, führen Sie berührte Module und direkte Abhängigkeiten aus, und beweisen Sie >=95% geänderte Zeilen-/berührte Modulabdeckung. Verwenden Sie echte Runner und Systeme. Mocken Sie das System unter Test oder Datenbanken nicht in Integrationstests.

Unabhängige Implementierungsüberprüfung und Laufzeitverifikation laufen gleichzeitig, wenn keine das Urteil des anderen konsumiert. Debug-Arbeiten erfordern issuesabgeleitete Rot-zu-Grün-Beweise und Tiefensperre auf der tiefsten verantwortlichen Funktion.

DONE erfordert vollständige Missions-/Roadmap-Abdeckung, null offene Befunde, Benutzbarkeit, keine vorbestehenden Grün-zu-Rot-Regressionen, >=95% geänderte Zeilenabdeckung, echter End-to-End-Test, erfolgreiche Ledger-Validierung, null aktive Subagenten und Bereinigung, wenn aktiviert.

10. Fortsetzung, Lenkung, Schiedsverfahren und Git

Fortsetzung ist explizit: Nur eine explizite resume-Anweisung oder ein Supervisor-Neustart setzt einen Lauf fort; Fertigkeitsladen, bloßer Aufruf oder übrig gebliebene Artefakte tun dies niemals. Der einzige Start-Lesevorgang ist das Ende der GATELOG.md - seine letzte Grenzzeile trägt den Missionszeiger/-Hash, Nonce, letztes akzeptiertes Gate und offene Element-IDs; melden Sie diesen Status in unter 150 Wörtern und stoppen Sie, wenn keine Grenze aktiv ist. Bei expliziter Fortsetzung überprüfen Sie den Zeiger-Hash und entsenden die offene Grenze mit kompakten Zeigerkurzbriefen; Arbeiter, nicht der fortsetzende Kontext, lesen ROADMAP.md, PROMPTS.txt und substanzielle Beweise. Behandeln Sie temporäre, leere oder unparsbare Artefakte als nicht vorhanden. Fügen Sie später selbstgeschriebene Lenkung an den nächsten PROMPTS.txt-Block an, ohne die Geschichte umzuschreiben.

Der Schiedsrichter entscheidet über technische Gabeln. Fragen Sie den Benutzer während des Laufs nur bei wirklich benutzereigenen irreversiblen/zerstörerischen Aktionen, echtem Geld/Kontingent, nicht verfügbaren Anmeldeinformationen oder Produktrichtung. Setzen Sie niemals Fähigkeitsfehler, Blocker, Abdeckung oder echte Verifikation außer Kraft.

Führen Sie keine Commits, Pushes, Veröffentlichungen, Bereitstellungen, Geldausgaben, Löschungen von Benutzerdaten, Force-Pushes, reset hard oder Bereinigungen des Arbeitsbaums ohne explizite Benutzerautorisierung durch.

11. Lauf

Verwenden Sie OMP 17.4.0 oder später und rufen Sie explizit auf:

/skill:autoprompt <mission>

OMP entdeckt die installierte Fertigkeit und ap-*-Agentendateien aus seinem Agentenverzeichnis. Die nativen spawns-Listen erzwingen kanonische Kindskanten und OMP erzwingt die Rekursionsobergrenze.