grahama1970/ask

Was macht ask?

Zuerst anhalten

Wenn der Benutzer $ask, /ask, einen Ask-Modus, Orakel, Deep Review, Parallel Review, Roundtable, Argue, CAE Lücken-Review oder Ask-DAG nennt, lesen Sie diese gesamte Datei, bevor Sie handeln. Verwenden Sie dann den echten Laufzeiteinstiegspunkt, es sei denn, der Benutzer bittet ausdrücklich um einen Fallback oder die Laufzeitumgebung ist nicht verfügbar und dieser Fallback wird gemeldet.

Ersetzen Sie $ask nicht durch spawn_agent, einen einfachen Modellaufruf, eine einfache Websuche, eine manuelle Zusammenfassung oder einen erfundenen Review.

Laufzeiteinstiegspunkt

Führen Sie Befehle aus diesem Verzeichnis aus. Die Pi-Skill-Command-Syntax wie /skill:ask webgpt Was ist 2 + 2? ist eine erstklassige Abkürzung: Der führende Browser-Handler (webgpt, webclaude, webkimi, webgemini oder webgrok) leitet an einen Tau single-call-Browser-Handler-DAG mit --execute --json weiter. Inline-Pi-Skill-Referenzen wie $ask webgpt Was ist 2 + 2? und die Leerzeichen-getrennte natürliche Schreibweise $ask web gpt Was ist 2 + 2? müssen gleich behandelt werden (web gpt wird zu webgpt normalisiert). Dies ist nur eine Kompatibilitätsabkürzung für Pi-Benutzer; es darf nicht den entfernten direkten WebGPT-Orakel-Pfad verwenden.

./run.sh tau-dag "<Anfrage>" wird intern dem Typer-Unterbefehl tau-dag run zugeordnet. ./run.sh team-plan "<Anfrage>" --team <Preset> erstellt einen rollenbasierten Multi-Agenten-Plan und eine eingefrorene Tau-DAG-Vorschau; die Ausführung erfordert explizites --execute --live (siehe README "Team Orchestration").

cd skills/ask
./run.sh --help
./run.sh webgpt Was ist 2 + 2?
./run.sh webgpt --compile-only Was ist 2 + 2?
./run.sh ask --help
./run.sh tau-dag run --help

Jeder nicht-triviale Lauf muss die Laufzeit-Artefakte erhalten. Der Standard-Artefaktsatz ist:

• <ask_id>.request.json
• <ask_id>.status.json
• <ask_id>.events.jsonl
• modus-spezifische Ausgaben wie review.md, review.json, DAG-Manifeste oder Browser-Evidenz

Laufzeit-Artefakte liegen standardmäßig unter .ask_artifacts/runs/<ask_id> oder dem angegebenen --run-output-root. Für lange, Live- oder generierte Läufe bevorzugen Sie ein speicherungsgestütztes Root-Verzeichnis wie /mnt/storage12tb/skills/ask/outputs/.... Commitieren Sie keine generierten Ask-Artefakte.

Jeder ausgeführte Handler-Aufruf (Erfolg oder Fehlschlag) wird im ask_call_log-Collection im Speicher ($memory) am Ausführungs-Engpass aufgezeichnet, mit Handler, Status, failure_code und controlled_tab_id/Konversations-URL, sofern vorhanden, sowie der bewährten Methode des letzten erfolgreichen Aufrufs (Reasoning-Auswahl, Tab-Bindung, Lebenszyklus-Modus, Dispatch-Befehl mit geschwärzten Geheimnissen). Modell-IDs werden gegen den Live-SciLLM-Katalog bei der Kompilierung validiert (invalid_scillm_model_id BLOCKIERT mit nächsten gültigen Alternativen); ein Browser-Platz mit 3+ aufeinanderfolgenden aufgezeichneten Fehlern wird vor dem Dispatch als bekannt-schlecht markiert, mit seinen Fehlercodes. Überprüfen Sie einen Platz, bevor Sie sich darauf verlassen: python3 skills/ask/scripts/ask_call_history.py --handler webgemini gibt den letzten erfolgreichen Aufruf und die letzten Fehler aus; fügen Sie --recommend hinzu, um die genaue bewährte Methode zur Wiederverwendung zu erhalten. Ein Handler ohne aufgezeichneten Erfolg ist eine blinde Vermutung – kompilieren Sie zuerst nur oder testen Sie günstig. Historische Läufe sind nachfüllbar: python3 skills/ask/scripts/backfill_call_log.py [Ausgabe-Root] nimmt jede vorhandene Knotenquittung auf der Festplatte idempotent auf (deterministischer _key pro Lauf+Knoten). Jedes JSON-Ergebnis eines AUSGEFÜHRTEN Laufs (und execution-status.json) trägt auch handler_last_success: pro Platz die letzte erfolgreiche Methode aus dem Speicher (Konversations-URL, Tab, Lebenszyklus/Layout), aktuelle aufeinanderfolgende Fehler und zu vermeidende Fehlercodes – im Kontext zurückgegeben, sodass der Projektagent nach dem Konsumieren eines Laufs nie eine separate Historiensuche benötigt.

Referenzen zum vertieften Studium (bei Bedarf lesen)

Bevor Sie dies tun	Lesen Sie dies
team-plan mit einer Plan-Datei; status --run --projection	references/plans-and-status.md
Explizites Pi-native Subagent-Ziel	references/pi-subagents.md
Ask-Ausgabe (One-Shot/Roundtable/Compete/Clean-Room) in Subagent-Spuren umwandeln	references/lane-handoff.md
herdr list/who/send an das Fenster eines anderen Agenten	references/herdr.md
Auswahl von One-Shot vs. Roundtable vs. Compete; Modell-/Aufwandsselektoren	references/modes.md
Panel-Audits, Sitzplatzliste, ratenbegrenzte Plätze, webclaude-Richtlinie	references/seats-and-audits.md
Ausführen/Überwachen eines Live-Laufs (Monitoring, Fenster, Payload-Matrix, Entblocken, Drift)	references/operations.md
Jeglicher Lauffehler	references/diagnosis.md
Kompilieren/Ausführen eines Multi-Sitz-DAG (Roundtable/Compete/Ersteller-Prüfer)	references/workflows.md
Jede Browser-Handler-Ausführung	references/browser.md

Vier Arten von Zielen

/ask adressiert vier gleichrangige Zieltypen. Sie unterscheiden sich im Transport, nicht im Rang:

Ziel	Beispiel	Transportinhaber
Herdr-Sitzung — ein Live-Agent in einem Fenster	memory, w11:p13	$monitor-herdr via herdr pane run
Modellaufruf — API/Modell-Handler	gpt-5.5-high, Codex-opus-5-high, deepseek-ai/DeepSeek-V3.2-TEE	$tau (SciLLM ist intern zu Tau)
Webmodell — browser-gestützter Reviewer (Chat-Tab, NICHT das agentische Modell; siehe die webclaude-Warnung unten)	webgpt, webclaude, webkimi	$surf + $browser-oracle
Pi-native Subagent — lokaler Pi-Berater/Worker	pi reviewer, subagent general-purpose, local coder	pi-subagents natives subagent-Tool

Ein Projektagent sollte sich nicht darum kümmern, welche Seite Browser, Modell, Herdr-Sitzung oder Pi-native Subagent ist, außer das Ziel zu benennen.

Projektagent-Schnellstart

Beginnen Sie hier, wenn der Benutzer einen einzelnen Modellaufruf, Roundtable, Wettbewerb oder Ersteller-Prüfer-Loop anfordert. Verwenden Sie eine dieser Formen; erfinden Sie keinen benutzerdefinierten Orchestrierungspfad.

Benutzerabsicht	Befehlsschema
Ein Handler antwortet	./run.sh tau-dag "<Aufgabe>" --repo <Repo> --target <Ziel> --immutable-goal "<Ziel>" --handler <Handler-oder-Modell> --execute --json
Roundtable	./run.sh tau-dag "<geteilte Aufgabe>" --repo <Repo> --target <Ziel> --immutable-goal "<Ziel>" --dag-template roundtable --handler <a> --handler <b> --topology concurrent --execute --json
Wettbewerb	./run.sh compete "<isolierte Aufgabe>" --repo <Repo> --target <Ziel> --immutable-goal "<Ziel>" --handler <a> --handler <b> --criterion <Kriterium> --execute --json
One-Shot (pro-Platz Antworten, kein Konsens)	./run.sh one-shot "<Frage>" --handler <a> --handler <b> --handler <c> — N unabhängige Single-Call-Spuren werden parallel ausgeführt; jede gibt ihre eigene nonce-gebundene Antwort oder einen benannten Blocker zurück. Teilantworten sind DEGRADIERT-aber-verwendbar (exit 0 bei oder über --min-answered); die Quorum-Verweigerung eines Roundtables gilt hier nie.
Pi-native Subagent von innerhalb Pi	subagent({ action: "list" }), dann subagent({ agent: "<Agent>", task: "<Aufgabe>" }) oder ein workflowScript-Fanout. Dies ist nur für explizite pi/subagent/local reviewer-Ziele; es ist kein Ersatz für Tau/Browser-Handler.
Ersteller dann Prüfer	./run.sh tau-dag "<Ersteller-Aufgabe dann Prüfer-Verdikt>" --repo <Repo> --target <Ziel> --immutable-goal "<Ziel>" --dag-template creator-reviewer --handler <Ersteller> --handler <Prüfer> --topology sequential --execute --json
Diagnose/Beheben/Schließen von GitHub-Issues	./run.sh fix-issues --repo <Besitzer/Name> --issue <N> [--issue <M>] [--handler gpt-5.5] [--execute] — sammelt jedes Issue via gh, diagnostiziert durch einen Live-One-Shot-Handler in strukturiertes Ursache/Fix-JSON mit dem Debugger-Leiter-Gatter (needs_debugger empfiehlt $debugger nur, wenn der fehlschlagende Übergang ein Inprozess-Laufzeitstatus ist, den kein Artefakt erklärt), und ist fehlschließend: Dry-Run standardmäßig; --execute schließt ein Issue NUR, nachdem sein benannter Verify-Befehl (typischerweise eine $agentic-evals-Fixture) tatsächlich bestanden ist. Kein Verify → blocked; fehlschlagender Verify → verify-failed, Issue bleibt offen. Quittungen pro Issue unter outputs/fix-issues/. Gatter: fixtures/fix_issues.json.

Handler sind gleichrangig, selbst wenn ihre Transporte unterschiedlich sind. Browser-Handler (webgpt, webclaude, webkimi, webgemini, webgrok) laufen über $surf und $browser-oracle. API/Modell-Handler wie gpt-5.5-high, gpt-5.5-xhigh, Codex-opus-5-high oder chutes deepseek-ai/DeepSeek-V3.2-TEE werden von Tau weitergeleitet. Projektagenten sollten sich nicht darum kümmern, welche Seite Browser oder API ist, außer den Handler zu benennen.

Handler sind gleichrangig, egal ob browser-gestützt (webgpt, webclaude, webkimi, webgemini, webgrok via $surf/$browser-oracle) oder API-gestützt (gpt-5.5-high, claude-opus-5-high, chutes <Provider>/<Modell> via Tau). Kompilieren Sie vor der Ausführung eines Multi-Sitz-DAG zuerst (weglassen von --execute), zeigen Sie dem Menschen das gedruckte ASCII-Diagramm und führen Sie es nur nach Bestätigung aus. Vollständige Modellbeispiele und Selektorregeln: references/modes.md. Vollständige Protokolle und Fehlschließ-Tabellen: references/workflows.md.

Nicht verhandelbare Bedingungen für jeden Lauf

• Ein explizites unveränderliches Ziel (--immutable-goal oder eine beschriftete Immutable goal:-Zeile) ist für Roundtable, Ersteller-Prüfer und Wettbewerb erforderlich; fehlendes Ziel schlägt die Vorabprüfung mit NEEDS_INTERVIEW, bevor ein Handler kontaktiert wird.
• Roundtables sind IMMER --topology concurrent mit einem identischen Paket für jeden Platz. Wettbewerbskandidaten werden isoliert und sehen sich nie gegenseitig.
• Ausgeführte DAGs müssen bis zu einem endgültigen Urteil über die JSON-Stream-Artefakte des Laufs überwacht werden (events.jsonl, dag-progress.json, Knotenquittungen, execution-status.json); starten Sie nicht und gehen Sie weg.
• PASS ist nur Prüfer/Modell-Evidenz; der lokale Abschluss erfordert deterministischen lokalen Beweis. DEGRADED/NEEDS_ATTENTION/Ratenbegrenzungen sind spur-lokal: behalten Sie nutzbare Plätze, befolgen Sie das Wiederherstellungspaket der fehlgeschlagenen Spur.
• Nicht-streaming-API-Antworten müssen eine typisierte Zulassung mit finish_reason=stop bestehen, bevor ihr Text als Evidenz zählen kann. Abgeschnittene, gefilterte, fehlende-finish_reason oder fehlerhafte Antworten emitieren scillm_response_incomplete; behalten Sie die rohen Bytes und Validierungsfehler von response.meta.json bei. Reparieren Sie keinen partiellen Urteilstext und wiederholen Sie nicht automatisch. Behaltene Fälle: completion-admission-rejects-truncation (erfasster Replay) und completion-admission-live-positive (echtes Provider-Readback).
• Fehler sind nicht still: Jede gescheiterte Spur gibt failure_code, ein Wiederherstellungspaket und next_command/Ticket-Anweisung preis. Lesen Sie bei jedem Fehler references/diagnosis.md und handeln Sie basierend auf der besitzenden Quittung, bevor Sie theorisieren.
• Direkte WebGPT-Orakel-Routing ($ask chatgpt, --oracle-backend webgpt, --webgpt-*) schlägt fehl geschlossen; Tau-Browser-Handler bleiben unterstützt.
• Anschlusskontinuität: Jede Browser-Spur-Knotenquittung / response.meta.json muss controlled_tab_id und die Konversations-URL enthalten; eine Null-Tab-ID ist eine fehlgeschlagene Übergabe. Wenn der Mensch möglicherweise klärende oder Folgefragen stellt, führen Sie mit --browser-tab-lifecycle fresh-keep (oder reuse-bound) aus – der Standard auto/fresh-temporary SCHLIESST das Fenster nach dem Lauf und beendet die Konversation. Melden Sie nach dem Lauf die Tab-ID + Konversations-URL und binden Sie sie (skills/browser-oracle/run.sh bind <Projekt> --backend <b> --tab-id <id> --url <url> --manual), sodass die Folgefrage dieselbe Sitzung adressiert.
• Tab-Sichtbarkeitsgatter (beobachtet 2026-09-15, webgemini): Einige Anbieter (Gemini bestätigt) verzögern das Senden im Composer, während der Tab ein verstecktes Dokument ist – in einem gemeinsamen Fenster kann nur ein Tab im Vordergrund sein, also sind N-1 von N gleichzeitigen Spuren immer versteckt und blockieren als prompt_too_large_or_stalled ("Prompt blieb nach dem Senden im Composer"). Gleichzeitige Browser-Spuren verwenden daher standardmäßig isolierte Fenster (ein Fenster pro Platz, auf dem Prüfer-Desktop platziert), sodass jeder Spur-Tab ein sichtbares Dokument ist; --window-layout shared ist Opt-in. Ein blockierter, bereits getippter Composer ist rettbar: skills/surf/run.sh tab.switch <id> macht den Tab sichtbar und das in der Warteschlange befindliche Senden wird ausgelöst. Überprüfen Sie document.visibilityState, bevor Sie Prompts für diese Fehlerklasse verkleinern. Die verifizierte, pro Platz funktionierende Methode wird in $memory gespeichert (ask_call_log-Schlüssel ask:method:webgemini; siehe ask_call_history.py --handler webgemini --recommend).
• webclaude ist ein claude.ai-Chat-Tab, nur zum Testen – NICHT agentisches Claude. Bevorzugen Sie claude-fable-low, dann claude-opus-4-8-high (siehe references/seats-and-audits.md).

Modus-Router

Verwenden Sie den engsten Modus, der der Benutzeranfrage entspricht.

Anfrage	Laufzeitmuster	Erforderliche Details
Speichergestützte Frage	./run.sh ask "<Frage>" --json	Bei Bedarf den Umfang angeben.
Orakel-Antwort	./run.sh ask "<Frage>" --oracle ... --json	Backend/Modell/Persona explizit wählen, wenn angefordert.
Pi-Browser-Handler-Abkürzung	./run.sh webgpt Was ist 2 + 2? von /skill:ask webgpt Was ist 2 + 2?	Schreibt nach Tau single-call mit --handler webgpt --execute --json um; verwenden Sie --compile-only, um den DAG ohne Live-Browser-Transport auszugeben.
Einzelner benannter Handler	./run.sh tau-dag "<Anfrage>" --handler <Handler-oder-Modell> --json	Browser-Handler verwenden $surf; Nicht-Browser-Handler sind $scillm-Modellnamen, die von Tau weitergeleitet werden. Fügen Sie --execute für Live-Transport hinzu.
Pi-native Subagent-Ziel	Natives Pi subagent-Tool, nach subagent({ action: "list" })	Nur, wenn innerhalb von Pi ausgeführt und der Benutzer explizit pi, subagent, pi-subagent, local reviewer oder local coder nennt. Browser/Modell/Tau-Ask-Anfragen verwenden diese Route nicht.
Multi-Handler-Roundtable	./run.sh tau-dag "<Anfrage>" --handler webclaude --handler gpt-5.5 ... --topology concurrent --execute --json	Roundtable ist Prompt-zu-Tau-DAG. Browser-Handler erhalten standardmäßig ein Ask-eigenes frisches Fenster. Bewahren Sie browser-tab-lifecycle.json, dag.json, Befehlsspezifikationen, Handler-Quittungen und Join-Quittungen auf.
Wettbewerb / Bakeoff	./run.sh compete "<Aufgabe>" --handler webgpt --handler webclaude --handler gpt-5.5-high --criterion deterministic-proof --execute --json	Isolierte Kandidaten plus Wettbewerbs-Scorecard und Fortsetzungsanfrage des Gewinners. Browser/API-Handler sind gleichrangig. Der Projektagent muss Funktionen vor der Förderung lokal verifizieren.
Ersteller-Prüfer-Loop	./run.sh tau-dag "<Ersteller-Aufgabe dann Prüfer-Verdikt>" --handler <Ersteller> --handler <Prüfer> --topology sequential --execute --json	Der Ersteller erhält die volle Aufgabe; der Prüfer erhält sowohl die Aufgabe als auch die Ersteller-Ausgabe. Keine Rollenvermischung.
Fix GitHub Issues	./run.sh fix-issues --repo <Besitzer/Name> --issue <N> [--issue <M>] [--handler gpt-5.5] [--execute]	Standardmäßig Dry-Run. --execute schließt ein Issue NUR, nachdem der Verify-Befehl bestanden hat. Ergebnisse unter outputs/fix-issues/. Siehe Gatter: fixtures/fix_issues.json.

Dateisystemstruktur

skills/ask/
├── run.sh                  # Haupt-Laufzeiteinstiegspunkt
├── SKILL.md                # Diese Datei
├── README.md               # Team-Orchestrierung, Benutzer-Workflows
├── references/             # Vertiefte Referenzen
│   ├── browser.md
│   ├── diagnosis.md
│   ├── herdr.md
│   ├── lane-handoff.md
│   ├── modes.md
│   ├── operations.md
│   ├── pi-subagents.md
│   ├── plans-and-status.md
│   ├── seats-and-audits.md
│   └── workflows.md
├── scripts/
│   ├── ask_call_history.py     # Letzter Erfolg/Empfehlung pro Platz
│   └── backfill_call_log.py    # Idempotentes Nachfüllen historischer Läufe
├── fixtures/
│   └── fix_issues.json         # Verify-Befehlskonfigurationen
└── tests/

Führen Sie keinen Befehl aus, der nicht in dieser Datei oder ihren Referenzen beschrieben ist. Wenn Sie einen Befehl oder Handler erfinden, wird der Lauf alle Echtzeit-Ressourcen aufbrauchen, die Pi für die tatsächliche Aufgabe benötigt.

Weitere vollständige Dokumentation zu Befehlsformen, Beispielen und Umgang mit Fehlern in den Referenzen references/workflows.md, references/seats-and-audits.md, references/browser.md und references/diagnosis.md.