<required> Tu DOIS poser à l'utilisateur la question de choix de mode de l'Étape 1 avant toute autre chose. Ne choisis pas un mode pour lui. Ne définis pas un mode par défaut. Le mode auto/autonome ne t'AUTORISE PAS à ignorer cette question — être en mode auto n'est jamais une raison valide pour contourner le prompt.

Il y a exactement deux exceptions étroites où tu PEUX ignorer la question de choix de mode de l'Étape 1. Les deux doivent être appliquées avec prudence ; si tu n'es pas certain qu'une exception s'applique, tu DOIS poser la question.

Pas d'opération depuis la dernière vérification dans cette conversation. La vérification CI la plus récente dans la conversation actuelle a déjà été exécutée, et chaque modification depuis est manifestement/indubitablement en dehors de la portée de toute vérification que la compétence effectue. Exemples qui s'appliquent : modifications uniquement de commentaires ; modifications uniquement de fichiers en dehors de tout package workspace (p. ex. fichiers sous .claude/, README.md / CHANGELOG.md à la racine du repo, docs de haut niveau ne se trouvant pas dans un package docs/*). Attention : docs/api/ et similaire sont eux-mêmes des packages workspace — le markdown à l'intérieur d'un package workspace NE s'applique PAS automatiquement. Si tu ne peux pas vérifier rapidement que les fichiers modifiés se trouvent en dehors de chaque package workspace, pose la question.
Instruction permanente explicite. L'utilisateur t'a explicitement dit — dans cette conversation ou dans une entrée de mémoire sauvegardée — d'ignorer automatiquement la vérification CI readiness sans demander. Les préférences déduites, les approbations antérieures d'exécutions passées, ou les conseils généraux « sois moins interruptif » NE s'appliquent PAS.

Si l'une de ces exceptions s'applique, traite-la comme équivalente à l'utilisateur choisissant Skip à l'Étape 1 : ne pose PAS la question de choix de mode, ne crée PAS de tâches/todos de CI readiness, et ne lance PAS le script CI ni aucune autre étape de build/test/API-report. Arrête la compétence après avoir signalé le skip.

Lorsque tu appliques une exception, tu DOIS signaler explicitement — chaque fois, sans abréger sur les exécutions répétées — que (a) tu as ignoré de poser la question de choix de mode, (b) la vérification CI readiness elle-même a été ignorée, et (c) quelle exception s'applique. L'omission silencieuse est interdite.

Quand aucune exception ne s'applique, pose la question à l'utilisateur et attends sa réponse. Immédiatement après sa réponse, crée un élément de tâche/todo par étape applicable en utilisant ton outil de tâches disponible (TaskCreate pour Claude, TodoWrite pour Copilot) — avant tout autre travail. Marque chaque tâche in_progress quand tu la commences et completed quand tu la termines. Cela empêche les étapes d'être silencieusement ignorées au fur et à mesure que le contexte se développe.

Tâches à créer par mode :

Check : Lancer le script CI → Examiner la sortie → Signaler le statut final
Build : Lancer le script CI → Examiner la sortie → Compiler les packages non compilés → ESLint auto-fix → Régénérer les rapports API → Examen des changements API → Lancer build:docs → Régénérer les tests de type → Signaler le statut final
Test : identique à Build, plus Lancer les tests

Pour Build/Test : si @fluidframework/tree figure parmi les packages modifiés et sa surface API a probablement changé, ajoute une tâche « Cascade API reports to aggregator packages » après « Régénérer les rapports API ».

Omet les étapes qui ne s'appliquent pas (p. ex. ignore « Compiler les packages non compilés » si tout est déjà compilé ; ignore « Régénérer les rapports API » et « Régénérer les tests de type » si la surface API n'a pas changé). </required>

Étape 1 : Confirmer avec l'utilisateur

Avant toute chose, pose la question à l'utilisateur :

Je peux exécuter une vérification CI readiness sur ta branche. Choisis un mode (du plus rapide au plus lent) :

Skip — ignorer la vérification CI readiness

Check (rapide) — auto-corriger le formatage, la politique, et syncpack sur les packages modifiés

Build — Check + compiler les packages non compilés + ESLint + régénérer les rapports API et les tests de type

Test (plus lent) — Build + exécuter la suite de tests dans les packages modifiés

Attends la réponse de l'utilisateur. S'il dit skip (ou quelque chose de clairement négatif), arrête-toi ici. Sinon, note son choix et crée immédiatement des tâches pour toutes les étapes restantes comme décrit dans le bloc requis ci-dessus avant de procéder.

Étape 2 : Lancer le script

Lance le script fourni depuis la racine du repository :

bash .claude/skills/ci-readiness-check/ci-readiness-check.sh [base-branch]

La branche de base par défaut est main. Passe une branche différente si nécessaire (p. ex., next).

Le script détecte les packages modifiés, installe les dépendances si nécessaire, exécute fluid-build --task checks:fix (en auto-corrigeant le formatage, la politique, syncpack, et la cohérence des versions de build), vérifie que toutes les vérifications réussissent, vérifie la présence d'un changeset, et signale les modifications non committées et le statut du build.

Étape 3 : Examiner la sortie

Signale à l'utilisateur : packages modifiés, ce qui a été auto-corrigé, les vérifications toujours en échec, et les fichiers non committés. (Les conseils sur le changeset sont gérés par la compétence api-changes si les rapports API ont changé ; sinon l'avertissement du script est suffisant.)

Si tu vois des artefacts générés inattendus sans rapport avec les changements de la branche (en particulier dans les fichiers *.api.md), les artefacts de build périmés d'une session antérieure ou le bug TypeScript incrémental en sont probablement la cause. Pour @fluidframework/tree ou son agrégateur (fluid-framework), un nettoyage ciblé par package n'est pas fiable — tu dois faire un nettoyage et rebuild complet depuis la racine du repo :

# Depuis la racine du repo — pas de raccourcis
pnpm clean
pnpm build

Le build complet inclut la génération de rapports API pour tous les packages (y compris l'agrégateur fluid-framework), donc aucune étape de régénération séparée n'est nécessaire. Vérifie les rapports ensuite — si seules tes modifications prévues apparaissent, c'est bon.

Pour d'autres packages, un nettoyage ciblé peut suffire :

cd $PKG && pnpm exec fluid-build . --task clean && pnpm exec fluid-build . --task compile

Puis relance la vérification CI readiness. *Ne modifie jamais manuellement les fichiers `.api.md`** — ce sont des artefacts générés. S'ils sont incorrects, rebuilde et régénère.

Le mode Check s'arrête ici — omet entièrement les étapes 4–8. Note ce qui a été omis dans le rapport final.

Étape 4 : Gérer les packages non compilés (Build et Test uniquement)

cd $PKG && pnpm exec fluid-build . --task compile

Étape 5 : ESLint auto-fix (Build et Test uniquement)

cd $PKG && pnpm exec fluid-build . -t eslint:fix

eslint:fix assure que la compilation est à jour avant le linting et utilise le cache incrémental donc c'est rapide quand le package est déjà compilé. Si c'échoue en raison d'erreurs non auto-corrigeables, note-les mais continue.

Déterminer si la surface API publique a changé

Les étapes 6 et 7 ne s'exécutent que si la surface API publique a changé. Continue si : src/index.ts ou un point d'entrée (src/alpha.ts, src/beta.ts, src/legacy.ts, src/internal.ts) a été modifié ; une signature de type/interface/classe/fonction exportée a changé ; ou package.json exports a changé. Ignore si seuls les tests, l'implémentation interne, les commentaires, ou les corps de fonction (pas les signatures) ont changé.

Lancer build:api-reports quand rien n'a changé peut introduire des diffs parasites — en particulier pour les packages @fluidframework/tree et fluid-framework, qui présentent un bug TypeScript incrémental connu qui réordonne non-déterministiquement les unions de types et peut causer d'autres changements fantômes. Si tu vois des diffs de rapport API inattendus, fais un build clean complet depuis la racine du repo (pnpm clean && pnpm build) et régénère. Les nettoyages par package ne sont pas fiables pour le package tree. Vois tree-api-checks.md pour les détails.

Étape 6 : Rapports API et cascade entre packages (Build et Test uniquement)

Si @fluidframework/tree figure parmi les packages modifiés et sa surface API a probablement changé, lis .claude/skills/ci-readiness-check/tree-api-checks.md avant de procéder à l'étape 6a.

6a. Régénérer les rapports API

cd $PKG && pnpm exec fluid-build . -t build:api-reports

Si API Extractor échoue avec ae-missing-release-tag, ajoute une balise de libération TSDoc (@alpha, @beta, @public, ou @internal) à la nouvelle export, rebuild, puis réessaye.

6b. Examen des changements API

Après régénération des rapports, vérifie si des fichiers api-report ont vraiment changé :

git diff --name-only HEAD -- | grep api-report

Si des fichiers api-report ont changé, lance la compétence api-changes. Elle classifiera les changements par balise de libération, déterminera si l'approbation d'API Council est nécessaire, signalera les changements qui cassent et qui nécessitent des étapes de processus, et vérifiera les exigences de changeset et dépréciation.

6c. Lancer `build:docs` pour attraper les erreurs TSDoc

build:api-reports supprime les erreurs ae-unresolved-link ; CI les attrape via build:docs. Lance pour chaque package modifié compilé ayant un script build:docs, indépendamment du changement de surface API :

cd $PKG && pnpm run build:docs

Si tu vois des erreurs ae-unresolved-link, la balise {@link} ou {@inheritdoc} référence un nom ambigu. Corrige en établissant un lien vers une cible non ambiguë. Les sélecteurs TSDoc :instance/:static ne sont pas supportés par cette version d'API Extractor.

Étape 7 : Régénération des tests de type (Build et Test uniquement)

Pour chaque package modifié compilé ayant un script typetests:gen et où la surface API publique a probablement changé :

cd $PKG && pnpm run typetests:gen

Étape 8 : Lancer les tests (Mode Test uniquement)

Lance les scripts de test qui existent dans chaque package modifié compilé :

cd $PKG && pnpm run test:mocha
cd $PKG && pnpm run test:jest

Ignore test:benchmark, test:stress, et test:realsvc — trop lents et instables pour une vérification pré-push. Signale tous les résultats pour le rapport final même si certains échouent.

Étape 9 : Statut final

Lance git status et signale :

Fichiers auto-corrigés — formatage, politique, corrections ESLint (non staged ; l'utilisateur devrait examiner et stage)
Fichiers générés mis à jour — rapports API, tests de type (doivent être committés avec la PR)
Résultats des tests — si le mode Test, réussite/échec par package
Problèmes restants — tout ce que la compétence ne pouvait pas auto-corriger
Vérifications omises — tout ce qui a été omis en raison du choix de mode ou de packages non compilés

Termine par une affirmation claire : « Ta branche est prête à être pushée » ou « Ces problèmes demeurent : ... »

Si des modifications de code supplémentaires sont apportées après cette vérification, relance ESLint et — si la surface API a changé — régénère les rapports API avant de pousser.