grahama1970/agent-status

Was macht agent-status?

Verwende dieses Skill immer dann, wenn ein Projekt-Agent mehrschrittige Arbeit verrichtet und der Mensch wissen muss, was wirklich passiert.

Dieses Skill ist bewusst kein Dashboard-Generator. Es erzeugt eine Wahrheitsoberfläche, die auf maschinenlesbaren Artefakten basiert:

.plan-iterate/<kampagnen-id>/status/
  status.json
  events.jsonl
  proof_manifest.json
  STATUS.html

Das HTML rendert nur das aktuelle Status-Artefakt. Es darf keine Fortschritte, Prozentsätze oder Fertigstellungsbehauptungen erfinden.

Kernprinzip

Status-Artefakt zuerst → HTML rendert Artefakt → Mensch kann Nachweis prüfen

Niemals so vorgehen:

Hübsche Seite zuerst → vage grüne Sprache → Mensch schließt auf Fortschritt

Erforderliche Antworten im ersten Ansichtsfenster

Eine generierte Statusseite muss antworten:

1. Was versucht der Agent zu erledigen?
2. Wo genau stehen wir?
3. Was ist gerade bestanden?
4. Was ist noch nicht belegt?
5. Was ist der nächste Schritt?
6. Läuft der Agent, ist er blockiert, im Leerlauf oder wartet er auf den Menschen?
7. Welcher Nachweis untermauert die aktuelle Behauptung?
8. Was soll der Agent als Nächstes nicht tun?

Zustandsmodell

Zulässige Zustände:

• not_started
• running
• needs_attention
• blocked
• failed
• passed_scoped_gate
• done
• idle

Wichtige Unterscheidung:

passed_scoped_gate != done

Verwende done nur, wenn das endgültige Ziel ein explizites abschließendes Nachweis-Artefakt besitzt.

Gängige Befehle

Eine Kampagne initialisieren:

./run.sh init \
  --campaign refactor-harness-e2e \
  --goal "Finishing des scoped Refactor-Harness-E2E-Nachweises"

Ein Gate als laufend markieren:

./run.sh update \
  --campaign refactor-harness-e2e \
  --state running \
  --current-step "Härtenden Concurrent-LLM- + OpenCode-Summarize-Gate ausführen"

Ein bestandenes Gate protokollieren:

./run.sh gate-passed \
  --campaign refactor-harness-e2e \
  --label "A01-A18 gehärteter Concurrent-LLM- + OpenCode-Summarize" \
  --verdict PASS_SPEC \
  --proof ".plan-iterate/refactor-harness-e2e/proof/refactor-concurrent-mixed.json" \
  --next-action "Reviewer-Paket + Reviewer-Fan-In-PHASE starten" \
  --not-proven "Transport Room B1 UI" \
  --not-proven "build_review_packet reviewer fan-in" \
  --not-proven "Vollständige OpenCode-Nachrichtenzustellung"

Den Menschen um eine Entscheidung bitten:

./run.sh needs-human \
  --campaign refactor-harness-e2e \
  --question "Welche nächste Kampagne soll der Agent ausführen?" \
  --option "A=Harness fortsetzen: Reviewer-Paket + Reviewer-Fan-In" \
  --option "B=TransportUI: Transport Room B1 starten" \
  --option "C=Nur stabilisieren: Checkpoint und Stopp"

Die Statusseite erneut rendern:

./run.sh render --campaign refactor-harness-e2e

Anti-Dashboard-Theater-Regeln

1. Keine Prozentangaben.
2. Kein grünes „Abgeschlossen“, es sei denn, das endgültige Ziel ist belegt.
3. Jedes BESTANDEN muss sein Nachweis-Artefakt benennen.
4. Jeder Status muss zeigen, was nicht belegt ist.
5. Jeder Leerlauf-Zustand muss sagen, warum der Agent im Leerlauf ist.
6. Jeder Warte-auf-Mensch-Zustand muss ein Entscheidungsmenü enthalten.
7. Jeder blockierte Zustand muss das fehlende Artefakt, den Dienst, das Gate oder die Entscheidung benennen.
8. Automatische Aktualisierung ist nur erlaubt, wenn die Seite status.json liest.
9. Wenn status.json veraltet ist, muss die Seite „veraltet“ anzeigen.
10. Prüfer-Urteile sind Quittungen, kein Fertigstellungsnachweis.

Wann verwenden

Verwende dieses Skill für:

• /plan-iterate
• /orchestrate
• /review-design
• /review-code
• /debugger
• /ask deep-review
• /code-runner
• /subagent-runner
• jede mehrschrittige Projekt-Agenten-Arbeit, die länger als einen fokussierten Befehl dauert

Artefakt-Erwartungen

status.json ist die Quelle der Wahrheit.

events.jsonl ist append-only und protokolliert Zustandsübergänge.

proof_manifest.json listet die Nachweis-Artefakte auf, die durch Statusbehauptungen benannt werden.

STATUS.html wird generiert, ist veraltungsbewusst und kann sicher im Browser geöffnet werden.

Abschlussstandard

Eine abschließende Antwort für länger laufende Agentenarbeit sollte das aktuelle Status-Artefakt zusammenfassen und – falls verfügbar – auf den Pfad der STATUS.html verlinken oder diesen zitieren.

Behaupte keinen Abschluss, es sei denn:

• der Zustand ist done;
• last_completed.proof_path zeigt auf ein endgültiges Nachweis-Artefakt;
• not_proven ist leer oder explizit als außerhalb des Rahmens gekennzeichnet;
• Blocker sind leer.