create-project

Fertigkeit zum Erstellen eines neuen Projekts in der Standardstruktur des Benutzers. Alles geschieht gemäß den globalen Regeln aus ~/.claude/rules/ (insbesondere project-meta.md, spcfctn-code.md, org-babel.md, file-editing.md); hier steht nur der Ablauf.

Der explizite Aufruf dieser Fertigkeit ist die Erlaubnis, spcfctn/ zu erstellen (die globale Regel „Bitte den Benutzer, spcfctn/ zu erstellen“ gilt hier nicht – der Benutzer hat bereits darum gebeten).

Schritt 0 – Vorbereitung

Projektwurzel ist das aktuelle Arbeitsverzeichnis (oder das vom Benutzer genannte Verzeichnis). Überprüfe, was bereits vorhanden ist: ls -la, find -L (Symlinks berücksichtigen).
Wenn .claude-root, .claude/CLAUDE.md usw. bereits existieren – dies ist kein neues Projekt: Überschreibe nichts, ergänze nur Fehlendes und melde, was bereits vorhanden war.
Wenn spcfctn/ bereits Teil eines gemeinsamen Repos (Monorepo) ist – teile nichts auf. Sage im Bericht Bescheid und schlage eine Aufteilung in Unterverzeichnisse mit Verlaufserhaltung beim nächsten Commit vor (spcfctn-code.md).
Gib vor jeder Erlaubnisanfrage eine kurze Zusammenfassung auf Deutsch (file-editing.md).

Schritt 1 – Projektsprache

Wenn der Benutzer in der Anfrage keine Sprache genannt hat – frage über AskUserQuestion („In welcher Sprache soll das Projekt geführt werden?“: Deutsch, Englisch, andere). Schreibe keinen Prosatext, bevor du die Sprache kennst.
Die Projektsprache betrifft die Dateien im Repository (Code, Kommentare, Commits, org/md) und externe Projektartefakte (Jira-Tickets, Confluence-Seiten). Die Chatsprache mit dem Benutzer ist separat, immer Deutsch.

Schritt 1a – Projektcode

Jedes Projekt hat einen eigenen kurzen Code aus zwei Buchstaben. Drei Buchstaben nur im äußersten Notfall, wenn keine akzeptablen zweistelligen Varianten existieren. Die Groß-/Kleinschreibung ist nicht festgelegt: Sie hängt vom Verwendungskontext ab (z. B. Jira-Ticket-Schlüssel in Großbuchstaben, KB-1676; Präfix im Code oder Namen nach der Konvention des Ortes, normalerweise klein). Zeige daher bei Vorschlägen den Code ohne Groß-/Kleinschreibung und schreibe in CLAUDE.md die Hauptgebrauchsform und geben an, wo welche Form verwendet wird.

Erfinde den Code nicht still und nimm nicht den erstbesten: Schlage explizit 3–4 interessante Optionen vor, die dir selbst gefallen (abgeleitet vom Projektnamen, seinem Wesen oder Wortspielen – mit kurzer Erklärung, warum genau diese) und lasse den Benutzer eine davon auswählen oder seinen eigenen nennen. Dies lässt sich bequem über AskUserQuestion erledigen (erste Option ist deine beste Einschätzung, markiert mit „(Empfohlen)“; „Andere“ wird automatisch für den eigenen Code des Benutzers hinzugefügt).
Überprüfe, ob der gewählte Code nicht mit den Codes vorhandener Projekte des Benutzers übereinstimmt (Suche in ~/.claude/projects/*/memory, .claude/CLAUDE.md benachbarter Projekte, bei Bedarf locate), und wenn doch, sage es und schlage andere vor.
Schreibe den Code in .claude/CLAUDE.md (Schritt 3) und erwähne ihn im Abschlussbericht.

Schritt 2 – Struktur

Erstelle im Wurzelverzeichnis:

Was	Inhalt
`.claude-root`	leere Datei (markiert die Wurzel des gemeinsamen Arbeitsverzeichnisses)
`.dir-locals.el`	untenstehendes Formular, unbedingt mit abschließendem Zeilenumbruch
`code/`	leeres Verzeichnis (hierher kommen Unterrepos/Code)
`spcfctn/code/`	Verzeichnis, falls noch nicht vorhanden (erstelle `spcfctn/` selbst, siehe oben), und darin ein separates `git init` (Routineaktion, keine Erlaubnis nötig) sowie `.gitignore` mit der einzelnen Zeile `*~`; mache keinen Commit, bis der Benutzer darum bittet. `spcfctn/` selbst ist kein Repository
`.mcp.json`	leer: `{"mcpServers": {}}` (`project-meta.md` – nur `project`-scope MCP, niemals `user`-scope)
`env.org`	literarische Quelle von `.env.example` – siehe unten
`.claude/`	siehe Schritt 3

env.org – ein Abschnitt pro MCP-Server des Projekts (* Name des MCP), der in Prosa beschreibt, welche Variablen benötigt werden und wofür; jeder Abschnitt wird mit einem :noweb-ref-Tag in der gemeinsamen .env.example getangelt (öffentlich, zeigt nur die VARIABLENNAMEN mit Platzhaltern, ohne echte Werte – org-babel.md, das Template „Multitarget“ wird hier nicht benötigt, das Ziel ist eines). Die echte .env (mit Berechtigung 600, project-meta.md) erstellt der Benutzer selbst – erstelle oder bearbeite sie nicht; .gitignore dafür wird im Projektwurzelverzeichnis nicht benötigt, da die Wurzel niemals ein Git-Repository ist (project-meta.md). Wenn zum Zeitpunkt der Projekterstellung noch kein MCP-Server vorhanden ist, kann env.org mit einem einzigen vorbereiteten Satz („Derzeit ist noch kein MCP angeschlossen“) anstelle von Abschnitten belassen werden, und später zurückgekehrt werden, wenn der erste Server erscheint.

.dir-locals.el (Abkürzung root: für org-Links, portabel, ohne hartcodierte Pfade):

#+begin_example ((org-mode . ((eval . (add-to-list 'org-link-abbrev-alist (cons "root" (locate-dominating-file default-directory ".dir-locals.el"))))))) #+end_example

(Im eigentlichen Datei ist dies reines Elisp – die Zeilen #+begin_example/#+end_example landen nicht darin.)

Falls spcfctn/ui/ benötigt wird (Layout-Analyse) – wird es später bei Bedarf erstellt; generiere keine leeren Verzeichnisse im Voraus. Jeder Unterordner von spcfctn/, der später hinzukommt (ui/, deploy/ usw.), erhält sofort ein eigenes git init und .gitignore mit *~ – spcfctn/ selbst ist kein Repository. Die Verzeichnisse draft/, raw/, data/ werden nicht erstellt, solange es nichts hineinzulegen gibt, und ihre Muster werden nicht vorab zu .gitignore hinzugefügt (project-meta.md).

Schritt 3 – `.claude/`

mkdir .claude und ein separates git init genau in .claude/ (auch wenn die Wurzel selbst ein Git-Repository ist oder innerhalb eines fremden liegt). Dies ist eine Routineaktion, keine Erlaubnis nötig. Mache keinen Commit, bis der Benutzer darum bittet.
.claude/.gitignore:

#+begin_example settings.local.json *~ #+end_example

(*~ – allgemeines Muster für Emacs-Sicherungsdateien, einschließlich *.~undo-tree~; abschließender Zeilenumbruch.)
.claude/CLAUDE.md – in der Projektsprache. Minimum:
- Abschnitt zur Sprache: Die gesamte Prosa des Projekts (Dokumentation, Code-Kommentare, Commit-Nachrichten, org-Überschriften usw.) – in der Projektsprache; dazu gehören auch Jira/Confluence-Artefakte; der Chat mit dem Benutzer bleibt weiterhin Deutsch;
- Projektcode (Schritt 1a) – als separate Zeile, z. B. „Projektcode: kb (in Jira-Ticket-Schlüsseln: KB)“;
- Kurze Beschreibung der Struktur: .claude-root markiert die Wurzel; code/ – Code; spcfctn/code/ – Dokumentation bestehender Codepraxis (eigenes Git); .claude/ – Projektabsichten und -konventionen (eigenes Git).
Erfinde nichts zusätzlich (Jira-Schlüssel, Assignee usw.) – das kommt im Laufe der Arbeit.
Schreibe nichts in settings.local.json – das ist persönlich und liegt außerhalb von Git.

Schritt 4 – Wurzel nicht in Git

Die Projektwurzel niemals ein Git-Repository (project-meta.md): Führe kein git init in der Wurzel durch und erstelle kein root-.gitignore. Wenn in der Wurzel bereits .git vorhanden ist, rühre es nicht an und informiere den Benutzer im Bericht. Wenn ein root-.mcp.json existiert, unternehme nichts damit.

Schritt 5 – Übersetzung bereits vorhandener Dateien

Alles, was vor der Erstellung im Projekt vorhanden war (außer *~-Dateien, .git, Binärdateien und den gerade erstellten Dienstdateien selbst), übersetze in die Projektsprache, wenn es in einer anderen geschrieben ist:

Schreibe den Text in vollständiger Übersetzung, unter Beibehaltung von Struktur, Tabellen, Code-Blöcken, Bezeichnern und Zitaten (Fehlermeldungen bleiben im Original).
Deutsch: verwende übliche deutsche Begriffe; übersetze keine Bezeichner oder CSS-Klassen (org-babel.md).
.md wird nur vom Agenten bearbeitet; bei .org – lösche keine unverständlichen Änderungen des Benutzers, sondern frage nach. Bei org-Dateien mit :tangle bearbeite die org-Quelle und tangle über emacsclient (org-babel.md).
Richte nach der Bearbeitung von Absätzen (Prosa, keine Code-Blöcke und keine Tabellen) die Zeilenumbrüche mittels eines echten fill-paragraph über emacsclient --eval aus (bei org zuerst (font-lock-ensure)); schreibe den Absatz in new_string/Write als einzelne Zeile. Wenn emacsclient sich nicht verbindet, bitte den Benutzer, den Server zu starten, simuliere nicht.
Führe anschließend für org/md-Prosa die Fertigkeit org-lint aus.
Wenn Teile des Inhalts auf Dateien/Projekte verweisen, die hier nicht vorhanden sind, „korrigiere“ die Verweise nicht, übersetze nur den Text darum herum.

Schritt 6 – Bericht

Liste kurz auf, welcher Projektcode gewählt wurde, was erstellt wurde, was bereits vorhanden war, was übersetzt wurde, und erinnere daran: Commits in .claude/ und in den Unterverzeichnissen von spcfctn/ wurden nicht durchgeführt (werden auf Anfrage gemacht).

Was nicht zu tun ist

Bearbeite nicht .env/.env.* (project-meta.md) und erstelle kein .mcp.json mit Geheimnissen.
Schreibe nichts in die CLAUDE.md/.claude/-Dateien von Unterrepos in code/* – nur in die root-.claude/.
Erfinde keine Sprachregeln für den Benutzer – nur die angefragte Sprache.
Weise keinen Projektcode selbst zu, ohne Vorschläge und Auswahl durch den Benutzer.
Führe kein git init in der Projektwurzel und in der Wurzel von spcfctn/ durch: Repositories nur in .claude/, in code/* und in Unterverzeichnissen von spcfctn/*.

EugineKosenko/majordom

Was ist majordom?

In Ihrer bevorzugten KI fragen

Dokumentation