Kiro CLI V3 est déployé comme expérience par défaut

Kiro CLI V3 apporte dans votre terminal le même harnais d’agent que celui qui alimente Kiro IDE et Kiro Web. Avec V3, vous pouvez confier à Kiro une tâche qui exige planification, implémentation et révision, et continuer à travailler pendant que des agents de workflow s’occupent des étapes en arrière-plan. Vous pouvez aussi démarrer une session infonuagique et fermer votre portable sans interrompre le travail. Avec le nouveau mode Spec, vous pouvez passer en revue les exigences et la conception avec Kiro avant qu’il commence à écrire du code. Et le nouveau mode tangent vous permet de bifurquer vers des conversations parallèles sans affecter le contexte de votre session principale.

Nous avons lancé V3 en option en juin et n’avons cessé d’ajouter de nouvelles capacités depuis. Nos clients qui l’ont adopté en option apprécient les nouvelles fonctions, et nous nous préparons maintenant à faire de V3 l’expérience par défaut pour tout le monde. À partir du 12 octobre, nous déployons graduellement une invite de démarrage qui vous propose de passer à V3, en prévision de la version CLI 3.0 d’ici la fin d’octobre. Il se peut que vous ne voyiez pas l’invite tout de suite, mais vous pouvez essayer V3 à tout moment avec kiro-cli --v3. Ce déploiement s’applique uniquement à Kiro CLI.

Pour la plupart des utilisateurs, le changement n’exigera aucune modification de configuration. Si vous avez personnalisé vos agents, vos permissions ou vos intégrations, les sections ci-dessous expliquent ce que Kiro migre automatiquement et ce qui demande votre attention. Avec CLI 3.0, nous retirons l’autocomplétion shell en ligne et l’application de bureau du CLI. Nous retirons aussi l’expérience Classic et concentrons les nouvelles capacités sur l’interface utilisateur du terminal.

Nous continuons d’ajouter de nouvelles fonctions à V3. Voici quelques faits saillants de nos dernières versions.

Vous pouvez maintenant laisser votre travail se poursuivre après avoir fermé votre portable, sans chercher des moyens ingénieux de garder votre portable « éveillé ». Démarrez une session infonuagique avec kiro-cli --cloud, associez-y un dépôt et laissez Kiro travailler dans un bac à sable infonuagique géré. Votre agent continue de travailler lorsque vous vous déconnectez, et vous pouvez reprendre la session depuis un autre poste. Si votre organisation utilise IAM Identity Center, un administrateur doit d’abord activer les sessions infonuagiques. Notez qu’à l’heure actuelle, les sessions infonuagiques s’exécutent uniquement dans la région USA Est (Virginie du Nord) us-east-1.

La nouvelle gestion de la mémoire permet à Kiro de conserver le contexte d’une session de clavardage à l’autre. Kiro peut tirer un contexte utile de votre travail dans des sessions V3 locales, comme les commandes et les conventions de votre dépôt, et s’en souvenir lors des sessions suivantes sans que vous ayez à le réexpliquer. Utilisez /memories pour gérer ce dont Kiro se souvient.

Vous disposez maintenant du mode Spec de l’IDE dans le CLI. Il vous permet d’examiner l’approche avant l’implémentation. Vous pouvez passer en revue les exigences et la conception avec Kiro avant qu’il commence à écrire du code. Vous pouvez aussi laisser des commentaires en ligne sur le document et choisir les tâches à exécuter, le tout depuis votre terminal. Commencez avec /spec new.

Nous avons réintroduit une version améliorée de /tangent, que nous avions d’abord présentée comme fonction expérimentale dans CLI V1. Elle vous permet d’explorer une piste secondaire sans affecter le contexte de votre session principale. Tangent était l’une de nos fonctions les plus demandées, et nous sommes heureux de la réintroduire dans V3.

À mesure que le nombre de sessions augmentait, trouver celle dont vous aviez besoin devenait plus difficile, comme chercher une aiguille dans une botte de foin. Nous avons ajouté un nouveau volet /sessions qui vous permet de parcourir, de mettre en signet et de renommer vos sessions, et bien plus, pour faciliter leur gestion.

Vous pouvez déléguer du travail complexe en plusieurs étapes à des workflows, en local et dans le nuage. Confiez une tâche à Kiro, et les workflows coordonnent des agents pour la planifier, l’implémenter et la réviser. Chaque étape s’exécute dans sa propre session avec un contexte neuf, de sorte qu’un réviseur n’hérite pas du raisonnement de l’agent de programmation. Vous pouvez continuer à travailler dans le clavardage principal pendant que le workflow s’exécute en arrière-plan, et l’orienter ou le suspendre au besoin. Les workflows sont facultatifs; activez-les dans les paramètres avant votre première exécution.

Nous avons aussi simplifié la réutilisation de votre configuration. Les Hooks globaux vous permettent d’utiliser la même automatisation dans tous vos espaces de travail. De plus, vous pouvez maintenant placer des fichiers AGENTS.md dans des sous-répertoires, et pas seulement à la racine du dépôt, pour donner à Kiro des instructions propres à différentes parties de votre projet. Par exemple, vous pouvez mettre les conventions de l’interface dans un répertoire et les instructions de test du serveur dans un autre.

Kiro CLI V3 apporte dans votre terminal le même harnais d’agent que celui qui alimente Kiro IDE et Kiro Web. Le harnais gère les outils, le contexte, les permissions et les interactions avec les modèles, tandis que chaque client conserve sa propre interface.

Pour nos utilisateurs, cela signifie que nous pouvons offrir dans le terminal une capacité conçue dans le harnais en même temps que dans les autres clients, plutôt que de la porter plus tard. Notre récent lancement des workflows en est un exemple : nous l’avons publié simultanément dans tous les clients. Le harnais partagé offre aussi aux clients un modèle commun de configuration et de permissions, de sorte que vous pouvez réutiliser la configuration .kiro/ de votre dépôt d’un client à l’autre. Ce que chaque client prend en charge demeure toutefois différent, et la documentation de V3 énumère la prise en charge actuelle du CLI.

Pour en savoir plus, lisez pourquoi nous avons conçu un seul harnais d’agent.

V3 est offert en option depuis juin. Les commentaires recueillis pendant l’accès anticipé ont confirmé que changer de harnais d’agent ne devrait pas vous obliger à reconstruire votre configuration. Vos agents, vos permissions et vos flux de travail habituels doivent vous suivre. Cela a façonné l’expérience de migration.

Nous avons défini un format de « configuration universelle » qui conserve vos paramètres V2 existants et ajoute la configuration dont V3 a besoin. Notre outil de migration met à jour vos agents personnalisés vers ce format, sauvegarde les configurations d’origine, convertit automatiquement les paramètres pris en charge et signale tout ce qui demande votre attention.

Pendant le déploiement de V3, Kiro CLI affiche au démarrage une invite qui vous propose de passer à V3. Elle offre trois choix :

• Switch to V3 and upgrade my configs (passer à V3 et mettre à niveau mes configurations) : enregistre V3 comme harnais par défaut, active les mises à niveau automatiques des agents et lance la migration de vos configurations d’agents personnalisés de l’espace de travail et globales.
• Remind me later (me le rappeler plus tard) : reporte le changement et permet à l’invite de revenir plus tard.
• Don’t ask again (ne plus me demander) : cesse d’afficher l’invite. Cela ne vous maintiendra pas sur V2, et votre configuration sera tout de même mise à niveau vers V3 lors de la sortie de CLI 3.0 à la fin d’octobre.

Si vous souhaitez changer dès maintenant, vous n’avez pas à attendre l’invite. Exécutez kiro-cli --v3 pour essayer V3 dans une nouvelle session. Pour l’enregistrer comme valeur par défaut, exécutez :

Si vous utilisez déjà V3, vous pourrez omettre l’option --v3 lorsqu’il deviendra l’expérience par défaut avec le déploiement de CLI 3.0 à la fin d’octobre.

Si vous devez revenir à V2, exécutez kiro-cli --v2. L’option s’applique uniquement à ce lancement. Vous pouvez reprendre vos sessions V2 dans V3, mais vous ne pouvez pas reprendre dans V2 les sessions créées dans V3.

Pour la plupart des utilisateurs, le changement n’exigera aucune modification de configuration. Si vous avez personnalisé votre configuration, voici ce qui est transféré automatiquement et ce qui demande une vérification. Les sections ci-dessous couvrent aussi l’autocomplétion, le retrait de Classic et les changements pour les intégrations ACP.

Lorsque vous acceptez l’invite de migration, Kiro sauvegarde chaque configuration d’origine sous le nom <name>.json.bak, conserve vos paramètres V2 existants et ajoute la configuration nécessaire à V3. Vos requêtes, vos choix de modèles, vos ressources et vos définitions de serveurs MCP sont transférés sans modification.

La migration convertit aussi les Hooks pris en charge. Les Hooks qui ne peuvent pas être convertis sont exclus de la configuration V3 et signalés par des avertissements. Examinez ces avertissements et mettez à jour manuellement les Hooks concernés. Votre configuration d’origine reste disponible dans la sauvegarde. Pour exécuter ou répéter la migration vous-même, utilisez /upgrade-agent.

Si votre équipe conserve ses agents dans un dépôt central, vous pouvez mettre à niveau tout le répertoire d’un coup avec kiro-cli agent upgrade <dir> dans la version 2.29 et les versions ultérieures. Exécutez d’abord la commande avec --dry-run pour prévisualiser les changements et les avertissements. Elle ne réécrit que les agents encore au format V2 et laisse inchangés ceux qui ont déjà une section V3.

V2 utilise des listes d’outils approuvés et des paramètres par outil. V3 utilise des règles pour les actions et les ressources, comme une commande shell ou un chemin de fichier. Lorsque des règles se chevauchent, le refus l’emporte sur la demande de confirmation, et la demande de confirmation sur l’autorisation, quelle que soit la portée.

La migration convertit les paramètres pris en charge, mais certains motifs demandent une vérification ou un remplacement manuel. Après la migration, exécutez /upgrade-agent diagnostics et réglez les avertissements de conversion avant de vous fier aux règles migrées.

--trust-all-tools demeure pris en charge dans V3. Le guide de migration des permissions explique comment chaque paramètre correspond au nouveau modèle.

V3 n’a pas l’outil use_aws. Les commandes AWS CLI s’exécutent plutôt par l’outil shell et suivent les règles d’approbation du shell.

Recréez vos paramètres d’autorisation et de refus de use_aws sous forme de règles de permission du shell. Pour les commandes que vous voulez approuver de façon permanente, vous pouvez aussi choisir « Always allow » lorsque la confirmation vous est demandée. Gardez des règles précises plutôt que d’autoriser des motifs larges comme aws *. Pour obtenir de l’aide sur la migration, consultez le guide des permissions.

L’autocomplétion shell en ligne et l’application de bureau du CLI sont en voie de retrait et ne seront plus offertes avec le déploiement de CLI 3.0.

Classic n’est pas pris en charge dans V3 et sera retiré graduellement. Nous développons les nouvelles capacités dans l’interface utilisateur du terminal.

Pour passer à la TUI, retirez --classic de vos alias ou de vos raccourcis et lancez kiro-cli.

La migration de la configuration des agents ne met pas à jour votre intégration ACP. Suivez le guide de migration ACP pour connaître les changements côté client, et utilisez kiro-cli acp --agent-engine=v3 pour démarrer le serveur ACP V3.

Les utilisateurs ordinaires du terminal CLI peuvent ignorer cette étape.

Pendant que nous déployons graduellement l’invite de démarrage qui vous propose de passer à V3, nous vous recommandons d’accepter le changement, d’explorer les nouvelles fonctions et de régler tout ce qui demande votre attention dans votre configuration avant la sortie de CLI 3.0 à la fin d’octobre.

Utilisez V3 pour votre prochaine tâche. Déléguez une tâche à un workflow, examinez un Spec ou laissez une session infonuagique poursuivre le travail pendant votre absence. La documentation de V3 couvre la configuration et la prise en charge actuelle. Dites-nous ce qui a fonctionné et ce qui vous a bloqué avec /feedback ou sur Discord, et suivez le journal des modifications du CLI à mesure que le déploiement progresse.