Vérification de version (Release Check)

Exécute un précontrôle avant publication sur un projet Flutter avant de construire pour Google Play ou l'App Store. À utiliser lorsque l'utilisateur demande « mon appli est-elle prête à être publiée ? », « vérifie avant que je publie », « liste de contrôle de version », « pourquoi mon appli a-t-elle été rejetée ? », ou avant d'exécuter flutter build appbundle / ipa.

Qu'est-ce que Vérification de version (Release Check) ?

Cette compétence aide les développeurs Flutter à préparer une version qui ne sera pas rejetée par Google Play ou l'App Store. Elle exécute un script de précontrôle déterministe qui vérifie la version, le changelog, l'analyse statique, les tests, les reliquats de débogage, Android et iOS. Chaque élément problématique est signalé comme OK, WARN ou FAIL. La compétence guide ensuite l'utilisateur pour corriger chaque problème avec des instructions précises (fichier et modification exacte). Elle vérifie également des points que le script ne peut pas détecter, comme le SDK cible, l'icône de l'application, les permissions, les assets du store et la suppression de compte. Enfin, elle génère un rapport court avec un verdict (PRÊT / PAS PRÊT), les correctifs obligatoires et recommandés, et les commandes suivantes. Elle est conçue pour être utilisée avec Claude Code.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/ChandraChaan/flutter-release-kit/tree/HEAD/skills/release-check

Installed? Explore more Développement et programmation skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Vérification de version (Release Check) ?

Vous aidez un développeur Flutter à publier une version qui ne sera pas rejetée par Google Play ou l'App Store. Soyez concret : nommez le fichier et la modification exacte pour chaque problème.

Étape 1 : exécuter le précontrôle déterministe

Depuis la racine du projet Flutter, exécutez :

bash "${CLAUDE_PLUGIN_ROOT}/scripts/preflight.sh" $ARGUMENTS

Le script affiche des lignes OK / WARN / FAIL regroupées par section (Version, Changelog, Analyse statique, Tests, Reliquats de débogage, Android, iOS) et se termine avec le code 1 en cas de FAIL. Cela peut prendre une minute lorsque les tests s'exécutent. Si l'utilisateur est clairement en pleine phase de développement et souhaite seulement un aperçu rapide, passez --skip-tests.

Étape 2 : enquêter sur chaque FAIL et WARN

Pour chaque élément, ouvrez le fichier nommé par le script et confirmez le constat avant de le signaler. Corrections courantes :

ConstatCorrection
La version n'a pas de numéro de buildChangez version: 1.2.0 en version: 1.2.0+1 dans pubspec.yaml.
Un tag existe déjà pour cette versionExécutez la compétence bump-version.
com.example applicationId ou bundle idUtilisez flutter pub run change_app_package_name:main com.votresociete.app ou modifiez android/app/build.gradle(.kts) et les trois entrées PRODUCT_BUNDLE_IDENTIFIER dans ios/Runner.xcodeproj/project.pbxproj.
Signature de version avec une clé de débogageAjoutez le chargement de key.properties et un signingConfig de type release ; voir references/android-signing.md.
key.properties ou *.jks suivis par gitAjoutez-les à .gitignore, puis git rm --cached <fichier> ; changez le mot de passe du keystore si le dépôt est public.
Absence de PrivacyInfo.xcprivacyCréez ios/Runner/PrivacyInfo.xcprivacy ; modèle dans references/privacy-manifest.md.
debuggable=true, trafic en clair, URL localhostSupprimez avant la publication.
Erreurs de l'analyseur / échecs des testsCorrigez-les ; ne suggérez pas de les ignorer.

Étape 3 : vérifier les éléments que le script ne peut pas détecter

Examinez le projet et considérez :

  • SDK cible : Google Play exige que les nouvelles applications et mises à jour ciblent un niveau d'API Android récent (l'exigence de Play correspond approximativement à la version de l'année précédente). Vérifiez targetSdk dans android/app/build.gradle(.kts) ou par défaut de Flutter.
  • Icône et écran de démarrage de l'application : l'icône Flutter par défaut entraîne un rejet lors de la revue et une désinstallation immédiate de la part des utilisateurs. Vérifiez la configuration de flutter_launcher_icons / flutter_native_splash ou les dossiers mipmap.
  • Permissions : si le manifeste contient autre chose que INTERNET, suggérez d'exécuter la compétence permission-audit.
  • Assets du store : image de fonctionnalité 1024x500 (Play), captures d'écran pour chaque catégorie d'appareil requise, URL de la politique de confidentialité (obligatoire si l'application collecte des données ou demande des permissions sensibles).
  • Suppression de compte : les deux stores exigent un chemin de suppression de compte dans l'application si celle-ci prend en charge la création de compte.
  • Connexion pour les testeurs : s'il y a un écran de connexion, rappelez à l'utilisateur de fournir un compte de démonstration dans les notes de revue.

Lisez references/store-rejections.md pour la liste complète des motifs de rejet courants et leurs corrections lorsque l'utilisateur demande pourquoi il a été rejeté ou souhaite une revue plus approfondie.

Étape 4 : rapport

Renvoie un rapport court :

  1. Verdict : PRÊT / PAS PRÊT.
  2. À corriger impérativement (éléments FAIL, chacun avec un fichier et une modification exacte).
  3. À corriger si possible (éléments WARN qui comptent pour cette application).
  4. Commandes suivantes : généralement flutter build appbundle --release et flutter build ipa --release, précédées de bump-version et changelog lorsque la version a déjà été publiée.

Soyez concis. Ne répétez pas les lignes OK à moins que l'utilisateur ne demande la sortie complète.

Individual skills in this repo

This repo contains 1 individual skill — each has its own dedicated page.

Skills associés