Von der Registrierung zur ersten abgearbeiteten Anforderung

Diese Seite beschreibt den vollständigen Weg — ohne ausgelassene Schritte. Wenn du noch überlegst, ob Artifacture zu dir passt: Lies sie einmal durch. Danach weißt du es.

Was du mitbringst

Artifacture arbeitet mit deiner vorhandenen Entwicklungsumgebung zusammen, es ersetzt sie nicht. Zwei Dinge müssen auf deinem Rechner sein:

• Claude Code
• Git

Beides ist installiert, nicht eingerichtet: Du lädst es herunter, und das war es. Der Setup-Befehl prüft anschließend selbst, ob es da ist, und öffnet dir eine Anleitung, falls etwas fehlt.

Dazu kommt eine inhaltliche Voraussetzung, und die ist die eigentliche: Dein Projekt liegt in einem Git-Repository. Artifacture setzt an einer Codebasis an — ob sie aus drei Dateien besteht oder aus dreitausend, spielt keine Rolle, aber es muss eine geben.

Was du nicht brauchst, ist eigene Infrastruktur. Es gibt nichts zu betreiben, die Plattform läuft bei uns.

Zu anderen Assistenten: Die MCP-Anbindung ist ein offener Standard und funktioniert mit jedem Assistenten, der MCP-Server unterstützt. Der Ein-Befehl-Einstieg weiter unten ist auf Claude Code zugeschnitten, und der Bootstrap ist ein Claude-Code-Skill; mit einem anderen Assistenten richtest du den Arbeitsbaum von Hand ein, trägst die Konfiguration selbst nach und beantwortest die strukturellen Fragen im Gespräch statt geführt.

Konto und Arbeitsbereich

Nach der Registrierung existiert dein persönlicher Arbeitsbereich. Er gehört dir, ist leer, und niemand außer dir sieht ihn.

Ein Arbeitsbereich bündelt Projekte, Mitglieder und Abrechnung. Wenn später ein Team dazukommt, arbeitet ihr im selben Arbeitsbereich — jeder mit eigenem Zugang, alle auf denselben Projekten.

Umbrella Repository anlegen und hinterlegen

Leg ein neues, leeres Git-Repository an. Es muss nichts enthalten und keinen bestimmten Namen haben.

Dann in Artifacture ein Projekt anlegen und den Pfad dieses Repositories als Umbrella hinterlegen. Wenn dein Code bereits in eigenen Repositories liegt, trägst du sie im Projekt-Setup dazu ein: einen Namen und die Git-Adresse, je Dienst eine Zeile. Sie landen später unter <Umbrella>/src/<Name>.

Artifacture legt keine Repositories an. Du bestimmst, wo dein Code liegt und wer darauf Zugriff hat.

Was ein Umbrella ist, steht auf einer eigenen Seite: ein Repository, das dein Projekt beschreibt, ohne es zu enthalten. Dort liegen die Architekturentscheidungen und die Projektanweisungen; dein Code liegt darunter in src/ und behält seine eigene Historie. Für die nächsten Schritte reicht das.

Der Setup-Befehl

Ein Klick erzeugt einen Befehl, den du einmal im Terminal ausführst. Er stellt den Arbeitsbaum her:

• klont das Umbrella und alle eingetragenen Repositories an ihre Plätze unter src/
• legt das Artifacture-Toolset daneben — das Verzeichnis .claude/ mit den Skills, darunter der Bootstrap aus dem nächsten Abschnitt, und die Datei .mcp.json mit deinem Zugang

Die Verbindung zum Board ist damit eingerichtet. Du musst nichts weiter konfigurieren.

Bestehende Checkouts bleiben unangetastet, und alles unterhalb von src/ wird nie überschrieben — der Befehl lässt sich also gefahrlos auf einem Rechner ausführen, auf dem schon Arbeit liegt.

Der Befehl enthält einen frisch erzeugten Zugangstoken und ist deshalb nur einmal sichtbar. Jeder Klick erzeugt einen neuen; alte bleiben gültig, bis du sie im Profil zurückziehst.

Einmal Bootstrap

Der Bootstrap ist kein Programm, das du startest, sondern ein Skill — eine Anleitung für Claude Code, die mit dem Toolset in .claude/skills/ liegt. Du musst dafür nichts installieren; der Setup-Befehl hat sie mitgebracht.

Öffne den Ordner in deinem Editor, starte eine Session und ruf sie auf:

/artifacture-bootstrap

Claude Code erkennt sie auch von selbst, wenn du etwas wie „lass uns das Projekt aufsetzen" schreibst. Der ausgeschriebene Aufruf ist der verlässliche Weg. Ein Mal, danach nie wieder.

Er stellt dir strukturelle Fragen. Braucht das eine Datenbank? Melden sich Nutzer an? Gibt es mehrere Mandanten? Was er ausdrücklich nicht fragt, ist, worum es in deiner Anwendung geht — das gehört aufs Board und nicht in ein Setup-Gespräch.

Aus deinen Antworten entstehen drei Dinge:

• die Struktur im Umbrella: CLAUDE.md, ADR/, Docs/, src/
• die ersten Architekturentscheidungen, aus fertigen Vorlagen statt aus freier Formulierung
• die ersten Items auf deinem Board, nach einer festen Zuordnung statt nach Einschätzung des Modells

Liegt in src/ bereits Code, erkennt der Bootstrap das und leitet die Entscheidungen aus dem ab, was schon gebaut ist. Du beantwortest dann weniger Fragen und bekommst stattdessen Vorschläge zu sehen, die aus deinem Bestand stammen.

Danach steht dein Projekt.

Die erste Anforderung

Auf dem Board legst du an, was entstehen soll — in fachlicher Sprache. Nicht „Postgres-Tabelle mit Spalte invoice_pdf", sondern „Es gibt einen Knopf, der aus dem Vorgang ein Dokument erzeugt".

Diese Unterscheidung ist der Kern. Du beschreibst das Fachliche. Was technisch dahintersteckt, kannst du festlegen — musst du aber nicht. Ein Workflow zieht dafür das Modell heran: Es arbeitet die technischen Folgen deiner fachlichen Anforderung aus und stellt dir Rückfragen, wo es fachlich mehrere Möglichkeiten gibt. Diese Rückfragen sind der wertvollste Teil, weil sie Unklarheiten aufdecken, bevor Code entsteht.

Den Workflow wählen

Ein Workflow legt fest, welche Zustände ein Item durchläuft und wer in jedem Zustand handelt — Mensch oder Modell. Der vollständige Weg heißt HSDD und führt von Backlog über Spec, Spec Review, Implement und Code Review nach Done. Daneben gibt es kürzere Abläufe für Aufgaben ohne Spezifikation und einen für die Vorarbeit an noch unklaren Anforderungen.

Das Spec Review ist der Punkt mit der größten Hebelwirkung. Du liest dort keine Implementierung, sondern die Beschreibung dessen, was gebaut werden soll, und prüfst eine einzige Frage: Ist das, was ich meinte? Wenn ja, ist die Wahrscheinlichkeit hoch, dass auch das Ergebnis stimmt. Wenn nein, hast du eine falsche Umsetzung verhindert, bevor sie stattgefunden hat.

Arbeiten

In deiner lokalen Session fragst du nicht mehr „was sollen wir jetzt machen". Die Session holt sich die Arbeit selbst:

1. Sie fragt das Board nach offenen Aufgaben.
2. Sie zieht eine davon und bekommt dazu die Anweisung, die zu diesem Zustand gehört — im Zustand Spec eine andere als im Zustand Implement.
3. Sie arbeitet und kann jederzeit nachfragen: die Spezifikation, die Rückmeldungen aus dem letzten Review, die gesamte Vorgeschichte des Items.
4. Sie meldet das Ergebnis zurück. Der Zustand rückt weiter.

Der Unterschied zum Arbeiten mit einem Assistenten allein liegt in Schritt 2. Nicht du entscheidest, was der nächste richtige Schritt ist, und auch nicht das Modell — der Workflow entscheidet es. Das nimmt dir den ständigen Erklärungsbedarf ab.

Der Kontext, den die Session bekommt, ist auf diesen Zustand zugeschnitten. Nicht die gesamte Projektgeschichte, nur das für diesen Schritt Nötige.

Freigeben

Erreicht ein Item einen Zustand, in dem ein Mensch handelt, wartet es. Du liest, was vorliegt, und entscheidest: weiter, zurück mit Anmerkung, oder verworfen.

Geht ein Item zurück, ist die Anmerkung Teil seines Kontextes. Die nächste Session liest sie mit.

Was jetzt anders ist

Nach dem ersten Durchlauf existiert etwas, das vorher nicht existierte: eine nachlesbare Spur. Was gefordert war, wie es verstanden wurde, was daraus wurde, wer wann zugestimmt hat.

Diese Spur ist der Grund, warum sich später jemand anderes in Minuten statt in Wochen einarbeiten kann — ein neuer Kollege, oder wir, wenn du feststeckst.

Wenn du nicht weiterkommst

Schreib uns. Dahinter sitzen die Leute, die die Plattform bauen und selbst seit Monaten damit arbeiten.

Wir müssen uns dafür nicht in fremden Code einlesen — wir lesen die Architekturentscheidungen, das Board und die Vorgeschichte. Deshalb kostet die Übernahme Minuten statt Wochen, und deshalb ist sie auch wieder auflösbar: Wenn wir etwas gelöst haben, arbeitest du am nächsten Tag selbst weiter. Gleiche Plattform, gleiches Board, gleiche Artefakte.