create-project

Que fait create-project ?

Compétence pour créer un nouveau projet selon la structure standard de l'utilisateur. Tout se fait conformément aux règles globales de ~/.claude/rules/ (notamment project-meta.md, spcfctn-code.md, org-babel.md, file-editing.md) ; ici ne figure que la procédure.

L'appel explicite de cette compétence est une autorisation à créer spcfctn/ (la règle globale « demande à l'utilisateur de créer spcfctn/ » ne s'applique pas — l'utilisateur a déjà demandé).

Étape 0 — préparation

• Racine du projet : répertoire de travail courant (ou le répertoire nommé par l'utilisateur). Regarde ce qui s'y trouve déjà : ls -la, find -L (on tient compte des liens symboliques).
• Si .claude-root, .claude/CLAUDE.md, etc. existent déjà — ce n'est pas un nouveau projet : ne réécris rien, complète seulement ce qui manque et signale ce qui était présent.
• Si spcfctn/ fait déjà partie d'un dépôt commun (monorepo) — ne le divise pas. Dans le rapport, signale-le et propose une subdivision par sous-répertoires avec conservation de l'historique au prochain commit (spcfctn-code.md).
• Avant chaque demande d'autorisation, donne un bref résumé en ukrainien (file-editing.md).

Étape 1 — langue du projet

• Si l'utilisateur n'a pas précisé la langue dans la demande — demande via AskUserQuestion (« En quelle langue mener le projet ? » : ukrainien, anglais, autre). N'écris aucun texte en prose tant que tu ne connais pas la langue.
• La langue du projet concerne les fichiers du dépôt (code, commentaires, commits, org/md) et les artefacts externes du projet (tâches Jira, pages Confluence). La langue de la conversation avec l'utilisateur est distincte, toujours en ukrainien.

Étape 1a — code du projet

Chaque projet possède son propre code court de deux lettres. Trois lettres — uniquement en dernier recours, quand aucun code à deux lettres acceptable n'existe. La casse n'est pas fixe : elle dépend du contexte d'utilisation (par ex. clé de tâche Jira en majuscules, KB-1676 ; préfixe dans le code ou le nom — selon la convention du lieu, généralement en minuscules). C'est pourquoi dans les propositions, présente le code sans contrainte de casse, et dans CLAUDE.md, inscris-le dans la forme d'utilisation principale et précise où chaque forme s'applique.

• N'invente pas le code en silence et ne prends pas le premier venu : propose explicitement 3–4 options intéressantes qui te plaisent personnellement (à partir du nom du projet, de son essence ou d'un jeu de mots — avec une brève explication du choix), et laisse l'utilisateur en choisir une ou donner la sienne. Il est pratique de le faire via AskUserQuestion (la première option étant la meilleure selon ton estimation, marquée « (Recommended) » ; « Other » s'ajoute automatiquement pour le code personnel de l'utilisateur).
• Vérifie que le code choisi ne coïncide pas avec les codes des projets existants de l'utilisateur (recherche dans ~/.claude/projects/*/memory, .claude/CLAUDE.md des projets voisins, si nécessaire locate) ; si c'est le cas, signale-le et propose d'autres codes.
• Enregistre le code dans .claude/CLAUDE.md (étape 3) et mentionne-le dans le rapport final.

Étape 2 — structure

Crée à la racine :

Quoi	Contenu
.claude-root	fichier vide (marque la racine du répertoire de travail commun)
.dir-locals.el	formulaire ci-dessous, avec un saut de ligne final obligatoire
code/	répertoire vide (les sous-dépôts / code iront ici)
spcfctn/code/	répertoire, s'il n'existe pas encore (crée spcfctn/ toi-même, voir ci-dessus), et dedans un git init séparé (action routinière, pas besoin de demander l'autorisation) ainsi qu'un .gitignore avec la seule ligne *~ ; ne fais pas de commit tant que l'utilisateur ne le demande pas. spcfctn/ lui-même n'est pas un dépôt
.mcp.json	vide : {"mcpServers": {}} (project-meta.md — uniquement MCP scope project, jamais user-scope)
env.org	source littéraire de .env.example — voir ci-dessous
.claude/	voir étape 3

env.org — une section par serveur MCP du projet (* Nom du MCP), décrivant en prose les variables nécessaires et leur rôle ; chaque section est tanglée (:noweb-ref) vers un .env.example commun (public, montrant uniquement les NOMS des variables avec des valeurs fictives, sans valeurs réelles — org-babel.md, le modèle « multicible » n'est pas nécessaire ici, la cible est unique). Le véritable .env (droits 600, project-meta.md) est créé par l'utilisateur lui-même — ne le crée ni ne le modifie ; un .gitignore pour lui à la racine du projet n'est pas nécessaire, car la racine n'est jamais un dépôt git (project-meta.md). Si au moment de la création du projet il n'y a pas encore de serveurs MCP, env.org peut ne contenir qu'une phrase d'attente (« Aucun MCP n'est encore connecté ») à la place des sections, et on y reviendra dès l'apparition du premier serveur.

.dir-locals.el (abréviation root: pour les liens org, portable, sans chemins codés en dur) :

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

(Dans le fichier lui-même, c'est du pur elisp — les lignes #+begin_example/#+end_example n'y apparaissent pas.)

Si spcfctn/ui/ est nécessaire (analyse de maquettes) — on le crée plus tard, selon les besoins ; ne multiplie pas les répertoires vides à l'avance. Chaque sous-répertoire de spcfctn/ qui apparaît ensuite (ui/, deploy/, etc.) reçoit immédiatement son propre git init et .gitignore avec *~ — spcfctn/ lui-même n'est pas un dépôt. Ne crée pas les répertoires draft/, raw/, data/ tant qu'il n'y a rien à y mettre, et n'ajoute pas leurs motifs dans .gitignore à l'avance (project-meta.md).

Étape 3 — .claude/

1. mkdir .claude et séparément git init dans .claude/ (même si la racine est elle-même un dépôt git ou se trouve à l'intérieur d'un autre). C'est une action routinière, pas besoin de demander l'autorisation. Ne fais pas de commit tant que l'utilisateur ne le demande pas.

2. .claude/.gitignore :

   settings.local.json
   *~
   

   (*~ — motif général des fichiers de sauvegarde Emacs, y compris *.~undo-tree~ ; saut de ligne final.)

3. .claude/CLAUDE.md — dans la langue du projet. Minimum :

   • section sur la langue : toute la prose du projet (documentation, commentaires de code, messages de commit, titres org, etc.) dans la langue du projet ; idem pour les artefacts Jira/Confluence ; la conversation avec l'utilisateur reste en ukrainien ;
   • code du projet (étape 1a) — sur une ligne séparée, par ex. « Code du projet : kb (dans les clés de tâches Jira — KB) » ;
   • brève description de la structure : .claude-root marque la racine ; code/ — le code ; spcfctn/code/ — documentation des pratiques de code existantes (propre git) ; .claude/ — intentions et conventions du projet (propre git).

   N'invente rien en plus (clé Jira, assignee, etc.) — cela apparaîtra au fil du travail.

4. N'écris rien dans settings.local.json — c'est personnel et hors git.

Étape 4 — la racine n'est pas dans git

La racine du projet n'est jamais un dépôt git (project-meta.md) : ne fais pas git init à la racine et ne crée pas de .gitignore racine. Si .git existe déjà à la racine — ne le touche pas et informe l'utilisateur dans le rapport. S'il y a un .mcp.json racine — n'y fais rien.

Étape 5 — traduction des fichiers déjà présents

Tout ce qui se trouvait dans le projet avant sa création (sauf les fichiers *~, .git, les binaires et les fichiers de service que tu viens de créer) — convertis-le dans la langue du projet, s'il est écrit dans une autre langue :

• Écris le texte par traduction complète, en conservant la structure, les tableaux, les blocs de code, les identifiants et les citations (les messages d'erreur restent en original).
• Ukrainien : « перелік », pas « список » (pour list) ; « зачіпка » pour hook ; les identifiants et les classes CSS ne se traduisent pas (org-babel.md).
• Les .md ne sont modifiés que par l'agent ; les .org — ne supprime pas les modifications incompréhensibles de l'utilisateur, demande-lui plutôt. Pour les fichiers org avec :tangle, édite la source org et tangle via emacsclient (org-babel.md).
• Après l'édition des paragraphes (prose, pas de blocs de code ni de tableaux), aligne les retours à la ligne avec un fill-paragraph réel via emacsclient --eval (pour org — d'abord (font-lock-ensure)) ; écris le paragraphe dans new_string/Write sur une seule ligne. Si emacsclient ne se connecte pas — demande à l'utilisateur de lancer le serveur, n'imite pas.
• Pour la prose org/md, après cela, exécute la compétence org-lint.
• Si une partie du contenu fait référence à des fichiers/projets absents — ne « corrige » pas les références, traduis seulement le texte autour.

Étape 6 — rapport

Énumère brièvement : le code du projet choisi, ce qui a été créé, ce qui existait déjà, ce qui a été traduit, et rappelle que les commits dans .claude/ et les sous-répertoires de spcfctn/ n'ont pas été effectués (ils le sont sur demande).

Ce qu'il ne faut pas faire

• Ne modifie pas .env/.env.* (project-meta.md) et ne crée pas .mcp.json avec des secrets.
• N'écris rien dans les fichiers CLAUDE.md/.claude/ des sous-dépôts de composants dans code/* — seulement dans le .claude/ racine.
• N'invente pas de règles linguistiques à la place de l'utilisateur — seulement la langue demandée.
• N'attribue pas le code du projet toi-même sans proposer d'options et sans que l'utilisateur choisisse.
• Ne fais pas git init à la racine du projet ni à la racine de spcfctn/ : les dépôts sont uniquement dans .claude/, dans code/* et dans les sous-répertoires de spcfctn/*.