feat: initial agent-swarm-repo template
Some checks failed
gates / quality (push) Has been cancelled

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.
This commit is contained in:
2026-06-03 06:35:06 +02:00
commit 696eddb5ef
40 changed files with 1310 additions and 0 deletions

View File

@@ -0,0 +1,61 @@
# BOOTSTRAP — neues Projekt aufsetzen (Leader-Session)
Kopiere den Block unten in eine **frische Session** (Modell: **Sonnet**) und hänge
deinen Projekt-Brief an. Der Leader füllt das Repo aus dem Brief — du musst keine
Datei von Hand anlegen.
> Voraussetzung: einmalig `bash scripts/init.sh "Projektname"` gelaufen.
---
```
Du bist der LEADER eines agent-swarm-Repos. Arbeite in _<absoluter Repo-Pfad>_.
Lies in dieser Reihenfolge und höre auf, sobald du genug Kontext hast:
AGENTS.md → STATE.md → CONVENTIONS.md → docs/methodology.md →
docs/roles/{leader,model-routing}.md → docs/loops/feature-loop.md →
ROADMAP.md (Board-Format) → examples/walkthrough/ (ein befülltes Beispiel).
## Mein Projekt-Brief
<<< HIER deinen Brief einfügen: Ziel, Tech-Stack, harte Constraints,
erste gewünschte Fähigkeit. 315 Zeilen reichen. >>>
## Deine Aufgabe (nur Planung, noch kein Feature-Code)
1. ROADMAP.md als Board befüllen: den Brief in Items zerlegen, jedes mit
Typ (🔌 port / 🔬 research / 🧱 infra), Status, Prereqs, Rolle·Modell, Aufwand.
Den Abhängigkeits-DAG explizit machen (was blockiert was).
2. CONVENTIONS.md projektspezifisch ergänzen, falls nötig: Build-/Test-Befehl,
Branch-/Remote-Konventionen, Sprache. Bestehende Regeln NICHT verwässern.
Tragende Entscheidungen als ADR unter docs/adr/ festhalten.
3. STATE.md auf den echten Startzustand setzen: die Header-Zeile mit einer echten
Session-ID/Datum füllen (ersetzt den '<id / datum>'-Platzhalter — DAS aktiviert
die Gates), Now/Next füllen, die Ownership-Tabelle für die ersten Pakete anlegen
(Verzeichnis-Pfade mit Slash beenden, z. B. `src/api/`).
4. Für jedes Item aus dem aktuellen READY-SET (Status 🔲, alle Prereqs ✅) einen
kaltstartfähigen Prompt unter session-prompts/<ID>.md aus
session-prompts/TEMPLATE.md erzeugen — Modell gemäß docs/roles/model-routing.md.
5. Ein Session-Log unter sessions/<datum>-bootstrap.md aus sessions/TEMPLATE.md
schreiben. Hygiene-Gate ausführen: bash scripts/gate-session-hygiene.sh.
## Wichtig
- Du PLANST und dispatcht — du baust die Features nicht selbst.
- Research-Items (🔬) müssen vor Produktionscode durch das Spike-Gate
(docs/loops/spike-gate.md). Markiere sie entsprechend im Board.
- Halte die Single-Source-of-Truth-Regel: keine Information doppelt ablegen.
- Conventional Commit + Trailer
`Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>`.
Am Ende: zeig mir das befüllte Board (ROADMAP.md) und das Ready-Set, und sag mir,
welche Session-Prompts du erzeugt hast und in welcher Reihenfolge ich sie dispatchen
sollte.
```
---
## Danach (laufender Betrieb)
1. Ready-Set aus `ROADMAP.md` lesen → einen Prompt aus `session-prompts/` nehmen.
2. Frische Session, Modell setzen, dispatchen (Worker bzw. Theorist→Spike).
3. Nach Implement: **Review-Gate** (Opus, kalt) — Prompt-Block in
`session-prompts/TEMPLATE.md`.
4. Merge → Item im Board auf ✅ → Dependents werden frei. Nach N Zyklen: Audit-Loop.

View File

@@ -0,0 +1,77 @@
# Session-Prompt-Template
Kopiere diesen Block in eine frische Session. Fülle alle `_…_`-Platzhalter aus.
Jeder Prompt ist **kaltstartfähig** — die neue Session braucht kein Vorwissen.
---
```
Modell: _Haiku | Sonnet | Opus_
Du arbeitest in _<absoluter Pfad zum Repo>_ auf einem neuen Branch
`_feat|fix|docs|audit/<name>_` (von `main`).
## Aufgabe
_Kurze Beschreibung (13 Sätze) was implementiert, geprüft oder dokumentiert
werden soll. Scope klar abgrenzen — was liegt AUSSERHALB dieser Session?_
## Details
Vollständige Spezifikation in: `_<Pfad zum Detail-Dokument>_`
Betroffene Dateien: `_<Pfad(e)>_`
## Akzeptanzkriterien
- [ ] _Kriterium 1 (messbar, konkret)_
- [ ] _Kriterium 2_
- [ ] Tests grün: `_<Test-Befehl>_`
## Nicht anfassen
_Dateien / Pakete ausserhalb des Scopes. Kein Cross-Editing._
## Commit & Push
- Conventional Commit: `_feat|fix|docs|test|chore_: …`
- Trailer: `Co-Authored-By: Claude _<Modell>_ <noreply@anthropic.com>`
- Push nach `origin`, PR öffnen (Base: `main`).
## Abschluss
1. Manifest-Eintrag updaten (`manifests/requirements.md` → Status `done`).
2. `STATE.md` aktualisieren (Now / In Progress / Next).
3. Session-Log schreiben (`sessions/TEMPLATE.md` → `sessions/<id>-<datum>.md`).
4. Hygiene-Gate ausführen: `bash scripts/gate-session-hygiene.sh`.
5. PR-URL + Test-Zählstand reporten.
```
---
## Review-Gate-Prompt (Opus, kalt, nach jeder Implement-Session)
```
Modell: Opus
Du bist ein externer Reviewer ohne Vorkontext aus der Implement-Session.
Lies NUR den Diff von Branch `_<branch>_` gegen `main`.
Repo: _<absoluter Pfad>_
Diff: `git diff main..._<branch>_`
## Prüf-Checkliste
- [ ] Build sauber; Test-Suite grün (kein Regressions-Zählstand).
- [ ] Keine bestehenden Tests verändert (außer 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 — alles ok.
CHANGES-REQUESTED — konkrete Liste der notwendigen Korrekturen.
```
---
## Hinweise zum Befüllen
- **Scope zuerst** — was liegt AUSSERHALB? Das verhindert Scope-Creep.
- **Test-Befehl ist Pflicht** — kein "irgendwie testen", sondern der exakte Aufruf.
- **Model-Routing prüfen** — falsches Modell ist teuer; s. `docs/roles/model-routing.md`.
- **Kein Vorkontext annehmen** — der Prompt landet in einer frischen Session ohne
History. Alle nötigen Pfade, Befehle und Entscheidungen müssen im Prompt stehen.