weiconet · excellence in digitalization

Mitmachen: Arbeitsplatz einrichten

Zwei Schritte, bis du selbst am Intranet mitentwickeln kannst. Jeder Schritt hat einen fertigen Text, den du kopierst und in deine Claude-Session einfügst — Claude arbeitet ihn ab und meldet am Ende, was funktioniert und was fehlt.

Worum es geht

Das Intranet liegt als Quellcode auf GitHub. Du holst dir eine Kopie auf deinen Rechner („klonen"), änderst dort etwas, testest es lokal im Browser und schickst es zurück („pushen"). Anschließend wird die Änderung auf den Server geladen („deployen") und ist live. Für diesen letzten Schritt brauchst du einen Server-Zugang — das ist Schritt 2.

Die Arbeitsanweisungen für Claude („Skills") liegen im Quellcode mit drin. Sobald du die Kopie hast, stehen dir Befehle wie /weiconet-develop zur Verfügung — du musst nichts extra installieren oder hochladen.

/weiconet-morning-check→ /weiconet-develop→ /weiconet-quality-gate→ /weiconet-deploy→ /weiconet-vault-save

Arbeitsplatz einrichten

Prüft, ob Git und Python vorhanden sind, holt den Quellcode auf deinen Rechner und richtet die Testumgebung ein. Am Ende bekommst du eine Liste mit Haken und Kreuzen — dann wissen wir beide, was läuft.

Voraussetzung: Claude Code ist installiert und du hast die GitHub-Einladung angenommen.
Arbeitsordner: Die Claude-Session muss mit dem Ordner ~/Repos/weiconet-intranet starten (genau dieser, nicht ~/Repos) — sonst stehen die /weiconet-...-Befehle nicht zur Verfügung. Beim allerersten Mal existiert der Ordner noch nicht: dann mit ~/Repos starten und nach dem Klonen eine neue Session im Projektordner öffnen.
Kein Homebrew: Python und Node über die offiziellen Installer von python.org und nodejs.org installieren (ARM64/Apple Silicon), nicht über Homebrew.
GitHub-Auth: Die angenommene Einladung reicht nicht. Zusätzlich GitHub CLI installieren und gh auth login ausführen (GitHub.com → HTTPS → Git-Credentials Y → Web-Browser). Device-Code kopieren, nicht abtippen.

Prompt 1 — in Claude einfügen

Ich bin neu im weiconet-Intranet-Projekt und arbeite auf einem Mac. Richte bitte meinen Arbeitsplatz komplett ein und prüfe dabei jeden Schritt.

Bitte der Reihe nach:

1. Prüfe, ob Git installiert ist. Falls nicht: sag mir Bescheid, bevor du etwas installierst.
2. Prüfe, ob Python 3.12 oder neuer installiert ist. Falls die Version zu alt ist, sag es mir.
3. Lege den Ordner ~/Repos an, falls er noch nicht existiert.
4. Klone das Repository https://github.com/Pierrekromat/weiconet-intranet.git nach ~/Repos/weiconet-intranet
Falls das Klonen an der Anmeldung scheitert: sag mir das genau so, dann kläre ich das mit Pierre.
5. Wechsle in den Ordner ~/Repos/weiconet-intranet
6. Lege dort eine virtuelle Python-Umgebung an (.venv) und installiere die Abhängigkeiten aus requirements.txt
7. Prüfe mit "git ls-remote --heads origin main", ob mein GitHub-Zugang funktioniert.
8. Starte den lokalen Testserver und öffne http://localhost:8000 — melde mir, ob die Login-Seite erscheint. Danach stoppe den Server wieder.

Wichtig: Installiere nichts ungefragt. Wenn etwas fehlt, sag mir vorher, was du installieren willst.

Gib mir am Ende eine Übersicht in genau diesem Format:

System: macOS
✅/❌ Git · ✅/❌ Python 3.12+ · ✅/❌ Repo geklont · ✅/❌ Testumgebung · ✅/❌ GitHub-Zugang · ✅/❌ Testserver startet

Und darunter eine Zeile pro ❌: was genau fehlt und was ich tun muss.

Hinweis: Im Ordner liegt unter .claude/ eine Anleitung (CLAUDE.md) und mehrere Skills. Schau da gerne rein — der Skill /weiconet-setup macht genau das, was ich hier beschrieben habe, und ist die ausführliche Fassung.

Wenn alles grün ist: Schick Pierre die Übersicht. Danach kannst du mit /weiconet-morning-check in deiner Claude-Session starten — der zeigt dir jeden Tag, was neu ist und woran du arbeiten kannst.

Server-Zugang einrichten

Damit deine Änderungen live gehen können, brauchst du einen Schlüssel für den Server. Der besteht aus zwei Teilen: einem privaten, der auf deinem Rechner bleibt, und einem öffentlichen, den du Pierre schickst. Der Prompt erzeugt beide und zeigt dir nur den öffentlichen an. Ohne diesen Schritt kannst du trotzdem entwickeln und deine Arbeit abgeben — nur das Live-Schalten geht noch nicht.

Prompt 2 — in Claude einfügen

Ich brauche einen SSH-Zugang zum weiconet-Server. Bitte richte den Schlüssel auf meinem Mac ein.

1. Erzeuge einen neuen SSH-Schlüssel:
   ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_weiconet -C "soenke-weiconet"
   Frage mich vorher, ob ich eine Passphrase setzen will (empfohlen: ja).

2. Zeige mir danach NUR den öffentlichen Teil an:
   cat ~/.ssh/id_ed25519_weiconet.pub
   Das ist eine einzige Zeile, die mit "ssh-ed25519" beginnt und mit "soenke-weiconet" endet.

3. Lege in ~/.ssh/config diesen Eintrag an (ergänzen, nicht überschreiben — falls die Datei schon existiert, hänge den Block unten an):

   Host weiconet
       HostName 
       User weiconet-deploy
       IdentityFile ~/.ssh/id_ed25519_weiconet
       ServerAliveInterval 10

    bekomme ich von Pierre — frag mich danach, bevor du die Datei schreibst.

4. Erkläre mir zum Schluss in einem Satz, welche der beiden Dateien ich NIEMALS weitergeben darf.

Wichtig: Zeige mir ausschließlich den Inhalt der .pub-Datei. Die Datei ohne .pub ist mein privater Schlüssel — den darfst du nicht ausgeben, nicht kopieren und nicht verschicken.

Danach: Schick Pierre die eine Zeile aus der .pub-Datei — per Mail oder Chat, die ist nicht geheim. Er trägt sie auf dem Server ein und sagt dir die Server-Adresse. Sobald ssh weiconet "echo SSH-OK" und ssh weiconet "sudo -l" durchlaufen, funktioniert /weiconet-deploy.

Was danach gilt

Die wichtigsten Regeln — ausführlich stehen sie in .claude/CLAUDE.md im Projektordner.

Regel	Warum
Vor jeder Arbeit `/weiconet-pull`	Es arbeiten mehrere Personen am selben Code — sonst entwickelst du auf einem alten Stand.
Vor jedem Deploy `/weiconet-quality-gate`	Es gibt keine Freigabe durch Dritte. Das Gate ist die letzte Prüfung, bevor etwas live geht.
Nie `git add .`	Sonst landen fremde oder lokale Dateien versehentlich im Projekt.
Zugangsdaten nie ins Projekt	Passwörter und Schlüssel liegen ausschließlich auf dem Server, nie im Quellcode.
Nie direkt auf dem Server ändern	Der Deploy überschreibt den Server-Stand komplett — direkte Änderungen dort sind danach weg.
Server-Technik vorher klären	Docker, Zertifikate, Firewall: an der Server-Substanz hängen andere Dienste. Erst mit Pierre sprechen.
Im Zweifel `/weiconet-ask`	Ein paar Rückfragen sind billiger als eine Änderung in die falsche Richtung.