kikita-labs/kikita-create-angular-app

Que fait kikita-create-angular-app ?

Amorce un nouveau projet Angular et génère son arborescence documentaire AGENTS.md / .agents/ afin que tout agent IA (Claude Code, Codex, etc.) travaillant ensuite sur le projet dispose d'une source de vérité complète et auto-maintenable.

0. Détection du mode (toujours à faire en premier)

Trois états possibles pour le répertoire cible — à vérifier dans cet ordre :

1. .agents/.kikita-scaffold.json présent → ce projet a déjà été scaffoldé ou adopté par cette compétence. Suivez update.md — ne relancez pas le questionnaire, ne re-scaffoldez pas, ne relancez pas adopt.md. update.md gère le téléchargement du dernier template, le diff depuis le commit enregistré, et la fusion des modifications dans les fichiers .agents/ (éventuellement personnalisés) du projet.
2. Répertoire vide ou presque vide (pas de package.json, pas de angular.json, rien à part peut-être un .git//README que l'utilisateur vient de créer) → initialisation complète. Continuez avec la section 1 ci-dessous, puis plan.md.
3. Projet existant, sans enregistrement de scaffold (package.json/angular.json présents, pas de .agents/.kikita-scaffold.json) → c'est un projet Angular existant (ou un projet plus ancien, antérieur à cette compétence). Ne lancez pas plan.md — il suppose un répertoire vide et essaiera de faire ng new sur un vrai projet. Suivez plutôt adopt.md : il génère l'arborescence .agents/ en fonction de ce qui existe réellement, en déduisant les réponses du questionnaire à partir de la configuration existante plutôt qu'en scaffoldant de nouveaux outils, et demande avant de modifier quoi que ce soit qui existe déjà.

0.5 Préconditions (initialisation complète uniquement)

• Confirmez que le répertoire de travail est vide ou que l'utilisateur souhaite explicitement y initialiser le projet.
• Si le répertoire s'avère non vide lors de la vérification, arrêtez-vous et redirigez vers le cas 3 ci-dessus (adopt.md) au lieu de forcer le chemin d'initialisation — ne demandez pas à l'utilisateur de simplement « confirmer qu'il est acceptable d'initialiser ici » alors que ce dont il a besoin est le flux d'adoption.

1. Questionnaire (toujours demander avant de toucher au système de fichiers)

Suivez plan.md étape par étape à partir d'ici. Ne sautez pas le questionnaire. Ne sautez pas l'installation MCP. Une fois terminé, parcourez checklist.md avant de dire à l'utilisateur que c'est fini.

Posez les questions à l'utilisateur, en un seul tour, d'un coup :

1. CSS : CSS natif (propriétés personnalisées), SCSS ou Tailwind CSS ?
   • Tailwind est une branche structurellement différente, pas une variante des deux autres : pas de schéma @layer {{PREFIX}}.*, pas de jetons :root écrits à la main, pas de mixins SCSS — voir les blocs de scaffold CSS=Tailwind dans templates/.agents/code-style/css-architecture.md, component-structure.md, et templates/.agents/architecture/folder-structure.md.
2. Bibliothèque UI : @kikita-labs/ui, Taiga UI, PrimeNG, ou aucune (construire un ensemble UI basé sur des jetons local) ?
   • Si une bibliothèque est choisie : vérifiez si elle fournit un schéma ng add et/ou un serveur MCP. Privilégiez le schéma. Si elle a un MCP, installez-le (voir plan.md étape 4).
3. Tests : aucun, unitaires uniquement, e2e uniquement, ou les deux ? Quel exécuteur (Vitest/Jasmine+Karma est déprécié sur les nouveaux Angular — préférez Vitest ; Playwright pour les e2e) ?
4. SSR : cette application est-elle rendue côté serveur (Angular SSR / hydratation) ou client uniquement ?
   • Détermine si .agents/architecture/platform-adapter.md est généré.
5. i18n : ce projet a-t-il besoin de plusieurs locales (@angular/localize ou une bibliothèque i18n d'exécution) ? Si oui, quelle approche ?
   • Détermine si .agents/i18n.md est généré.
6. JSDoc sur l'API publique : imposer un JSDoc obligatoire sur chaque symbole exporté, ou l'ignorer ?
   • Détermine si .agents/agent-surface.md est généré (recommandé par défaut : oui).
7. Préfixe du projet : préfixe de sélecteur court en kebab-case pour les composants/directives.
8. Politique Git : l'agent peut-il commit et push sans demander à chaque fois, ou chaque commit/push doit-il être confirmé ?
9. Gestionnaire de paquets : npm, pnpm ou yarn ? Recommandation par défaut : pnpm (plus rapide, efficace en disque grâce à un magasin partagé à adressage par contenu, résolution des dépendances plus stricte). Ne remplacez la valeur par défaut que si l'utilisateur demande autre chose.
10. Dépôt Git distant : l'utilisateur a-t-il déjà une URL de dépôt vers laquelle pousser ? Si oui, enregistrez-la — git remote add origin <url> s'exécute juste après git init (voir plan.md étape 9). Si aucune URL n'est donnée, ignorez cette étape ; l'utilisateur configurera le dépôt distant lui-même plus tard.

Enregistrez chaque réponse — elles pilotent à la fois le scaffold et les fichiers de documentation générés. Ne supposez jamais silencieusement une valeur par défaut ; si l'utilisateur ignore une question, reposez-la pour celle-ci. Cette compétence cible un seul projet Angular, pas un monorepo — si l'utilisateur veut un monorepo/espace de travail Nx, dites que cette compétence ne couvre pas cela et arrêtez-vous plutôt que d'improviser.

2. Génération

Suivez plan.md. Copiez les fichiers de templates/ dans le projet cible, y compris les fichiers point (.gitignore, .editorconfig, .prettierrc, .prettierignore, .nvmrc, .vscode/extensions.json).

Deux choses différentes se produisent avec les réponses du questionnaire, ne les confondez pas :

• Placeholders textuels — recherchez et remplacez chaque {{TOKEN}} par la valeur réelle, n'en laissez aucun derrière : {{PREFIX}}, {{PROJECT_NAME}}, {{CSS}}, {{CSS_EXT}}, {{UI_LIB}}, {{UI_LIB_MCP_NAME}}, {{UI_LIB_MCP_PURPOSE}}, {{TESTS}}, {{GIT_POLICY}}, {{PACKAGE_MANAGER}}, {{NODE_VERSION}}, {{I18N_APPROACH}}, {{DATE}}.
• Portes d'inclusion — les réponses concernant SSR, i18n, JSDoc obligatoire, bibliothèque UI et moteur CSS ne remplissent pas un placeholder ; elles décident si un fichier entier (ou un bloc marqué <!-- SCAFFOLD --> à l'intérieur de celui-ci) est copié. Une réponse « non » (ou, pour CSS, les deux moteurs non choisis) signifie que le fichier/bloc est supprimé, pas rempli par une chaîne vide. Les fichiers conditionnels doivent toujours être liés depuis AGENTS.md / le README concerné lorsqu'ils sont conservés, et leurs liens supprimés lorsqu'ils sont ignorés.

3. Vérification

Exécutez checklist.md en intégralité avant de signaler la réussite.

Notes sur la structure de la documentation (à lire une fois, puis à suivre littéralement les templates/)

• CLAUDE.md est toujours une simple ligne pointant vers AGENTS.md.
• AGENTS.md est le point d'entrée obligatoire : une courte liste « À lire impérativement » plus des règles non négociables, à la racine du projet.
• .agents/README.md est un index plat de tout ce qui se trouve sous .agents/ — l'équivalent du index.ts pour l'arborescence documentaire. Chaque document racine et chaque README de sous-dossier y est lié. Maintenez-le à jour chaque fois qu'un fichier conditionnel (i18n, agent-surface, platform-adapter) est ajouté ou ignoré.
• Les sujets qui tiennent en un seul document court restent plats dans .agents/*.md (workflow, git-policy, documentation, mcp, testing-and-quality, agent-surface, refactoring, progress, i18n, accessibility).
• Les sujets qui se ramifient en plusieurs petits documents reçoivent un sous-dossier avec son propre README.md : .agents/code-style/, .agents/architecture/, .agents/shared/, .agents/core/, .agents/decisions/. Il s'agit d'une déviation délibérée par rapport à kikita-ui/-docs (qui restaient complètement plats) car le cahier des charges de cette compétence exige des documents de réutilisation par composant et par préoccupation qui continueront de croître après le scaffold.
• .agents/shared/README.md enregistre tout ce qui se trouve sous src/app/shared/, divisé par forme de dépendance : shared/ui/ (composant/directive/pipe, décoré Angular) et shared/utilities/ (fonctions simples, zéro import Angular — appliqué par une règle ESLint d'import restreint). Les mixins SCSS, si SCSS a été choisi, vivent dans styles/mixins/, pas du tout sous shared/. .agents/core/README.md enregistre les singletons à l'échelle de l'application (services/guards/interceptors) sous src/app/core/. Aucun des deux n'est nommé « components » — les deux couvrent plus que des composants, d'où la dénomination.
• .agents/decisions/README.md explique quand un ADR court est requis (direction des couches, propriété d'état, stratégie de routage, schéma d'alias public) — toujours généré, commence sans fichiers ADR. AGENTS.md le lie sous un groupe conditionnel « pour les modifications structurelles », pas dans la liste à lire toujours — même modèle que le groupe shared//core/ « pour le travail sur les composants ».
• Tout le contenu des fichiers suivis — y compris le JSDoc — est uniquement en anglais. Pas de cyrillique, pas de mojibake.
• Tous les documents dans .agents/ doivent se lire comme angular-code-style.md dans kikita-ui : impératif, court, appuyé par des exemples, se terminant par une checklist de révision/vérification.