Nothing starts as a Story. Everything ends woven.

Ein Projektmanagement-Tool für kleine Teams, die noch dabei sind, sich zu finden.

LOOM ist ein Projektmanagement-Tool für kleine Gruppen — typischerweise 3 bis 5 Personen, die zum ersten Mal ein größeres Projekt zusammen durchziehen. Diplomarbeiten, Abschlussprojekte, Studierenden-Forschung. Teams, die noch nicht eingespielt sind. Teams, die noch nicht wissen, wie sie miteinander arbeiten sollen, weil sie es noch nie mussten.

Solche Teams brauchen mehr als nur eine To-Do-Liste. Sie brauchen strukturierte Reflexion: einen Rhythmus, der ihnen hilft, ihre Entscheidungen zu dokumentieren, ihre Stories sinnvoll zu schneiden, und Reibungspunkte rechtzeitig sichtbar zu machen. LOOM ist dafür gebaut. Plus: LOOM hat KI-Unterstützung an den Stellen, wo sie wirklich hilft — beim Story-Schneiden im Casting, beim Comment-Verdichten, beim Loomback-Rückblick. Du musst nicht alles selbst machen. Du musst nur lernen, was du der KI mitgeben sollst, und was du selbst entscheiden musst.

LOOM ist kein neu erfundenes Framework. Es ist eine bewusste Mischung: der Takt von Scrum — feste Rituale, ein verlässlicher Rhythmus — trifft den kontinuierlichen Fluss von Kanban, in dem Stories durch Lanes wandern, ohne Sprint-Commitment. Beides haben wir auf ein anfänger-freundliches Maß heruntergebrochen. Das ist keine Theorie vom Reißbrett, sondern die Konsequenz aus der Analyse von 14 Repos vergangener Diplomarbeiten und Anschlussprojekte: Das wiederkehrende Muster dort war nie der Code — es war die fehlende Struktur für Reflexion und Begründung.

Warum heißt es LOOM?

Ein Webstuhl webt Garn zu Stoff. Du fütterst ihn mit Fäden, gibst ihm einen Rhythmus, und am Ende hast du etwas, das Fäden allein nie hätten sein können — ein zusammenhängendes Gewebe. LOOM macht genau das mit deinen losen Ideen, Entscheidungen, Notizen und Code-Schnipseln: aus chaotischer Selbst-Disziplin wird strukturierte Reflexion.

Die Metapher hat aber noch eine zweite, historische Ebene — und die hebe ich mir fürs Schlusswort auf. Nur so viel vorab: Der Webstuhl hat einmal die Arbeit einer ganzen Epoche umgekrempelt. LOOM hat deutlich bescheidenere Ziele — aber dieselbe Grundidee, dass Rhythmus aus loser Mühe etwas Zusammenhängendes macht.

Eine Story, die nicht gewoben wird, ist nur Faden auf dem Boden.

LOOM auf einen Blick — das Vokabular und die drei Schichten.

Bevor es in die Details geht, zwei Landkarten. Die erste übersetzt das LOOM-Wording in die Begriffe, die du vielleicht aus Scrum oder Kanban kennst — die Artefakte und Rituale stehen nebeneinander. Die zweite zeigt, wie die Teile zusammenhängen.

Dieselbe Idee, andere Namen

Drei Schichten, die parallel leben

LOOM ist kein Pfeil von links nach rechts, sondern drei Schichten, die gleichzeitig laufen und sich gegenseitig nähren:

Setup

Die Wurzel — acht Dialoge, die den Projekt-Kontext definieren. Lebt immer, ist nie "fertig". (§4)

Cycle

Die Arbeit — Stories laufen durch die Lanes, getaktet von Casting, Showcase und Loomback. (§5)

Project Memory

Das Gedächtnis — Flocks, Beacons und Comments sammeln sich hier und werden später per KI verdichtet. (§3)

Was im Cycle gelernt wird, justiert das Setup; jede Setup-Änderung wirft wieder einen Beacon ins Project Memory. Damit ist LOOM nicht linear, sondern rekursiv-lernend.

Vom Flock zum Woven — der Weg, den jede Idee geht.

Wenn dir mitten in der Arbeit etwas auffällt — eine Idee, ein Problem, eine Abhängigkeit — dann ist das ein Flock. Ein Flock ist die niedrigste Eintragsschwelle, die LOOM hat: ein paar Sätze in eine Markdown-Datei, fertig. Kein Schätzen, kein Owner, kein Akzeptanz-Kriterium. Das kommt später.

Beim nächsten Casting (das ist der Cycle-Start, dazu gleich mehr) werden Flocks gemeinsam mit dem Team gesichtet und zu Story-Vorschlägen verdichtet. Die Vorschläge landen in der Lane Candidates — das sind noch nicht beschlossene Stories, sondern Kandidatinnen. Erst wenn das Team sich einig ist und die Akzeptanz-Kriterien stehen, wandert eine Story in Backlog und wird mit ready: true markiert. Sobald jemand anfängt, daran zu arbeiten, geht sie zu Spinning.

Wenn die Story fertig ist, sagt der Owner: "Ich zeige sie beim nächsten Showcase." Sie geht in die Lane Showcase — die Pre-Demo-Halde. Beim Showcase-Termin (vor Coach und Stakeholdern) führt der Owner sie vor, die Akzeptanz-Kriterien werden abgehakt, und die Story wechselt nach Woven: gewoben, fertig, Teil des Stoffs.

Aber: nicht jede Story schafft es bis Woven. Manche werden gecuttet. Cut ist kein Versagen — Cut ist eine Entscheidung. Die Story ist außerhalb des Scopes geraten, ist obsolet geworden, oder das Goal hat sich geändert. Wenn du eine Story cuttest, musst du sagen warum (das ist der cut_reason). Das ist Disziplin: kein stilles Verschwinden.

Flocks, Beacons, Comments — drei Wege, etwas festzuhalten.

LOOM hat genau drei niedrigschwellige Erfassungs-Werkzeuge. Jedes hat einen klaren Zweck. Wenn du beim Werfen unsicher bist, hilft dir die Faustregel:

Flock — die zentrale Anlaufstelle für niederschwellige Erfassung

Flocks sind die niedrigste Eintragsschwelle, die LOOM hat: wirf einen, sobald dir etwas auffällt — ein Feature-Wunsch, ein erkanntes Problem, ein Lösungsansatz, ein Risiko, eine Abhängigkeit. Hinschreiben, fertig. Beim Werfen wählst du einen Typ: note · idea · risk · dependency · bug · feature (bug und feature tragen Casting-Priorität). Was daraus wird, entscheidet das Team beim Casting: ein Flock kann zu einer Story werden (der häufigste Fall), zu einem Beacon (z.B. ein erkanntes Risiko wandert ins Project Memory) oder direkt in einen Setup-Edit (wenn er ein Goal, einen Milestone oder ein Subsystem betrifft). Flocks bleiben im Vault: active bis zum Casting, dann promoted (verarbeitet) oder archived (bewusst verworfen). (Nur das Warum hinter einer schon getroffenen Entscheidung schreibst du nicht als Flock, sondern direkt als Beacon.)

Beacon — der Moment, an den du dich erinnern willst

Beacons sind das Project Memory deines Projekts — append-only: Einträge werden nicht weggeräumt, sie bleiben dauerhaft als Audit-Trail stehen. Sie werden automatisch geworfen, wenn du Setup-Felder editierst (mit Pflicht-Begründung). Plus: du kannst sie manuell werfen — wenn ein Telefonat eine Anforderung bringt, wenn ein Code-Review eine Architektur-Erkenntnis liefert, wenn ein Stakeholder eine Entscheidung fordert. Eine Entscheidung (decision) wird nicht nachträglich umgeschrieben; ändert sich die Lage, wird sie von einer neuen Entscheidung abgelöst (superseded), nicht gelöscht — der abgelöste Eintrag trägt dann einen Vorwärtsverweis (superseded_by) auf seinen Nachfolger, sodass beim Lesen sofort klar ist, welche Entscheidung jetzt gilt. So bleibt die kollektive Erinnerung intakt, die in vier Monaten erklärt, warum ihr X gewählt habt und nicht Y.

Vom losen Gedanken zum festen Eintrag. Ein Beacon lässt sich niederschwellig als note festhalten — freier Text, kein Formular, jederzeit änderbar. Die leichten Typen (note, risk, blocker, insight, dependency) bleiben frei editierbar — ein Arbeits-Notizbuch, das mit dem Gedanken wächst; eine note reift zu einem passenderen Subtyp, wenn klar wird, was sie ist. Erst wenn ein Gedanke zu einer decision wird und ratifiziert wird — oder ein Ritual versiegelt wird — friert der Text ein: ab da ist er Audit-Trail, und die jeweiligen Regeln (Ratifizierung bzw. Seal) greifen. (Der Freeze gilt dem Text; Tags und Beziehungen bleiben immer kuratierbar.)

Comment — die niederschwellige Story-Diskussion

Comments hängen an einer einzelnen Story. Wenn du beim Spinning auf etwas stößt, das das Team kennen sollte, hinterlässt du einen Comment. LOOM destilliert Comments später per KI in die Conversation-Sektion der Story — du musst nicht selbst zusammenfassen, das passiert für dich.

Weaving — Fäden zwischen den Einträgen ziehen

Flocks, Beacons und Stories sammeln sich — aber ihr Wert wächst, wenn sie vernetzt sind: welche Entscheidung hängt an welcher Story, welcher Flock führte zu welchem Insight. Im Detail-Drawer jedes Eintrags öffnet ein Weave-Mode einen Picker: Fäden ziehen (suchen + anhängen), lösen (Chip entfernen) — so leicht wie Labels setzen. Damit wird das Project Memory zum begehbaren Netz: „webt zu" / „gewebt von", dem Faden zum nächsten Eintrag folgen, und eine kleine Constellation zeichnet die Nachbarschaft. Aus einer Halde von Einträgen wird ein Gewebe, in dem man den roten Faden tatsächlich verfolgen kann.

Setup ist die Wurzel, die deinem Projekt Form gibt.

Bevor LOOM für dich arbeiten kann, musst du ihm sagen, wer du bist und was du baust. Das passiert im Setup — neun Dialoge, die du einmal durchläufst und danach pflegst. Setup ist nicht Bürokratie. Setup ist der Kontext, mit dem die KI später arbeitet.

Dialog 1

Team & Stack — wer ist dabei, welche Technologien

Dialog 2

Project Description — was bauen wir, für wen

Dialog 3

Subsystems — was hängt mit was zusammen

Dialog 4

Goals — Hauptziele (HZ), optionale Ziele (OZ), Nicht-Ziele (NZ)

Dialog 5

Milestones — bis wann ist welches Deliverable fällig (Zeit-Achse)

Dialog 6

Fallback Protocol — was tun, wenn jemand wegfällt

Dialog 7

Communication Rules — drei Regeln, jede mit Konsequenz

Dialog 8

Roadmap — welches Feature in welcher Version (Produkt-Achse)

Dialog 9

Good Practices — kuratierte Arbeitshaltungen (Disziplinen + Items), optional; „Load LOOM defaults" als Startpunkt, KI-Formulierhilfe je Disziplin

Setup ist nie fertig. Jede Änderung wirft einen Beacon mit Pflicht-Begründung. Damit ist das Setup nicht veraltete Vor-Doku, sondern lebende Wahrheit über dein Projekt.

Cycle, Casting, Showcase, Loomback — der Takt deiner Arbeit.

LOOM arbeitet in Cycles. Ein Cycle ist eine Zeit-Klammer von etwa zwei Wochen. Anders als ein "Sprint" im Scrum-Sinn ist der Cycle kein Commitment-Vertrag ("wir versprechen, X bis Datum Y zu machen"). Der Cycle ist eine Klammer um drei Rituale: er beginnt mit Casting, endet mit Showcase und Loomback.

Casting — der Cycle-Start

Beim Casting verdichtet ihr eure Flocks zu Stories. Das ist das längste und wichtigste Ritual — plant dafür Zeit ein. LOOM führt euch durch eine Vorbereitung und fünf Stages. Das Entscheidende daran: bis zum Schluss ist alles zurücknehmbar. Geschrieben wird erst in Stage 5. Ihr könnt also in Ruhe ausprobieren, umsortieren und eure Meinung ändern, ohne etwas kaputtzumachen — und ihr könnt zwischendurch aufhören und später weitermachen.

• Vorbereitung (Stage 0) — was liegt überhaupt an: Bevor die KI etwas tut, seht ihr euer Eingangs-Material: die Flocks seit dem letzten Casting, Stories die schon warten, euer Setup-Kontext. Fällt euch beim Hinsehen noch etwas ein, werft ihr hier direkt einen Flock nach.
• Stage 1 — Flock-Sichtung: Die KI gruppiert eure Flocks zu Themen und schlägt vor, zu welchem Ziel sie gehören. Ihr greift voll ein: umbenennen, Flocks verschieben, Gruppen zusammenlegen. Was ihr von Hand einsortiert, merkt sich die KI beim nächsten Durchlauf.
• Stage 2 — Story-Kandidaten: Die KI schlägt pro Thema ein bis zwei Stories vor. Jede Karte braucht eine Entscheidung von euch — annehmen, splitten, vertagen (mit Begründung) oder verwerfen. Nichts rutscht kommentarlos durch.
• Stage 3 — Refinement: Story für Story legt ihr die Akzeptanz-Kriterien fest — woran man erkennt, dass sie fertig ist. Die KI schlägt vor, ihr kuriert und ergänzt. Wollt ihr eine Story bewusst nicht verfeinern, markiert ihr sie so; sie kommt trotzdem durch, aber sichtbar.
• Stage 4 — Estimation: Jetzt wird geschätzt, und zwar als Gespräch statt Ansage: die KI nennt eine Zahl, ihr könnt mit eurer eigenen Zahl plus Begründung kontern, die KI antwortet darauf. Nach drei Runden ohne Einigung gilt „agree to disagree" — euer Wert zählt. Beide Zahlen bleiben gespeichert, damit ihr im Loomback seht, wo ihr und die KI auseinanderlagt.
• Stage 5 — Team-Kuration: Die Übersicht über alles, was ihr entschieden habt — und dann der eine echte Schreibmoment. Jetzt entstehen die Stories im Backlog, ein casting-Beacon wandert ins Project Memory, die verwerteten Flocks werden abgehakt und der neue Cycle beginnt.

Weekly — der Puls dazwischen

Casting ist am Anfang, Showcase und Loomback sind am Ende. Dazwischen liegen zwei Wochen — und genau dort verlieren Teams erfahrungsgemäß den Faden. Das Weekly ist die Antwort darauf: einmal pro Woche beantwortet jede:r für sich drei Fragen — Was habe ich letzte Woche gemacht? Wo gab es Probleme? Was habe ich diese Woche vor? Daraus wird ein weekly-Beacon.

Zwei Dinge unterscheiden es von den anderen Ritualen. Erstens: es braucht keinen Termin. Jede:r schreibt es, wenn es passt — niemand muss auf die anderen warten. Zweitens: es hängt an der Kalenderwoche, nicht am Cycle. Es läuft einfach weiter, auch über Cycle-Grenzen hinweg. Ob ihr euch die Weeklies zusätzlich mündlich erzählt, ist eure Sache; geschrieben werden sie so oder so. Der Gewinn ist eine durchsuchbare Spur: wer wissen will, woran jemand vor drei Wochen hing, liest es nach, statt zu fragen.

Showcase — der Cycle-Ende-Demo-Termin

Im Tool führt euch ein Showcase-Durchlauf durch die Stories der Showcase-Lane: pro Story die Akzeptanz-Kriterien abhaken (✅/⏭️/❌), Reviewer-Verdikt setzen — beim Abschluss wandert die Story nach Woven (oder bei Fail zurück nach Spinning). Stakeholder schauen zu, geben Feedback. Drei Pfade entstehen dabei: neue Ideen werden Flocks (Eingang fürs nächste Casting), erkannte Risiken werden Beacons (Eingang fürs Loomback), Detail-Feedback wird Comments an die jeweilige Story.

Loomback — die Team-interne Reflexion

Nach dem Showcase trifft sich das Team intern. Zuerst zeigt LOOM eine Cycle-Overview (was lief, Member-Beiträge, die Beacons des Cycle). Dann erfasst ihr eure Diskussion in Stichzeilen — und die KI verdichtet eure Worte zu strukturierten Sektionen (Highlights, Reibungspunkte, Empfohlene Maßnahmen). Ihr kuriert, dann Commit als loomback-Beacon, der dauerhaft im Vault bleibt. Wichtig: die KI strukturiert eure Reflexion — sie rät sie nicht vor und ersetzt sie nicht.

Insight-Harvest — Lehren ernten und wiederverwenden

Im Loomback entdeckt das Team Lehren. Statt sie in der Cycle-Reflexion versinken zu lassen, erntet ihr sie mit einem Klick: jede Lehren-Zeile trägt einen „→ insight"-Einstieg, der einen eigenständigen insight-Beacon vorbefüllt (die KI verdichtet die Zeile in die Vorlage Realized / Why it matters / What we do differently). Der Insight verlinkt zurück auf seinen Loomback — so wird aus flüchtiger Reflexion wiederverwendbares Wissen, das beim nächsten Cycle und in der Defensio trägt.

Wenn eine Story nicht weiter will — drei Stufen, dann Hard-Block.

Manchmal bleibt eine Story liegen. Sie startet im Backlog, kommt nicht ins Spinning. Oder sie geht ins Spinning, aber wird nicht fertig. Am Cycle-Ende ist sie immer noch da — und rollt automatisch in den nächsten Cycle. Das ist Sticky.

Sticky ist kein Versagen. Sticky ist ein Signal. LOOM macht es sichtbar in drei Stufen:

Der Eskalations-Ausweg: Cut → Flock → Re-Casting

Was tun, wenn die Idee gut war, aber die Story-Form nicht trägt? Du cuttest die Story und gibst die Essenz als neuen Flock zurück. Im nächsten Casting taucht die Idee dann frisch auf — ohne Roll-Count-Last, mit potentiell neuem Schnitt. Das geht so:

1. Story-Essenz in 2-3 Sätzen als Flock formulieren
2. Story auf Cut setzen mit cut_reason: stale und Verweis auf den neuen Flock
3. Im nächsten Casting ist die Idee wieder im Pool — frisch, neu zu schneiden

Damit ist das System nicht ideen-vergessend, aber auch nicht müll-schleppend. Die Story-Identität verfällt, der Inhalt überlebt im Project Memory.

LOOM erzieht ohne zu stechen — bis es muss.

Wofür LOOM gebaut ist — die echten Use-Cases.

LOOM ist nicht für jedes Projekt gut. Aber für die folgenden Konstellationen wurde es gebaut, und dort spielt es seine Stärken aus:

Was LOOM gut macht — drei Dinge

1. Begründungs-Geschichte. Du verlierst nie wieder die Antwort auf "warum haben wir das damals so entschieden?" — die Beacons sind da.

2. Niederschwellige Disziplin. Flock werfen ist 10 Sekunden. Casting ist KI-vorbereitet, Loomback ist KI-vorbereitet. Du machst weniger Doku-Arbeit, kriegst mehr Doku-Output.

3. Honest Reflection. Sticky Stories machen sichtbar, was du sonst übersiehst. Loomback macht die Reibung diskutierbar. Showcase trennt extern (Erfolge zeigen) von intern (Reibung diskutieren). Drei verschiedene Modi für drei verschiedene Audiences.

Pädagogisch ehrlich — diese Projekte brauchen etwas anderes.

LOOM ist gut darin, was es kann. Aber es kann nicht alles. Wenn dein Projekt einer der folgenden Typen ist, nutz besser ein anderes Werkzeug — oder zumindest LOOM nicht als Hauptachse.

Was LOOM nicht ersetzt

Auch innerhalb eines DA-Projekts ersetzt LOOM nicht alles:

• Code-Review-Plattform. Forgejo macht das. LOOM weiß von Forgejo, holt Stunden-Aggregate aus Commits, aber reviewed nicht selbst.
• Chat / Realtime-Kommunikation. Discord, Slack, oder das Schul-Tool. LOOM ist asynchron — Comments und Beacons sind keine Chats.
• Datei-Sync zwischen Geräten. Syncthing, Git, Nextcloud. LOOM ist vault-lokal, sync-frei.
• KI-Modell-Hosting. Ollama lokal oder API-Provider. LOOM ruft KI auf, betreibt sie nicht.

Diese Trennung ist gewollt: LOOM macht eine Sache richtig, statt zehn Dinge halb. Wenn du Sync brauchst, nimm Sync. Wenn du Chat brauchst, nimm Chat. LOOM ist die Reflexions-Schicht oben drauf.

Phase 0 war ohne LOOM — ab Phase 1 weben wir mit dem eigenen Werkzeug.

Das hier ist der Teil, der dir vielleicht komisch vorkommt, aber er ist wichtig. Du liest gerade ein Dokument, das aus 9 Konzept-Sessions, 200+ dokumentierten Entscheidungen und drei großen Markdown-Dateien (Vision, Architektur, Journal) hervorgeht — und das alles wurde ohne LOOM-Vault aufgebaut. Wir nennen das Phase 0: die Bootstrap-Phase, in der LOOM noch nicht als funktionierendes Werkzeug existiert. Phase-0-Items heißen bei uns deshalb bewusst Tickets, nicht Stories.

Aber: der Plan ist anders. Sobald das erste Casting läuft (Phase 1, Mai 2026), wechseln wir auf LOOM-Eigenanwendung. Wir werden mit den eigenen Artefakten und Ritualen arbeiten — Stories statt Tickets, Cycles statt loser Plan-Wochen, Casting statt Coach-Brainstorming, Showcase und Loomback als Cycle-Ende-Rituale, Beacons im Project Memory. So gut, wie es zu jedem Zeitpunkt sinnvoll ist. Wir sehen dann während der Entwicklung, was sich richtig anfühlt — und wo wir das Konzept noch nachschärfen müssen.

Plus die Lücken, die wir gerade kennen:

Was LOOM heute noch nicht kann

• Native Mobile-App. Browser-UI funktioniert auf Tablet/Phone, aber es gibt keine eigene iOS/Android-App.
• Live-Token-Streaming. Wenn die KI antwortet, siehst du in V1 das Ergebnis erst am Ende. Streaming kommt in V2.
• Versions-Filter im Board. Du kannst die Roadmap-Versionen pflegen, aber nach Version filtern („zeig mir nur V2-Stories") geht noch nicht.
• Echte Mehrsprachigkeit. LOOMs Oberfläche ist durchgehend englisch, die Domain-Werte ebenso. Weitere Sprachen kommen später als Übersetzungsschicht — hardcodiert wird nichts.

Wenn du etwas davon brauchst, weißt du jetzt, dass wir es kennen. Wir bauen es, sobald V1 läuft und wir Erfahrung haben. Das ist nicht Ausrede, das ist Iteration.

Wie KI in LOOM passt — local-first, kontextgefüttert.

LOOM hat KI nicht als Gimmick, sondern als Co-Bauer in den Workflow eingebaut. Sie sitzt nicht an einer Stelle, sondern an jeder Station, an der du ohnehin arbeitest — und überall gilt dasselbe: sie schlägt vor, du entscheidest.

• Im Setup — meist deine erste Begegnung mit der KI, lange vor dem ersten Casting. Sie prüft, ob ein Projekt-Ziel konkret genug ist (SMART), gibt Rückmeldung zu einzelnen Feldern, während du sie ausfüllst, und schlägt bei den Good Practices Einträge vor, wenn euch nichts einfällt.
• Beim Casting — an vier der fünf Stages: sie gruppiert eure Flocks zu Themen (Stage 1), schlägt daraus Story-Kandidaten vor (Stage 2), formuliert Akzeptanz-Kriterien zur Auswahl (Stage 3) und bringt eine Schätzung ins Gespräch, der ihr widersprechen könnt (Stage 4).
• An der Story — den Comment-Strom verdichtest du per Klick zur Conversation-Sektion: die KI schlägt vor, du redigierst und speicherst.
• Bei den Beacons — sie bringt einen hingeworfenen Gedanken in die Form seines Typs (bei einer Entscheidung: Kontext, Optionen, Wahl, Folgen) und schlägt beim Loomback vor, woraus ein Beacon werden könnte.
• Im Weekly — sie stellt dir ein Gerüst für die drei Fragen hin, damit du vor keinem leeren Feld sitzt.
• Im Loomback — sie bereitet die Cycle-Übersicht auf und verdichtet eure Diskussions-Stichzeilen zu strukturierten Sektionen.
• In den Documents — „Draft with AI" entwirft die Prosa-Abschnitte deines Berichts aus dem echten Cycle-Material; mehr dazu in §11.
• In der Roadmap — sie schlägt aus den Cycles eines Zeitraums Features und einen schülersprachlichen Changelog-Text vor, den ihr dann kuriert.

Local-first ist das Motto

Default-Backend ist Ollama lokal auf localhost:11434. Empfohlenes Modell: gemma4:12b für Standard-Aufgaben (läuft lokal, ~16 GB RAM, auch ohne dedizierte Grafikkarte) — stärkere Modelle, wenn die Hardware es hergibt. Externe APIs (Claude, OpenAI, Gemini) sind opt-in über config.yaml. Damit bleibt LOOM datenschutz-freundlich für Schul-DA-Teams, die keine Daten zu Cloud-Diensten senden dürfen.

Transparent bleibt das Ganze über das Prompt Lab (eigene Ansicht): dort siehst du jeden KI-Prompt, den LOOM verwendet, kannst ihn ansehen, anpassen und testen (gerenderter Prompt mit Setup-Kontext + Roh-Antwort). Details im Prompt-Lab-HowTo.

Was die KI nicht macht

LOOM hat klare Grenzen für KI-Eingriffe in V1:

• Keine autonome Story-Erstellung. KI schlägt vor, Team entscheidet — in jeder Stage. Geschrieben wird erst, wenn ihr in Stage 5 den Commit auslöst.
• Keine automatische Status-Änderung. Nur Menschen ziehen Cards zwischen Lanes.
• Keine direkte Beacon-Erstellung. KI schreibt keine Beacons selbst — Beacons werden von Setup-Edits oder manuell gezogen.

In V3 (Roadmap) ist eine Erweiterung geplant: KI als Team-Mitglied, mit eigenem Repo-Zugriff, kann Stories implementieren und im Showcase präsentieren. Aber das ist V3, nicht heute.

Deine Doku schreibt sich aus dem Project Memory — du kuratierst sie.

Der klassische DA-Schmerz: die Doku aus Woche 1 ist in Woche 12 eine Lüge auf Hochglanzpapier. LOOM dreht das um — in der Documents-View rendert das Tool fertige Dokumente direkt aus deinem Vault: Progress-Report für den Coach, Projektantrag, Stack-Übersicht. Jedes Dokument besteht aus zwei Schichten:

• Live-Blöcke wie {{setup.goals}} oder {{beacons.decisions(5)}} werden bei jedem Export frisch aus dem Projekt-Stand gefüllt. Fakten veralten nie.
• Kurations-Blöcke sind deine Erzählung: „Draft with AI" entwirft den Abschnitt aus dem echten Cycle-Material, du redigierst und frierst ihn mit deinem Namen ein (curated · datum · du). Die KI schreibt nie selbst ins Dokument.

Der Progress-Report berichtet dabei über den letzten abgeschlossenen Cycle — ein Bericht an den Coach redet nicht über den halbfertigen.

Vorlagen gehören eurem Team

Die eingebauten Vorlagen sind der Start. Jede lässt sich im Tool bearbeiten (euer Stand landet als Override in templates/ — „Revert to default" holt das Original zurück), und mit „New template" baut ihr eigene Empfänger-Formate — leer oder als Kopie. Beim Tippen von { schlägt der Editor alle verfügbaren Blöcke vor, dasselbe Menü wie im Prompt Lab. Bis zu drei Dokumente pinnt ihr als Schnellzugriff-Karten oben fest.

Drei Ausgänge: Vorschau in der View · Export als datierter Markdown-Snapshot nach documents/ · Print / PDF über den Browser-Druckdialog — unterschriftsfertig für Betreuer oder Einreichung.

Das ist deine Reihenfolge — Schritt für Schritt.

Wenn du am ersten Tag mit LOOM startest, ist hier deine Reihenfolge:

1. Setup durchlaufen. Alle acht Dialoge. Plant 2-3 Stunden ein. Das ist die wichtigste Session — der Kontext, mit dem alles andere arbeitet.
2. Erste Flocks werfen. Brainstormt im Team: was sind die ersten 10-15 Stories, die euch einfallen? Werft sie als Flocks. Nicht ausformulieren, einfach ⌘⇧F und zwei Sätze.
3. Erstes Casting. Mit Coach-Anwesenheit. Die fünf Stages durchgehen, Story-Kandidaten kuratieren, Akzeptanz-Kriterien und Schätzung festlegen. Erstes Backlog ist gefüllt. Plant dafür Zeit ein — das erste Casting ist das längste.
4. Erste Story spinning starten. Owner setzen, in Spinning ziehen, anfangen.
5. Beacons werfen, sobald sie auftauchen. Kommt eine Architektur-Entscheidung? Ein Stack-Wechsel? Ein Stakeholder-Telefonat? ⌘⇧B.
6. Comments hinterlassen, wenn ihr auf etwas stoßt. Auf der Story-Detail-View. Nicht zu kurz, nicht zu lang.
7. Erstes Showcase nach 1-2 Wochen. Stories aus Showcase-Lane vorführen, durchsprechen, nach Woven.
8. Erstes Loomback direkt danach. Manuell als loomback-Beacon. Was funktioniert? Was reibt? Welche Sticky Stories fallen auf?

Nach den ersten zwei Cycles wirst du merken: Setup ist nicht fertig. Goals haben sich verschoben. Subsystem-Abhängigkeiten sind klarer geworden. Das ist normal. Setup ist nie fertig — du editierst, jeder Edit ist ein Beacon, das Project Memory wächst.

Wenn dir LOOM gut zuhört, bekommst du drei Stimmen zurück.

In diesem Dokument hast du drei wiederkehrende Callouts gesehen. Sie sind nicht zufällig — sie sind die drei Modi, in denen LOOM mit dir arbeitet:

Plus zwei Spezial-Stimmen für die schwierigen Stellen: