user2595/agent-swarm-repo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
61ce330fdfbe14d8cddfae3b4a43ce872a5cddcd
agent-swarm-repo/docs/roles/reviewer.md
Tarik Moussa 696eddb5ef
Some checks failed
gates / quality (push) Has been cancelled
Details
feat: initial agent-swarm-repo template 
Generelles Git-Repo-Template fuer KI-Agenten-Arbeit (multi-agent swarm pattern).

Enthaelt:
- Rollen-System (Leader, Worker, Reviewer) mit Model-Routing-Matrix (Tier-basiert)
- Zwei komplementaere Loops: Feature-Loop (vorwaerts) + Audit-Loop (rueckwaerts)
- Spike-Gate fuer Research-Items (GO/NO-GO vor Produktionscode)
- Obligatorische Opus-Review-Gate nach jeder Implement-Session
- Drei ausfuehrbare Gates: session-hygiene, ownership (Cross-Edit-Schutz), doc-drift
  -- alle dormant bis zur ersten Initialisierung, dann automatisch aktiv
- Bootstrap: scripts/init.sh + session-prompts/BOOTSTRAP.md
- Worked Example (URL-Shortener-Domaene): Board, Session-Log, Audit-Finding, ADR
- Token-Hygiene (3-Tier: Session-Schnitt / Command-Disziplin / Cache-Disziplin)
- GitHub Actions CI (gates.yml) laeuft auf jedem Push/PR

Muster destilliert aus produktiv-bewaehrten Patterns des ConformalLabpp-Projekts.
2026-06-03 06:35:06 +02:00

2.0 KiB
Raw Blame History

Rolle: Externer Reviewer (kalt)

Auftrag

In einer frischen Session ohne Vorkontext verifizieren, ob das Repo stimmt und ob ein Neuling sich orientieren kann.

Modell: immer Opus. Rationale: ein unabhängiger, kapazitätsstarker Pass nach jedem Implement findet systematisch andere Fehler als das implementierende Modell. Der Reviewer darf niemals dasselbe Modell in derselben Session gewesen sein.

Zwei Reviewer-Rollen

1. Review-Gate (nach jeder Implement-Session, Feature- wie Audit-Loop)

Geht den Diff durch — nicht das ganze Repo. Prüft:

  • Build sauber; Test-Suite grün (keine Regressions im Zählstand).
  • Keine golden-vector / Parität-Tests verändert, sofern nicht explizit begründet.
  • Numerische Änderungen sind wert-identisch wo behauptet, oder getestet.
  • Neue Public-Surface (Typen, Enums, API) ist absichtlich und dokumentiert.
  • Commit-Message enthält Model-Attribution des Implementers.
  • Finding / Phase als ✅ in der Orchestration-Tabelle mit Commit-Ref eingetragen.

Ergebnis: APPROVE oder CHANGES-REQUESTED (mit konkreter Liste).

2. Audit-Reviewer (periodisch, Audit-Loop)

Startet komplett kalt — kein Vorkontext aus vorherigen Sessions.

  1. Nur AGENTS.md → STATE.md → CONVENTIONS.md lesen. Orientierung gelungen? (Ja/Nein → erstes Finding.)
  2. manifests/requirements.md durchgehen: Dateien vorhanden? Tests lauffähig?
  3. Drift suchen: Docs vs. Code, ADRs vs. Realität, STATE.md-Aktualität, tote Verweise, ungetestete Behauptungen.
  4. Hygiene prüfen: Ownership-Verstöße, Doppel-Dokumentation, Doc-Budget.
  5. Findings nach audits/<datum>.md (Template) mit Severity + Model-Zuweisung. Korrektur-Tasks in ROADMAP.md / STATE.md einstellen. Observability-Gate aktualisieren.

Prinzip

Der Reviewer baut keine Features — er deckt Lücken zwischen behauptet und belegt auf. Er nimmt an, dass alle Aussagen im Repo falsch sind, bis er sie selbst verifiziert hat.